Products that last
Most software is not killed by a dramatic failure. It is abandoned slowly, because nobody can safely change it any more, or because the people who knew why it was built that way have moved on and took the reasons with them. Durability is rarely the thing anyone is assigned to work on, and it is usually what decides whether a product is still running in five years.
In practice it comes down to legibility and honesty. Legibility means choosing the plain version on purpose: the obvious control flow, the explicit conditional, the dumb reliable database constraint instead of the clever in-memory trick. That choice is defended from the failure mode rather than from taste, because taste arguments are unwinnable and failure-mode arguments end in agreement. Honesty means monitoring that reflects what your users actually experience, and alerts that do not spend their credibility paging you over nothing.
The same logic applies to teams, which is why this pillar covers both. Code that a tired stranger can change safely and a team that keeps its context are the same bet made twice, and both are the sort of investment that looks unimpressive right up until the moment it is the only reason the product survived.
- You are maintaining something you expect to still be running in five years.
- You keep losing arguments for the plain solution in code review.
- You want reliability practice that does not cost more than the outage.
Cognitive debt costs you a slow refactor in most code and a wrong payment in billing code. How to scale AI review to what breaks when you are wrong.
Narrate the execution, not the file: what fires, in what order, in whose process. The four questions that find hook, observer and queue bugs in WordPress and Laravel.
How to argue for the plain version from the failure mode, and when to delete clever code you were proud of.
Why one server in one region measures its own path rather than your users, and how to confirm before you page anyone.
Inherited something you are afraid to change?
A codebase nobody wants to touch, or a system you need to still be running in five years. That is the work I like most.
Get in touchOther people's writing that shaped it
- martinfowler.com · Martin Fowler
Technical Debt Quadrant
A very short post that gives you a vocabulary for an argument you have probably had badly. Debt taken deliberately and debt taken accidentally are different problems; debt taken prudently and debt taken recklessly are different again. Once you can name which quadrant a shortcut sits in, the conversation about whether to pay it down stops being about taste.
- InfoQ · Rich Hickey
Simple Made Easy
A talk rather than an article, and the one worth an hour. The distinction it draws is between simple, meaning not braided together with other things, and easy, meaning familiar or near to hand. Most of what makes long-lived codebases painful is choosing easy over simple repeatedly, each time for a good local reason.
- danluu.com · Dan Luu
Files are hard
A survey of how often filesystems and the code above them get durability wrong, with the research to back it. The reason it belongs in a billing-adjacent reading list is the pattern rather than the subject: assumptions that hold in every test and fail under power loss are exactly the shape of the bugs that cost money.
- kalzumeus.com · Patrick McKenzie
Falsehoods Programmers Believe About Names
A list of assumptions about human names that are all wrong, and the piece that started an entire genre. Useful practically if you touch billing or account forms, and useful more generally as a habit: every one of these felt obviously true until it was written down and disproved.
- sre.google · Google SRE
Postmortem Culture: Learning from Failure
The chapter that explains why blameless postmortems produce better systems, and more usefully what a blameless one actually looks like in writing. Relevant to a one-person shop too: the discipline of recording what happened and why, in a form someone else could read, is most of the value even when the someone else is you next year.
Building something where this kind of work matters?
I'm in GMT+6 and work async-first, so your timezone is never a reason not to reach out.
Get in touch