If You Can’t Explain It, You Don’t Fully Understand It
4/1/2026
This week we’re going to continue with our discussion of what I would do if I was trying to break into tech in 2026. When I first learned to program, I didn’t spend much time on theory.
I learned the way a lot of people do. I looked at what good engineers were doing, copied the patterns, and used them in my own code. If it worked, I kept doing it. If it didn’t, I adjusted until it did.
And it worked.
For example, I got into the habit of putting services behind interfaces. I saw other engineers doing it, so I did it too. My code stayed organized, things were easier to swap out, and everything generally worked the way I expected.
For a long time, I had no idea why I was doing it. I didn’t think that mattered. As long as it worked that’s all I needed.
That assumption held up until I started interviewing.
In one interview, I was asked what the Task type does in C#. It’s something I had used constantly. I had written async code many times. But when I had to explain it clearly, I struggled.
I didn’t want to say something incorrect, so I hesitated and gave a weak answer.
Later in the same interview, we moved to a coding exercise. I used async and await without thinking about it. It was second nature at that point.
The interviewer noticed and asked why I couldn’t explain something I was clearly able to use.
That moment stuck with me.
What I realized is that there are two different kinds of knowledge in programming.
There’s knowing how to use something.
And there’s knowing how to explain what it is, why it exists, and what problem it solves.
For a long time, I relied heavily on the first one.
That’s how a lot of developers learn. You pick up patterns that work and build intuition over time. There’s nothing wrong with that.
But eventually you hit situations where that isn’t enough.
- You need to explain your decisions to another engineer
- You need to adapt a pattern to a new situation
- You need to debug something that doesn’t behave the way you expect
That’s when the “why” starts to matter.
Looking back, I don’t think the mistake was learning through patterns.
The mistake was waiting too long to connect those patterns to the underlying concepts.
Things like:
- Why use an interface here?
- What problem does this pattern solve?
- What do other engineers call this idea?
Those questions turn something you can do into something you actually understand.
If I were starting today, I would still build things the same way. I would still copy patterns from good engineers and get things working.
But I would add one step much earlier.
I would regularly pause and ask:
- What is this pattern doing?
- Why does it exist?
- When is it useful?
- How would I explain it to someone else?
Not in perfect academic language. Just clearly enough that another engineer would understand.
Theory doesn’t matter because it’s academic.
It matters because it helps you explain, adapt, and reason about what you’re building.
And once you can do that, you’re not just following patterns anymore.
You’re making decisions.
If you can use something but can’t explain it, you’re probably closer than you think.
You just haven’t connected the dots yet.
Start doing that earlier, and everything else gets easier.