The Name Is the Understanding
Struggling to name something isn't a vocabulary problem. It's the code telling you that you don't yet understand the thing you're building — and a good name is what understanding looks like once you do.
Blog
Fast Enough Is a Real Number
Performance has a target, and the target is almost never 'as fast as possible.' It's a specific threshold tied to what a human perceives or a system requires — and knowing that number is what tells you when to stop.
The Shape Beats the Constant
Once you've measured, most real speedups don't come from making the code faster. They come from making the code do less — changing how the work grows with the input, not shaving the cost of each step.
You Are Guessing About Speed
Performance intuition is wrong often enough to be dangerous. The slow part is rarely where it feels like it should be — and the only way to know is to measure the specific system, not reason about it.
The Deadline Doesn't Change the Work
A deadline sets when you want something, not how much work it is. When the two collide, the honest levers are few — and the popular ones, adding people and working harder, mostly make it worse.
The Estimate Is a Distribution
When you give a task a single number, you've hidden the only thing that mattered: the spread. A three-day estimate that's really 'two to fifteen' isn't a smaller version of the same answer — it's a different kind of answer.
The Second Ninety Percent
The old joke — the first 90% of the work takes 90% of the time, and the last 10% takes the other 90% — isn't cynicism. It's a precise description of where estimates go to die: the unglamorous finishing that no one pictures.
Coverage Is Not Confidence
A coverage number tells you which lines ran during the tests. It says nothing about whether anything was actually checked — and the gap between those two is where teams get a false sense of safety.
The Mock That Agreed With You
A mock replaces a real dependency with your belief about how it behaves. When the belief is wrong, the test passes and production fails — because you tested the version of the world in your head, not the one that exists.
The Test That Broke for the Wrong Reason
A test that fails when you refactor working code isn't protecting you — it's charging you. And the real damage isn't the wasted hour; it's that the suite slowly teaches people that failures don't mean anything.