A chess master can glance at a board for five seconds and rebuild most of it from memory. Scatter the same pieces at random and he does no better than a beginner.
That one result, from a 1973 paper by William Chase and Herbert Simon, quietly explains something every developer has felt. You know the senior engineer who skims a 300-line diff and says "this breaks the retry logic" before you've found the function. It looks like a better memory.
It isn't. It's a bigger alphabet.
Five seconds with a chessboard
Chase and Simon worked with three players: a master, a Class A player and a beginner. Each one looked at a position for five seconds, then rebuilt it on an empty board.
On middle-game positions taken from real games, with 24 to 26 pieces on the board, the master placed about 16 pieces correctly on the first try. The Class A player managed about 8. The beginner, about 4.
Then the researchers took real positions and put the pieces on random squares. The master's advantage vanished. In their words, there was "no relation at all between memory of the position and playing strength." All three did worse on random boards than the beginner had done on real ones.
The interesting part came from watching how they recalled. Players put down a few pieces in a quick burst, paused, then put down another burst. Chase and Simon read each burst as one chunk: a cluster of pieces the player already knew as a single thing, think of a castled king tucked behind its pawns. The master recalled more chunks, and bigger ones.
His storage wasn't bigger. His units were.
Later work by Fernand Gobet and Simon (1996) put a rough size on the library behind those units. Their simulation fit the usual estimate that a master stores some 50,000 chunks. They also found that mirroring a position hurt recall, which means a chunk is a specific pattern in a specific place. It isn't a vague sense of "good chess."
Then someone tried it with code
In 1981, Katherine McKeithen, Judith Reitman, Henry Rueter and Stephen Hirtle ran the same test on programmers. Beginners had just started a programming course. Intermediates had just finished one. Experts had more than 2,000 hours of programming behind them.
Everyone got a 31-line ALGOL W program. Two minutes to study it, three minutes to write down everything they could remember. Five rounds.
Derek Jones later digitised the paper's figure, and the numbers are blunt. By the fifth round, experts had recalled roughly 20 of the 31 lines. Beginners were under 8.
Then the lines were scrambled. Same code, random order. The experts' edge largely went away: about 9 lines for experts against about 7 for beginners on the last round. Later reviews of the study sum it up simply: scramble the code and the expert advantage disappears.
The second half of the study is the part I keep thinking about. The team looked at how each group clustered ALGOL keywords in memory. Beginners grouped them by everyday English associations. Experts grouped them by what the commands do in a program, and their groupings looked remarkably alike from one expert to the next.
So the expert doesn't see 31 lines. They see "a loop that walks the array," "the guard clause," "the swap." A handful of things.
Why the number of slots matters
You've probably heard that working memory holds "seven, plus or minus two" items. That's George Miller's 1956 paper, and it's one of the most quoted lines in psychology.
Nelson Cowan argued in 2001 that seven was always more of a rough estimate and a rhetorical device than a hard limit. When you stop people from rehearsing or grouping items, the real capacity comes out at about four chunks.
Four. Not much room for debugging a race condition.
The good news sits inside the word "chunk." A chunk can be anything your long-term memory already knows as one thing. A single letter. A word. The whole idea of "debounce this handler." Four slots of beginner chunks hold four tokens. Four slots of expert chunks can hold the shape of a whole module.
The runner who remembered 79 digits
If you want proof that chunks are learned, look at a student known as S.F. In 1980, K. Anders Ericsson, William Chase and Steve Faloon had him practise a digit-span task about an hour a day, three to five days a week. He started at a normal span of 7 digits.
After more than 230 hours over about 20 months, he could hold 79.
S.F. was a distance runner, so he recoded digits as race times. 3492 became "3 minutes and 49 point 2 seconds, near world-record mile time." When times didn't fit, he used ages and dates. He then stacked those groups into larger structures, and he never put more than four groups into one supergroup.
Here's the giveaway. When the researchers switched him from digits to letters, his span dropped back to about six consonants. His memory hadn't grown. His library of running times had.
What this means at your desk
Seniority, in this light, is mostly a pattern library. Elliot Soloway and Kate Ehrlich called these patterns "programming plans" in 1984: generic fragments for stereotyped jobs (think "keep a running total inside a loop"), plus "rules of programming discourse" about how plans usually fit together. If that's right, code that breaks the conventions should feel harder even to an expert, because it stops chunking.
It also explains a feeling you've had. Clever, unidiomatic code is tiring to read even when it's short. It's the scrambled board. Your chunks don't fit, so you're back to holding single pieces in four slots.
And it means you can build chunks on purpose. Three things to try this week:
- Read code to name the plan. Open a well-maintained repo in your stack. For each function, write one line describing its plan ("cache-aside lookup," "retry with backoff") before you read the body in detail. You're training recognition, which is what the chess master had.
- Explain it back from memory. Close the file and say out loud what the function does and in what order. Then check. The gaps tell you which parts are still single pieces.
- Run the McKeithen test on yourself. Pick 30 lines of real code in a language you know. Two minutes to study, three to write it from memory. Do it again in a month with different code from the same codebase. If the count climbs, your chunks are growing.
Keeping the chunks you meet
Most of the patterns I've picked up came from talks, blog posts and videos, and most of them faded within a week because I never saw them again. That's the gap I built Recl for. You save the talk or article, it pulls out the key takeaways, and later it comes back with a recall question like "Still remember this one?" so the pattern gets retrieved again on a spaced schedule. Retrieval is how a new pattern stays available long enough to become a chunk.
Next time a senior dev spots the bug in seconds, remember the chess board. Same four slots as you. Bigger pieces in them, and every one of those pieces was learned.
Asutosh writes about memory and learning, and builds Recl, an app for remembering what you watch and read.
References
- Chase, W. G., & Simon, H. A. (1973). Perception in chess. Cognitive Psychology, 4(1), 55–81. https://doi.org/10.1016/0010-0285(73)90004-2
- McKeithen, K. B., Reitman, J. S., Rueter, H. H., & Hirtle, S. C. (1981). Knowledge organization and skill differences in computer programmers. Cognitive Psychology, 13(3), 307–325. https://doi.org/10.1016/0010-0285(81)90012-8 (digitised recall data: Derek Jones, https://shape-of-code.com/2016/11/17/ability-to-remember-code-improves-with-experience/)
- Miller, G. A. (1956). The magical number seven, plus or minus two. Psychological Review, 63(2), 81–97. https://doi.org/10.1037/h0043158
- Cowan, N. (2001). The magical number 4 in short-term memory: A reconsideration of mental storage capacity. Behavioral and Brain Sciences, 24(1), 87–114. https://doi.org/10.1017/S0140525X01003922
- Ericsson, K. A., Chase, W. G., & Faloon, S. (1980). Acquisition of a memory skill. Science, 208(4448), 1181–1182. https://doi.org/10.1126/science.7375930
- Gobet, F., & Simon, H. A. (1996). Recall of random and distorted chess positions: Implications for the theory of expertise. Memory & Cognition, 24(4), 493–503. https://doi.org/10.3758/BF03200937
- Soloway, E., & Ehrlich, K. (1984). Empirical studies of programming knowledge. IEEE Transactions on Software Engineering, SE-10(5), 595–609. https://doi.org/10.1109/TSE.1984.5010283
Top comments (0)