Commonplace

The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.— Edsger W. Dijkstra

Every distributed system is eventually a consistency problem in disguise. The CAP theorem doesn't tell you which tradeoffs to make — it tells you that you cannot avoid making them. The best architecture decisions I've seen were made by engineers who understood the business domain well enough to know which consistency guarantees actually mattered to their users, and which ones were theoretical concerns they could trade away for simplicity.

The best book on software design I've read in years. Ousterhout's core argument is that complexity is the root cause of nearly all software problems, and that good design is about managing complexity through deep modules with simple interfaces. His concept of "classitis" — excessive decomposition creating shallow, leaky abstractions — perfectly describes a mistake I've made and seen made countless times.

I've started writing the runbook before writing the code. If I can't explain how to operate a system in plain English — how to know it's healthy, what degrades gracefully, what fails hard, how to restore it — then I don't understand the system well enough to build it. The runbook becomes a forcing function for operational clarity that no amount of code review achieves.

Make it work, make it right, make it fast. In that order, and only that order.— Kent Beck

The clearest visual explanation of CAP I have found. I link this to every new engineer on my team during onboarding. Worth bookmarking.

I distinguish between deliberate and accidental technical debt. Deliberate debt is a conscious tradeoff — we shipped fast knowing we'd need to refactor. Accidental debt is the result of not knowing better at the time. The former is manageable if you track it. The latter is dangerous because it's invisible until it compounds. Most teams conflate the two and end up with neither type addressed.

Borrowed from military training. The engineers I most admire don't type faster — they think more clearly before they type. They ask the question behind the question. They resist the urge to immediately reach for a solution. The extra 10 minutes of upfront thinking reliably saves hours downstream.

Good software is software that changes well.— Michael Feathers, Working Effectively with Legacy Code

The single most impactful technical book I've read. If you work on backends and haven't read it, stop and read it. Chapter 9 on consistency and consensus alone is worth the price.