I was watching a video not that long ago about an archaeological site that probably most of us have heard about. The researchers had reached a new conclusion based on new evidence. They’d had the date of a major event wrong, so they went back and revisited some old assumptions and then proceeded to explain how the old incomplete information had led them to a wrong conclusion.
That’s not unusual. It is in fact, how science and engineering are supposed to work.
It reminded me of something I’ve noticed throughout my career as a software developer and software engineer.
The ocean of things you do not know
But let me back up a bit. Growing up, I was surrounded by a way of thinking that treated being wrong as a mark against your credibility and your experience. If you admitted you made a mistake, maybe you weren’t as trustworthy as everyone thought you were. As in “That person can be wrong, so why should we believe them?”
Science and engineering have taught me effectively the opposite.
The longer you’re an engineer or developer, the more you realize how much there is to know. When I started as a web developer, learning felt like stepping into a big creek. Before long I realized the flow of things to learn wasn’t really a creek at all. It was a river. Then a much bigger river. After a few years that river started feeling like a lake, and eventually even that lake began to feel a little like an ocean.
Every year reveals another layer of things you didn’t know you didn’t know.
At some point, though, how you think of things changes. It’s like you start understanding the contours of your own personal skill and knowledge island in that ocean.
Hopefully, by then you have realized that you don’t need to look like someone who knows everything because you have come to realize the impossibility of the task. What becomes far more important is understanding where the limits of your own knowledge and skills actually are.
That’s the real skill.
Can you clearly tell the difference between what you know, what you suspect, and what you simply haven’t learned yet? Better yet, can you communicate those boundaries honestly?
That takes a surprising amount of self-awareness, and I think it’s one of the defining characteristics of good engineering and a healthy engineering culture.
Reality matters more than ego
Good engineers should be comfortable saying things like, “I don’t know,” “I think I misunderstood,” “I was wrong,” or even, “I’m pretty sure that’s right, but let’s test it.”
None of those statements signal weakness to me. They tell me I’m working with someone who understands that reality matters more than ego.
Software has an inconvenient habit of exposing “certainty” that isn’t backed by evidence. Production bugs do not care how confident we sounded in a meeting, and users certainly don’t benefit because someone protected their reputation instead of revisiting an assumption.
Reality always gets the final vote.
That’s why I’ve never been comfortable when people describe this kind of openness and honesty as a communication style or a personality trait. I don’t think it is. I think it is a necessary part of the discipline.
Every engineer eventually reaches the edge of what they know. If you can’t acknowledge that, it becomes much harder to investigate honestly. And if you’re unwilling to admit a mistake or distinguish between what you know and what you merely suspect, you’re not protecting your credibility. I believe you are slowly making yourself less effective.
The best engineers I’ve worked with are not the ones who project absolute certainty. They’re usually the people with the clearest picture of where their knowledge ends. They know their strengths, they’re aware of their blind spots, and they don’t mind asking what might seem like a basic question if it gets everyone closer to the truth. Sometimes they ask the stupid question not because they don’t know the answer but because it helps facilitate a very necessary conversation.
I believe that is exactly what makes them trustworthy.
When admitting mistakes becomes political
Unfortunately, not every engineering culture functions that way. We are human after all.
There will always be folks that mistake certainty for competence. Someone who says, “I don’t know,” might be assumed to be inexperienced by folks not familiar with the discipline, while someone who has a confident opinion on everything can be assumed to be an expert.
The reality is almost always the opposite.
The people with the broadest experience usually have a much clearer understanding of the boundaries of their own knowledge because they’ve spent years discovering just how large the field really is.
That’s also why I think engineering cultures can begin to decay when admitting mistakes becomes political.
Once people start protecting narratives instead of searching for answers, learning slows down. Saying, “I don’t know,” starts feeling dangerous. Changing your mind starts looking like losing an argument instead of improving your understanding.
From there it’s a pretty short slide. People stop admitting the small mistakes because they’re worried about how they’ll be perceived, and before long they’re hiding larger ones too. Collaboration becomes more guarded. Discussions become performances instead of investigations. And the whole team can end up spending more energy protecting appearances than understanding reality.
The goal is to get it right
I’ve lost count of the number of times simply saying, “Sorry, that was me,” has saved hours of investigation. Instead of several engineers chasing ghosts through logs or disappearing down some obscure rabbit hole, everyone immediately knows where to start. A ten-second admission can save half a day of unnecessary work.
To me, that’s what psychological safety is really about. It’s creating an environment where people can say, “I think I got this wrong,” without worrying that honesty will be held against them.
Because the goal of engineering has never been to look like you’re doing things right.
The goal is to get it right.
Those are not the same thing.