Why Experts Take Bad Notes

In 1973, William Chase and Herbert Simon ran a study that should probably be required reading for anyone who builds tools to store knowledge. They showed chess grandmasters a board position for five seconds, then removed it. The grandmasters could reconstruct it with uncanny accuracy — nearly perfect recall of piece placement across a complex midgame. Then Chase and Simon scrambled the same pieces into random positions. The grandmasters' recall collapsed to roughly the level of beginners.

They weren't memorizing squares. They were seeing patterns — configurations that had been internalized through thousands of hours of play. Large chunks of board state processed as single units, the way a fluent reader takes in "immediately" rather than "i-m-m-e-d-i-a-t-e-l-y." And crucially: they couldn't tell you what those patterns were. The knowledge was real, reliable, extremely valuable — and completely unavailable for inspection.

This is the thing about deep expertise that most knowledge management tools are built to ignore.

How expertise changes the form of knowledge

Hubert and Stuart Dreyfus published their model of skill acquisition in 1980. The progression from novice to expert isn't accumulation — it's transformation. A novice operates by explicit rules: check the pawn structure, develop your knights, don't trade a bishop for a knight without reason. An expert does none of this consciously. The rules have dissolved into something faster and less legible. What was a checklist becomes intuition. What was effortful becomes automatic.

This is good, mostly. The problem is that the transformation is one-way. You can't easily inspect what you've internalized. The cognitive scientists Colin Camerer, George Loewenstein, and Martin Weber coined the phrase "curse of knowledge" in 1989 for a related phenomenon: once you know something, you can't accurately model what it's like not to know it. That's the communication problem. But there's a recording problem underneath it.

When knowledge becomes tacit — when it lives in your fingers, your pattern recognition, your gut — it stops being the kind of thing you can write down. A senior engineer's commit message is three words where a junior's is three paragraphs. Not because the senior cares less. Because the context they're compressing against is so large that spelling it out would take a week. So they don't.

What your notes actually contain

Here's the uncomfortable implication: your notes are densest around the things you were actively learning — the edges of your understanding where uncertainty was highest and the need to externalize was strongest. They thin out as expertise deepens, not because you're less thoughtful but because you stop needing to write things down.

I notice this in my own notes. The oldest entries on topics I now know well are long, hesitant, full of partial models and worked examples. The recent ones are almost empty. Not because the topic got simpler. Because the understanding got quieter, moved inward, stopped being something I needed to record.

Which means your knowledge base, however carefully maintained, is an autobiography of your confusion. The map is densest at the frontier you've already crossed. The territory you live in most fluently has almost no markings.

When an AI reads your notes, that's what it sees: not your current competence, but the learning curve that preceded it. A portrait of a previous version of you.

What structure does that prose can't

This is where typed entities start to make sense not as a convenience feature but as a design response to an actual epistemological problem.

A person record doesn't try to capture the tacit understanding you've built up about someone over years. It captures the name of the thing — the anchor. Role, relationship, last conversation, associated projects. The explicit structure doesn't replace what you actually know. It creates a hook that knowledge can hang on even when the knowledge itself isn't writable.

Gary Klein's research on expert decision-making shows that experienced practitioners don't reason through options in sequence — they recognize situations and act. The situation has to be recognizable to be acted on, though. A named, typed entity in your knowledge base is a recognizable handle. Even when your understanding of a person, project, or decision is too compressed to articulate, the structure lets you point at it. And pointing is often enough.

This is different from writing a note. A note is an attempt to capture reasoning. A structured record is more like naming a thing you already know how to think about. The note assumes your future self will need the reasoning spelled out. The record assumes your future self — or the AI working on your behalf — just needs to find the thing, and can use whatever they already know once they've found it.

What you should write down

None of this means notes are useless. It means they're most useful at exactly the moment they're hardest to take seriously: before you understand something well enough for the knowledge to go quiet.

The notes worth taking aren't summaries of what you know. They're records of the thinking that's still loose — the decisions you made and couldn't fully justify yet, the preferences that haven't calcified into habit, the person you're still figuring out how to read. Write the things that are still uncomfortable to name. Once they become automatic, you've missed the window.

The goal might not be to capture what you know. It might be to capture what you're about to forget.

---

Asgeir Albretsen is the founder of Harbor.