The Art of Making Things Clear
Technical explanation as a creative act, not a reductive one. Why the best explanations are stories, not definitions. What changes in you when you explain something well.
The physicist Richard Feynman had a test. If he couldn't explain something to a first-year undergraduate, he didn't understand it himself. Not "simplify it for beginners" — explain it. Make it genuinely clear to someone who doesn't share your vocabulary, your assumptions, or your years of accumulated context.
This is much harder than it sounds, and not for the reason most people think.
Clarity is not simplicity
There's a widespread belief that explaining a complex topic means dumbing it down. Removing nuance. Sanding off the interesting edges until what remains is smooth, approximate, and slightly wrong. This belief is why so many technical explanations are terrible — they're written by experts who think clarity and accuracy are in tension.
They aren't. Clarity is a property of the explanation, not the topic. A quantum physics paper can be clear. A children's story can be confusing. The variable isn't complexity — it's whether the author has done the work of translating their understanding from the compressed, jargon-dense format in which experts think into a format that builds understanding step by step.
The key word is builds. A good explanation doesn't transfer information from one mind to another like copying a file. It constructs a mental model in the reader's mind, piece by piece, testing each piece against what the reader already knows, adjusting when something doesn't fit. This is an act of design, not transcription.
When someone says "I can't explain this simply because it's too complex," what they usually mean is "I haven't figured out the construction sequence." They know the destination but they haven't mapped the path from the reader's current position to the destination. That mapping is the craft.
The curse of knowledge
Cognitive scientists call it the "curse of knowledge." Once you understand something, you can no longer imagine not understanding it. The steps that got you from confusion to clarity are invisible to you now — they've been compressed into a single chunk of understanding that you access as a unit, the way a fluent speaker accesses a word without remembering the years of acquisition that made the word available.
This is why experts are often terrible explainers. They skip steps they can no longer see. They use terms they've forgotten are jargon. They assume context that only exists inside their own mental container. The explanation makes perfect sense to them — because they already have the understanding that the explanation is supposed to create.
The fix is empathy, not simplification. The explainer needs to reconstruct the state of not-knowing — to remember or imagine what it felt like before the pieces fell into place. What was confusing? What was the wrong mental model that needed to be corrected? What analogy would have helped? What question would have unlocked the next step?
This reconstruction is effortful and uncomfortable. It requires you to temporarily unmake your own understanding, which feels like regression. Most experts resist it. The ones who don't — Feynman, Sagan, the best teachers you've ever had — produce explanations that feel like gifts.
Metaphor as bridge
The most powerful tool in explanation is metaphor, and it's also the most dangerous.
A good metaphor creates a bridge between something the reader already understands and something they don't yet. "A database index is like the index at the back of a book — instead of reading every page to find what you want, you look up the location and go straight there." This works because the reader already has a mental model of book indexes, and the database concept maps cleanly onto it.
But every metaphor lies. The database index is not a book index. It has properties the book index doesn't (B-tree structure, write amplification, storage overhead) and lacks properties the book index has (alphabetical ordering visible to the user, physical pages). If the reader takes the metaphor too literally, they'll build a wrong model that they'll later have to unlearn.
The craft is in knowing when to deploy the metaphor and when to break it. "A database index is like a book index... except that it updates itself every time you add data, which a book index doesn't. This means every insert pays a cost that a book doesn't have. This is why you don't index every column — it's like creating a separate book index for every possible way someone might search."
The metaphor gets the reader near the concept. Then you gently push them past it. Then you bring them back with a refined version. This dance — analogy, correction, deeper analogy — is the rhythm of all good explanation.
Teaching as learning
Here's the thing nobody mentions about explaining: it changes you.
When you explain something well — not summarise it, not parrot it, but genuinely construct it from scratch for someone who doesn't know it — you understand it differently afterward. The act of finding the construction sequence, of mapping the path from not-knowing to knowing, reveals gaps in your own understanding that you didn't know were there.
Every teacher knows this. The semester you teach a course for the first time, you learn the material more deeply than in all the years you studied it. Not because you read it again, but because you had to reconstruct it. You had to ask "why does this come before that?" and "what would happen if I explained it in the other order?" and "what does the student need to know before this step makes sense?"
These are questions you never ask when you're learning for yourself. You can get away with partial understanding, compressed steps, and unexamined assumptions when you're the only consumer of your knowledge. The moment you try to explain, the gaps become visible.
This is why writing is thinking, not just recording. Why rubber-duck debugging works. Why the best way to learn something is to try to teach it. The explanation process is a debugging process — it exposes the places where your understanding is held together by hope rather than structure.
And here's the deepest thing: the willingness to explain is the willingness to be wrong. Every time you construct your understanding out loud, you risk discovering that it was wrong. That the mental model you've been relying on doesn't survive contact with a fresh perspective. That the compression you performed when you "got it" lost something essential.
This is why the best explainers are also the most humble. They know that their understanding is provisional, constructed, and subject to revision. They explain not from a position of authority but from a position of curiosity — "here's how I think about this, and let's see if it holds up."
What do you think you understand that you've never tried to explain?