Writing on systems and people
Field notes on code, teams, and the rest of a life.
I'm an engineering director who still gets obsessed with the problem in front of me, how the product feels in someone's hands, and the insight that actually grows a business. This is the writing I wish I'd had earlier: architecture and strategy when they're useful, leadership when teams get messy, and the mental models that connect building products with building a life. Come for a post on systems. Stay if you also care about the people running them.
What cloud’s lost decade teaches us about adopting AI
The cloud was the right bet. The way we adopted it was not. AI is on the same curve, steeper and more expensive — and this time the bill includes trust, unless we front-load the learning that the last decade skipped.
The two-billion transaction cliff
Postgres does not get slower when it runs out of transaction IDs. It stops accepting writes entirely — and three of the commands people reach for first will make the outage longer.
Exponential backoff alone will not save you
Backoff spreads retries out in time. It does not spread clients apart from each other. Without jitter a synchronised herd stays synchronised — it just gets quieter in between the spikes.
At fan-out, your p99 becomes your median
A service where one request in a hundred is slow sounds healthy. Fan a single user request out to a hundred such services and 63% of your users wait. The arithmetic is unforgiving, and it is why per-service latency targets quietly fail.
About this blog
Most engineering writing restates a well-known idea in confident language and stops there. The pieces here aim for the opposite: specific mechanisms, real thresholds, actual measured numbers, and a citation for each one so you can check the work instead of taking it on trust.
Where the evidence is ambiguous or the sources disagree, the post says so rather than smoothing it over. Corrections are welcome and get made.