The difference between knowing the answer and understanding it

There is a question that separates the two: can you explain why?

Knowing an answer means you can reproduce it when prompted. Understanding means you could derive it from scratch, connect it to adjacent ideas, and recognize when it does not apply. Most people who think they understand something actually know it. The distinction matters more than it sounds.

Why they feel the same

When you get something right, the feedback is identical whether you knew it or understood it. You pass the test. You fix the bug. You answer the question in the meeting. The external signal says: yes, you have this.

This is what makes the gap invisible for so long. You accumulate examples of being right. The confidence compounds. And then you encounter a situation that is slightly different -- different enough that knowing the answer is not enough -- and you find yourself at the edge of what you actually have.

A simple test

Peter Norvig has written about this in a different form: the true measure of learning something is time, not completion. Ten hours on something, revisited over months and years, builds something qualitatively different than ten hours done once.

A simpler test I find useful: try to explain it to someone who knows nothing about the field, using only first principles. Not the vocabulary. Not the acronyms. The actual underlying logic. If you cannot do this, you know the answer but do not understand the thing.

Richard Feynman called this the difference between knowing the name of something and knowing something. Knowing that a bird is called a "grebes" tells you nothing about how it dives or why its feathers repel water. You have a label. You do not have the phenomenon.

How borrowed knowledge decays

Understanding compounds. You read something new, and because you understand the underlying principles, you immediately see how the new thing connects to what you already know. The network grows.

Knowing decays. It is isolated. It does not connect to much. When you do not use it, it fades. And because it was never really yours -- because you received it rather than built it -- even when it is present it is fragile.

The engineers I have learned the most from can take any problem and reason about it from the ground up. They are not reaching for stored answers. They are building an answer in real time, from principles they have internalized deeply enough to use fluently. This is not a talent. It is the result of a specific kind of practice: the practice of asking why, not just what.

What this looks like in practice

The difference shows up most clearly in how people respond to unexpected failures.

When something breaks in a familiar way, knowing the answer is fine. You have seen this before. You apply the fix.

When something breaks in an unfamiliar way -- when the symptoms are ambiguous, when the standard playbook does not help -- the person who understands the system has a fundamental advantage. They can form a hypothesis based on how things actually work. They can reason about what is possible and what is not. They are not pattern-matching against a library of known answers; they are thinking.

This is also why rereading good books yields more than reading more books. Each time you return to something foundational, you are slightly different -- you have more experience to connect it to. The book has not changed; your understanding of it has deepened. That is the compounding in action.

The goal is not to have more answers. It is to have fewer answers you need to look up because you have built the capacity to reason toward them.