Your Brain Holds Four Things. Your Software Holds Millions.
George Miller's 1956 paper "The Magical Number Seven, Plus or Minus Two" was half a joke. Later research, notably Cowan (2001), stripped away rehearsal and chunking tricks, and the honest limit for working memory is about four separate items. That's it. Now consider the device you're reading this on: tens of millions of lines of code. The entire discipline of software engineering is a response to that ratio.
The Gorilla You Missed
Inattentional blindness is not a metaphor. In the famous Simons & Chabris (1999) experiment, half the people counting basketball passes failed to see a person in a gorilla suit walk through the scene for nine seconds. The Simons & Levin (1998) door study went further: while giving directions, a stranger swapped in behind a carried door, and half the subjects didn't notice the person they were talking to had been replaced. Your attention is a narrow beam in a dark warehouse, and almost everything is outside it. Even what you do hold leaks: Peterson & Peterson (1959) showed that unrehearsed letters vanish from memory within twenty seconds.
The Machine Is No Better
LLMs suffer from the same boundedness. Their context window is a hard limit—once something drops out, it's gone. The "Lost in the Middle" study (Liu et al., 2023) found that models answer accurately when the needed fact is at the start or end of a long input, but accuracy drops when it's buried in the middle. Give the model more retrieved documents, and performance can actually worsen. The model's attention is a fixed quantity that must sum to one; spread it thin, and earlier instructions fade. It's the same failure mode as a tired developer skimming a document.
The Permanent Condition
This isn't a problem you outgrow by being clever or hiring smarter people. The gap between mind and system is not a few orders of magnitude—it's the permanent condition of the work. Every incident report that blames "human error" is a system designed for an operator who never gets tired, never looks away, and holds the whole machine in mind. That operator was never born. The only question is: how do we shape the system so a small mind can change it without bringing it down?
Engineering as Cognitive Prosthesis
Good engineering moves facts out of your head and into structure. Precise names let you stop remembering what a variable does. Clear boundaries give you promises you can stop re-checking. Tests park decisions where they can't fade. Undo mechanisms make mistakes cheap. Each of these takes something that would otherwise live in those four fragile slots and anchors it in the system itself.
The OXO Handle Principle
In 1990, Sam Farber watched his wife Betsey struggle with a vegetable peeler due to arthritis. The resulting OXO Good Grips design—a soft, yielding handle—became a bestseller among people without arthritis. Designing for the most constrained user makes the tool better for everyone. The same applies to code: make a system safe for the tired engineer, the distracted one, the newcomer, and the LLM that keeps losing the thread, and you haven't lowered a ceiling—you've built something every engineer reaches for when their beam goes narrow.
Concrete Moves
This essay is the preamble to a manifesto of specific practices. The core idea: treat your attention as the scarce, unreliable resource it is. Name things precisely. Draw boundaries. Write tests. Make everything undoable. These aren't one-off tricks; they're a habit of mind. The full set of moves is detailed in The Shape of the System, but the principle is simple: build for a mind that holds four things, misses gorillas, and forgets within seconds. That's every mind. Including yours.
