Not a biography.

How I think

I think in systems before screens. When someone describes a feature, I hear the data model, the failure modes, and the upgrade path before I picture the interface — because the interface will be redesigned three times, and those other things are forever. The question I ask most in any design discussion is the least glamorous one: what happens when this goes wrong? Systems reveal their character in failure, not in demos.

I write things down. Decision records, invariants, rejected alternatives — not as bureaucracy, but because a decision that can’t survive being written down usually shouldn’t survive at all. The written trail is also how a system outlives its authors, and outliving its authors is the point.

And I hold opinions at two strengths: invariants, held firmly and listed shortly; everything else, held loosely and priced openly. Most engineering conflict comes from confusing the two.

How I approach software

Start from one sentence the system must never violate — no acknowledged write is ever lost; keys never leave the device; a bank’s release is never blocked by us — and derive the architecture from it. A system with a clear invariant almost designs itself; a system without one argues forever.

Then: budgets over intentions. Latency, memory, binary size, build time — agreed before the work, asserted in CI after. A number that isn’t enforced by a failing build is a wish. Boring technology by default, abstractions only as answers to pain that has already arrived, and deletion treated as a first-class achievement. The pull requests I’m proudest of are net-negative.

Above all, I optimize for the engineer who arrives next. Code is read hundreds of times and written once; APIs, names, module boundaries, and error messages are user interfaces whose users are future colleagues. Software that lasts is software the next person can change without fear.

How I approach leadership

Reasoning out loud. The verdict of a design review matters less than the reasoning being spoken where juniors can hear it — that’s how judgment transfers. I’d rather a team understand why a boundary exists than obey it, because understanding survives my absence and obedience doesn’t.

Standards live in tooling, not memos. If the correct structure isn’t the easiest structure to produce, the standard is already dead; templates, linters, and CI are how a culture keeps its promises on a deadline. And mistakes get written up by whoever made them, starting with me — the engineering journals in the case studies include my own errors because a team learns honesty by watching what leaders do with theirs.

The measure I use for senior engineers, myself included: how many problems stop being hard for the people around them.

What great engineering looks like

Calm. Great engineering is quiet in production and quiet in the repository — few alerts, few surprises, few meetings about the same bug twice. It’s measured: claims come with numbers, and the numbers come from CI, not memory. It’s legible: a newcomer can trace the data flow in an afternoon and find that the code matches the documentation, because the documentation is tested too.

Mostly, it’s invisible. Users never see the module graph that let a feature ship safely, the merge function that refused to lose their data, or the budget that kept a widget alive. They just notice, year after year, that the software keeps working — and that is the entire reward.