I joined Keep on the banking team and spent my first four months building payments and currency conversion. By the end of it the system was moving ten million Canadian dollars a month across six currencies.
Payments are the only kind of software where a bug has a unit. Not "a bad user experience" — four hundred and twelve dollars, belonging to someone, in the wrong place.
The part that is not arithmetic
Currency conversion looks like multiplication. It is not.
A conversion has a rate, and a rate has a time, and the time you fetched the rate is not the time the user agreed to it, which is not the time the transaction settles. Every one of those gaps is a place where money can be created or destroyed. The engineering problem is not computing the number; it is deciding, and then defending, which moment is the truth.
TODO — Alberto: This is where the case study earns its keep. Describe the model you landed on. Where was the rate captured? What happened when settlement moved? Did you model money as a value object with a currency attached, or did you have a near-miss where a float or a bare integer crossed a boundary? Concretely: what did you get wrong first, and how did you find out? The wrong-first story is the one that proves you have actually done this. Everyone can describe the correct design in retrospect.
Managing
I moved from the banking team to managing multiple teams, including managers.
The honest summary of that transition is that I got further from the thing I am best at. I do not regret it — you learn things about how software gets made that you cannot learn from inside a pull request — but it is why I am an individual contributor again, and why I will say so in an interview rather than let someone discover it.
You cannot fix what you refuse to measure
The org had twenty-five engineers and no shared idea of whether it was fast or slow. Everyone had a feeling. The feelings disagreed.
I introduced DORA metrics — deployment frequency, lead time, change failure rate, time to restore — instrumented with Span.app and Pullpo.io. The point was never the dashboard. The point was that "review is slow" became "time to merge is nine days on this team and two on that one, and here is what the fast team does differently."
In some teams, time to merge fell from nine days to two. Not all of them. The teams where it worked were the teams where the number embarrassed someone with the authority to change how review was scheduled. Where it didn't work, the number was simply absorbed into the ambient noise of the week. That is a management lesson, not an engineering one, and it cost me most of a year to learn.
CI, again
Twenty-seven minutes to ten at P95; fifteen to five on an average run.
TODO — Alberto: One paragraph on how. If it was the same set of moves as at Prefix, say so — a reader will find it more convincing that you have a repeatable method than that you had two unrelated flashes of insight.
Infrastructure and the SOC 2 tax
I worked with our infrastructure contractor to maintain Terraform and with vendors through SOC 2.
There is no glamour in this paragraph and I have left it short on purpose. It is here because a staff-level reader knows that someone has to own the boring, load-bearing, audit-shaped work, and notices who volunteers.