The Feynman Method

You use the jargon fluently. "Dependency Injection." "Eventual Consistency." "Event Sourcing." Everyone nods in meetings. You sound like you know what you're talking about.

Then someone asks you to explain it simply. And you freeze.

That freeze is the Feynman test. Take a blank sheet of paper and describe the concept using only plain language — no jargon, no buzzwords, no hiding behind professional vocabulary. Just the idea, exposed. You'll get stuck at the transitions. Those are the exact places where you've been using a complex term to bridge a gap in your actual comprehension — places where the vocabulary was doing the work your understanding hadn't finished yet.

The same signal shows up in code. When you don't fully understand a problem, abstraction becomes a refuge. The class hierarchy grows. The interfaces multiply. It starts to look like engineering — and that's precisely what makes it dangerous. Complexity that masquerades as design tends to calcify. Nobody wants to touch it. Everyone assumes someone else understood it deeply when they built it. The confusion gets preserved in amber.

The blank page applies here too. If you can't walk someone through what your system does in plain terms, the design may be carrying confusion that never got resolved. Working through that confusion until you can say it plainly tends to reshape the code — the unnecessary layers start to fall away, and what's left is closer to what the problem actually needed.

Simple explanations and simple designs share the same source: a thorough understanding of the problem underneath them.