Boring infrastructure wins the year

Checked 22 Sep 2026 · By Luke Czak

ArticleOpinionFree to read

The highest-leverage hour I spent this year did not ship a feature anyone could see. It quietly removed a category of incident nobody now has to have.

If I total up the hours I have spent this year and sort them by how much they actually mattered, the top of that list is not a feature anyone asked for. It is a stretch of unglamorous plumbing work: a health check that runs after every deploy and refuses to call the deploy finished until it passes, a retry policy that actually distinguishes a real failure from a passing network blip instead of treating them the same, a rule that stops a background job running twice when two machines both think they are the only one running it, the last of which exists because two machines once ran the same nightly job at the same moment, wrote conflicting updates to the same table, and left me untangling which write was correct for the better part of a morning. None of it produced anything a person outside my own pipeline would ever see, use, or ask about.

That invisibility is not incidental, it is the entire mechanism by which this kind of work pays off. A good health check does not produce a success story for anyone to read later, it prevents an incident from ever becoming one in the first place, and a prevented incident leaves no trace behind for anyone to notice or credit, because there is nothing left over to point at once it has done its job properly. The reward for good infrastructure is an ordinary day that nobody remarks on, which is a genuinely difficult thing to feel good about while you are building it, because the entire payoff is the absence of something bad rather than the presence of something good.

This makes boring infrastructure systematically underweighted against the return it actually produces, in a way a flashy feature never is. A new feature announces its own value the moment it ships, because someone can see it, use it, react to it, and tell you they like it. A retry policy that quietly stops a dozen transient failures turning into a dozen support tickets never announces anything at all, because from the outside a system with good retries and a system that simply never happened to hit a bad network this month look completely identical. I have to actively remind myself, fairly regularly, that the two are not the same thing just because they look the same from where I am standing.

I want to be honest that this is not an argument for building nothing but plumbing all year. An estate made entirely of health checks and retry policies, with no feature anyone actually wants sitting on top of them, ships nothing worth having, and infrastructure that exists purely to support a product nobody uses is not more valuable for having been carefully built. The case is not that infrastructure beats features in general, because plainly it does not on its own. It is that most of us, myself very much included, judge the return on an hour of work by how visible its result turns out to be, and that instinct gets infrastructure’s actual return badly wrong in one specific, predictable direction, every single time it is applied.

What changed for me this year was deciding to budget time for the boring category on purpose, rather than treating it as whatever gets done after the visible work is finished, because it never actually reaches that point on its own if left to compete for attention on its own merits. There is always another feature that feels more urgent than a health check nobody is currently complaining about, precisely because nobody is currently complaining. The plumbing does not compete well against something a real person is waiting on right now, so it has to get scheduled deliberately, on the strength of a return that will never show up as a headline anywhere, only as a year with noticeably fewer bad nights in it than the one before.

Comments (0)

Sign in to comment.