Code Review
When I review a pull request I read the error handling before I read the feature. It is an odd order and it occasionally annoys people, but it comes from a simple observation: almost every incident I have been part of was an error path that had never been executed
Opinion
Every runbook I have ever opened during an incident was wrong. Not catastrophically, not uselessly, but wrong in the specific way that costs fifteen minutes at three in the morning: the dashboard had been renamed, the command needed a flag that did not exist when it was written, and the
Opinion
Positions I argued for, sometimes loudly, that turned out to be mistaken. What changed my mind in each case.
Debugging
An error message is read by a person under stress who needs to make a decision. Almost nobody designs them that way.
Engineering Culture
A document nobody reads, listing action items nobody does, produced to satisfy a process. Here is the version that actually changes something.
Debugging
Every layer you add to avoid repetition adds a place where the truth can hide. Here is how to tell which abstractions earn their cost.
DevOps
The instinct is to start investigating. The first ten minutes are better spent on four other things, and doing them makes the investigation faster.
AI
Green CI, clean review, broken production. The gap is that tests check whether code matches the implementation and production checks whether it matches reality.
AI
Each agent works fine alone. Chain them and quality collapses. The failure is almost always at the boundary between them.
Engineering Culture
They are genuinely useful and every one you leave in place multiplies the number of code paths nobody tests. Here is how to keep the benefit.
AI
Every mitigation at the model layer can be worked around. The fix is architectural: assume the model will be compromised and limit what it can do.
DevOps
A build system with production credentials and the ability to run arbitrary code from a pull request is the most under-secured part of most stacks.