You don't understand it until you teach it
For a few years, a large part of my job was to go to other companies' offices and teach their engineers how to integrate with a system I had helped build. I went alone. The sessions lasted days. The audience was technical, skeptical, and had every incentive to find the holes — they were the people who would have to live with the integration long after I had flown home.
I did not, at the time, think of this as the most formative thing I would do in my career. It felt like a service obligation: a thing that had to be done so that the real work could proceed. Looking back, it was the real work. It is where I learned what understanding something actually means, and how little of what I thought I understood would survive a room full of people with reasons to test it.
The room, again
The format was unforgiving in a way that no internal review ever is. You stand in front of eight or ten engineers who have read your documentation and found it wanting. You explain how a piece of the system works. Someone asks a question that reveals they have understood your explanation perfectly and found a case where it doesn't hold. You have two options: answer, or admit you can't. There is no third. You cannot defer, delegate, or look it up. And there is always a next session, with the same people, who remember exactly what you said yesterday.
What this does, within a few sessions, is strip your understanding down to what is actually load-bearing. Every "it works like this" that is only mostly true gets a follow-up that exposes the part that isn't. Every simplification you've been relying on gets tested against a real case. Every piece of knowledge you had organized around how the thing was built gets reorganized, forcibly, around how it behaves — because that is the only thing the audience cares about.
I came out of those years knowing the system far better than I had going in, and I had not touched a line of its code in the meantime. That is the part worth explaining.
Two kinds of understanding
There is the understanding of the person who built something. It is deep, and it is organized around construction: the internals, the history, the trade-offs that were made and why, the parts that are elegant and the parts that are held together with apology. If you ask this person how the system works, they will tell you how it was made.
And there is the understanding required to explain the same system to someone who shares none of your assumptions and cares only about what it does for them. This is organized around behaviour: what goes in, what comes out, what happens at the edges, what the guarantees are and where they stop. If you ask this person how the system works, they will tell you what it will do to you.
The second kind is harder to acquire than the first, and — this is the uncomfortable part — having the first does not give you the second. Builders routinely cannot explain their systems to users. Not because they are bad communicators, but because their knowledge is shaped wrong for the task. It is indexed by structure, and the user's questions are indexed by consequence. Translating between the two is real work, and most people never do it, because nothing forces them to.
The hostile audience forces it. That is its whole value.
Why peers don't count
It matters that the audience was not my peers. Explaining something to people who share your vocabulary and context is easy, and it teaches you almost nothing, because the gaps get filled in silently on both sides. You say "and then it reconciles," they nod, and neither of you notices that you mean slightly different things by "reconciles" — until production notices for you.
Explaining the same thing to people who challenge you from the perspective of use, not of construction, removes the silent filling. They don't know what you mean by "reconciles," and they are not going to pretend. So you have to say what actually happens, step by step, and somewhere in the saying you discover that you weren't entirely sure yourself. Whatever survives that process is what you actually understand. Everything else was shared assumption wearing the costume of knowledge.
What I do with this now
I have carried the lesson into every role since, and it has changed how I evaluate understanding — in others and in myself.
When I want to know whether someone really understands a design, a decision or an architecture, I don't ask for a document. Documents can be assembled. I ask them to explain it to someone who will push back — ideally someone who has to depend on the thing and doesn't yet trust it — and I watch what happens at the first hard question. People who understand get more precise under pressure. People who don't get more abstract. The tell is almost never wrong.
When I want to know whether I understand something, I try to explain it to the least sympathetic competent listener I can find, before I'm ready. If I can't, I've learned something important and cheap. If I can, I've usually learned something anyway, because the act of explaining reorganizes what I know into the shape that actually matters.
And when I'm reviewing a system I didn't build, the first thing I look for is whether anyone can explain it in terms of behaviour rather than structure. If the only people who understand it are the people who built it, and they can only describe it as they built it, the system is not finished — regardless of what the status report says. It is a construction that nobody has yet turned into knowledge.
On authority
The last thing those years changed is how I think about technical credibility. I used to assume it was accumulated in private — you learn, you build, you get good, and at some point the world notices. It doesn't work that way, and I'm not sure it ever did.
Credibility is built by exposing what you know to people who have reasons to test it, and correcting it every time the test fails. It is a public process, not a private one, and it is uncomfortable in exactly the proportion that it is useful. The people whose technical judgement I trust most are, without exception, people who have stood in a lot of rooms like the ones I'm describing and come out of them with less certainty and more knowledge. That trade is the whole thing. I didn't understand it until I'd had to teach it.