Those Who Know Nothing, Doubt Nothing

The most confident answers I've heard in technical discussions have, on average, been the least reliable ones. Not because confidence is wrong, but because genuine familiarity with a problem tends to produce visible hesitation. You've seen enough edge cases to know which ones might be hiding.

This is Dunning-Kruger from the inside, which is a less comfortable angle than the usual version. The usual version is about other people: they overestimate their competence because they don't know enough to see what they're missing. That's easy to talk about. The harder observation is that the phenomenon also describes you, at some earlier point in your career, and that you probably didn't notice it at the time.

I was more certain about my technical opinions at year three than I am now. That's not because I've gotten worse at forming opinions. It's because I've been wrong enough times to have a more honest prior.

What certainty actually indicates

When someone in a meeting gives a fast, confident answer to a hard question, there are a few possibilities. They know the domain well and the answer happens to be simple. They don't know enough to see why it isn't. Or they've learned to project confidence regardless of actual certainty, because rooms tend to reward it.

The signal you want isn't confidence. It's whether the person can articulate what would change their answer.

An engineer who says "probably X, but I'd want to check the write volume on that table before committing" is more useful than one who says "definitely X." The qualification isn't weakness. It's them telling you they've seen this matter before.

Someone who says "definitely X" with no qualifications either knows something is settled and simple, or doesn't know what they don't know. You can usually tell the difference by asking a follow-up question. If they can explain the constraints and where the answer changes, it's the first case. If the confidence holds steady regardless of what you ask, it's the second.

The internal experience

The experience of knowing a domain well is that you start to see more of the space. At year one, a question has an answer. At year ten, the same question has an answer plus a set of conditions under which that answer is wrong. Those conditions make you more accurate but slower to answer, and in rooms that reward fast answers, that reads as uncertainty.

I've watched junior engineers out-confident senior ones in meetings and walk away with the action item, then build the wrong thing because they didn't see a constraint that was two questions deep. The senior engineers were right. They just didn't speak with enough conviction to carry the room.

That's a failure mode worth naming. The hesitation that comes from expertise is not the same as not knowing.

Building judgment about your own uncertainty

The useful skill is distinguishing between "I'm uncertain because I haven't thought about this" and "I'm uncertain because I've thought about it enough to see the edges." Both look like uncertainty. Only one is carrying information.

A practical test: if your uncertainty disappears after five minutes of thought, it was probably the first kind. If it gets more specific after five minutes, meaning you can now say exactly what you'd need to know to reduce it, it's the second kind.

The second kind is the one to communicate. "I'm not sure" is incomplete. "I'm not sure because I don't know how often that column is written to" gives someone something to go find out.

Your certainty at any given moment is a function of how much you've seen. That doesn't mean don't have opinions. It means hold them with appropriate grip, and know the difference between the grip that comes from shallow confidence and the grip that comes from having seen this fail before.

The people worth listening to in a room are usually the ones who tell you what they'd need to know to be wrong.