Articles worth the time. Each one has a note on what it changed in how I build, not a summary, because a summary would only be a worse version of the thing it points at. Go and read the originals.
4 Aug 2026·joelonsoftware.com·Joel Spolsky
Twenty-five years old and still the most useful thing written about the urge to rewrite. The argument is that the ugly code you want to delete is ugly because it encodes bug fixes you have forgotten about, and a rewrite throws that knowledge away along with the mess. If you maintain a plugin with an install base, read it before your next planning meeting rather than after.
4 Aug 2026·martinfowler.com·Martin Fowler
The practical answer to "we cannot rewrite it, so what do we actually do". New behaviour grows beside the old system and takes work away from it piece by piece, until the original can be retired. The part worth sitting with is the defence of throwaway transitional code: scaffolding you will delete later is not waste, it is what makes the risk affordable.
4 Aug 2026·brandur.org·Brandur Leach
The implementation piece that most idempotency writing skips. Not the concept, but the schema, the state transitions, and what happens when a request dies halfway through a multi-step operation. If you have ever written a webhook handler that calls a payment provider and then updates two tables, this is the piece that explains why that is harder than it looks.
4 Aug 2026·martinfowler.com·Martin Fowler
A short, clear description of the pattern that stops one failing dependency taking your whole application with it. Useful well beyond microservices: any plugin that calls a licence server, a payment gateway or an external API on a page load has this problem, and usually solves it with a timeout and hope.
4 Aug 2026·martinfowler.com·Martin Fowler
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.
4 Aug 2026·InfoQ·Rich Hickey
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.
4 Aug 2026·danluu.com·Dan Luu
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.
4 Aug 2026·kalzumeus.com·Patrick McKenzie
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.
4 Aug 2026·docs.stripe.com·Stripe
Vendor documentation rather than an essay, and worth reading even if you never touch Stripe. It is the clearest statement of what at-least-once delivery obliges the receiver to do: verify signatures, acknowledge fast, do the slow work elsewhere, and expect the same event more than once. Most webhook bugs are one of those four ignored.
4 Aug 2026·sre.google·Google SRE
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.
4 Aug 2026·semver.org·Tom Preston-Werner
The specification itself, which is short and which most people quoting it have not read. The value for plugin work is not the numbering scheme, it is the definition of a breaking change: anything that alters the public API, where the public API includes behaviour other people have come to depend on, not just function signatures.
4 Aug 2026·paulgraham.com·Paul Graham
The essay that gives technical founders permission to do the manual, unautomatable work early. Relevant to engineers specifically, because the instinct to build a system for something before you know whether anyone wants it is the most expensive habit an engineer-founder has.