The illusion of understanding: why writing reveals what you actually know

I thought I understood closures. I use them every day; I could explain them in three sentences. Then I sat down to write a post about them - step by step, without skipping the hard parts - and I got stuck on a question I couldn’t answer off the top of my head: what exactly does a function carry with it when you return it, and when is that reference created? It wasn’t knowledge I didn’t have. It was knowledge I felt I had.

It turns out this isn’t a beginner’s problem. Cognitive scientists called it the illusion of explanatory depth: as a rule, we rate our understanding of a mechanism higher than it actually is, and we only notice when we try to reconstruct that mechanism. Rozenblit and Keil showed this in 2002 with everyday objects - asked to rate how well they understood a bicycle or a toilet, people gave themselves high marks, then couldn’t explain how the thing actually works, and lowered their scores. Closures are no different; only the line sits elsewhere: for one person it’s how a closure works at all, for another it’s exactly why a microtask jumps ahead of setTimeout. The line moves, but it is always somewhere. The question isn’t whether you have one, but where yours is - and the fastest way to find it is to try to explain something.

#Where the illusion comes from

Reading and watching give you fluency: your brain recognises a familiar shape and reports “I get it,” mistaking familiarity for understanding. And since nothing pushes back, you don’t notice that you quietly skipped every hard step.

#Why writing helps

One thing helps: producing, not just consuming. In memory research, the generation effect says that information you produce yourself sticks better than information you only read - even when the content is identical. Writing is exactly that kind of producing. You have to lay out every step in order, and each one you used to skip becomes visible, because you cannot write it down without understanding it.

The effect is even stronger when you write for someone seeing the topic for the first time. The mere prospect of teaching changes how you organise what you know: in an experiment, people told they would have to teach the material learned it better and organised it more clearly than those preparing “just” for a test - even though no one ended up teaching. That is why I don’t start a post from a topic I have mastered. I start from one I have the impression I understand, and I write it for a beginner reader - because nothing tests that impression faster than having to lay it out for an outsider.

#The surest test: code that runs

There is a test even more unforgiving than explaining: building something that actually works. Text can be fudged - you can pick words so the gap doesn’t show. Code can’t: it either runs the way you claim, or it doesn’t. When I was building the interactive microtask and macrotask queue for the event loop post, there was nowhere to hide - I had to understand exactly when a microtask runs before setTimeout, or the animation would have shown it wrong. The same with the Big-O post, which I learned mostly from scratch: I was sure that “Map is O(1).” Only when I was feeding real numbers into the slider did I see that Map is O(1) on average - in the typical case, yes, but not guaranteed in every one. Reading, I would never have noticed; I caught it only because the demo had to be real.

This habit has a side effect that reaches well beyond the blog: it is harder to fool myself in everyday code. When I catch myself thinking “it works, though I don’t fully know why,” that is exactly the moment I used to let slide - and now I treat it as a signal that there is a gap somewhere I haven’t named yet.

The practical takeaway is a little uncomfortable: the feeling of “I know this” is precisely what you shouldn’t trust, because it is the thing that fools you most smoothly.