Three essays that circle the same truth from different angles: good engineering is mostly about restraint, about respecting the limits of the person doing it, and about why duplication beats the wrong abstraction.
Matt Williams’ Engineering for Bounded Cognition is the piece I’ll be quoting for a while. The honest number for how many things a mind can hold at once, with no tricks, is about four, and we build systems of tens of millions of lines with that. The gorilla experiment and the door-swap study drive it home: attention is a narrow torch beam, and “human error” is usually a system built for an operator who never gets tired, never looks away, and holds the whole machine in their head: an operator who was never born. Everything we call good engineering (naming, boundaries, tests, anything undoable) is a way to move state out of a fragile four-slot mind and into the structure. And LLMs, with their context windows and “lost in the middle” attention, fail the same way. The OXO peeler coda (design for the constrained case and you get a better thing for everyone) is the quiet heart of it.
Sandi Metz’s The Wrong Abstraction is a 2016 classic that’s only gotten more relevant. The thesis (“duplication is far cheaper than the wrong abstraction”) and the eight-step decay it describes (extract the shared thing, then watch each new requirement bolt on a parameter and a conditional until it’s incomprehensible) is a pattern you’ll recognize in your own codebase immediately. The sunk-cost trap is the villain: the more effort the abstraction took, the harder it is to let go. Her advice is counterintuitive and correct: when the abstraction is wrong, the fastest way forward is back: re-inline the duplication, delete what each caller doesn’t need, and re-extract from what’s actually there. Read it right after the Expressive piece in the programming list; they’re arguing for the same instinct about boundaries.
Jakub Krehel’s Less Is More, More or Less brings it into the AI present. When every feature, animation, and idea is a couple of prompts away, the constraint stops being can you build it and becomes should you. His context-menu example is perfect: animating both open and close feels obviously better until you realize the menu opens 200 times a day, and then not-animating becomes the obvious call, a judgment agents can’t make yet because they execute without understanding how something is used. Removing is harder than adding, because removing requires intention. His conclusion, that in the age of AI knowing what not to build might be the most important skill of all, is the through-line of this whole cluster.