The Best Engineers I Know Are Wrong a Lot

There is a version of technical excellence that most people imagine when they picture a great engineer. They picture someone who looks at a problem and immediately knows the answer. Who proposes a solution in a meeting and turns out to be right. Who writes code that does not need to be revisited. Who builds things that work the first time.

I have met a small number of engineers who are occasionally like this. I have never met one who is like this consistently, across all problems, across all contexts.

What I have met, many times, are engineers who are genuinely excellent at their work and who are wrong quite often. They propose solutions that do not work. They make predictions that do not come true. They build things that need to be rebuilt. And somehow, despite being wrong regularly, they are the people everyone wants on their team, the people organisations build around, the people who produce the best outcomes over long periods of time.

Understanding why requires looking at what actually separates the engineers who progress from the ones who stall. It is not accuracy. It is what they do with inaccuracy.

Being wrong fast is a skill

When most people are wrong about something, there is a delay before they know it. They have a theory about why a system is behaving strangely. They investigate in the direction of that theory. They gather evidence that supports it and discard or explain away evidence that does not. Eventually they are forced by reality to accept that the theory was wrong, usually after having spent significant time in the wrong direction.

The best engineers I know have compressed this delay to almost nothing.

They form the hypothesis. They identify the fastest possible way to test it. They run the test. If the test fails, they do not defend the hypothesis. They discard it and form the next one. The emotional attachment to the theory is absent, or at least very weak. The theory was a tool for navigating toward the answer, not a position to be defended.

This sounds simple. It is not simple to do. Every person has a natural tendency to become attached to the explanations they have generated. The explanation feels like part of you, a product of your intelligence, and being wrong about it feels like being wrong about yourself. Separating the hypothesis from the self, so that discarding the hypothesis requires no self-correction, is a mental habit that takes years to develop.

The engineers who have developed it are dramatically faster at solving problems than the ones who have not, for a simple reason: they do not spend time defending wrong answers. Every minute not spent defending a wrong answer is a minute spent moving toward the right one.

The question that reveals everything

There is a question I have started asking when I want to understand how good an engineer actually is. Not about their technical knowledge. Not about their experience. This question:

Tell me about a technical decision you were confident about that turned out to be wrong.

The responses to this question separate engineers into two groups very clearly.

The first group struggles to answer. They eventually produce a story about a mistake that was small, recent, and quickly corrected. Something with no significant consequences. Something that could almost be reframed as a success. The story is told carefully, with qualifications that explain why it was understandable to be wrong given the information available.

The second group answers immediately and talks for a long time. They have multiple stories. The stories involve real consequences. They can tell you not just what was wrong but why they thought they were right, what the evidence looked like from the inside, at what point the first doubt appeared, and what they learned that they have not forgotten.

The first group is not less intelligent than the second. They are less honest with themselves about being wrong, which means they learn less from it when it happens. The second group has made being wrong a normal part of how they think about their work, which has turned every mistake into a lesson that actually stuck.

What confidence is actually for

There is a misunderstanding about confidence that runs through the culture of software engineering. Confidence is treated as a signal of competence. The person who speaks with certainty is assumed to know more than the person who qualifies their statements. The engineer who says “this will work” is taken more seriously than the one who says “I think this will work, and here is what I would check to confirm.”

This is backwards.

Certainty about complex systems is almost always a sign that someone has not thought carefully enough about the ways they might be wrong. Complex systems are genuinely uncertain. They have unexpected interactions. They behave differently under conditions that were not anticipated. The engineer who is certain has usually simplified the system in their mind to the point where certainty is possible, which means they have removed the complexity that is most likely to cause them problems.

The appropriate relationship with confidence in engineering work is something closer to: I have thought about this carefully, I believe this is right for these specific reasons, and I am aware of these specific conditions under which I would expect to be wrong.

This is a much more useful statement than either “I am certain” or “I have no idea.” It tells you what the person knows, what they have thought about, and where to look if things go wrong. The uncertainty is not a weakness in the position. It is the most honest and therefore most useful part of it.

The best engineers I know communicate this way. They are confident in their reasoning without being certain of their conclusions. They tell you what they think and why, and they tell you what would change their mind. Working with them is easy because you always know exactly where you stand with them.

The approval trap

There is a specific failure mode that derails a lot of talented engineers, particularly early in their careers. I think of it as the approval trap.

In the approval trap, an engineer’s primary motivation in technical discussions is to be seen as right. Not to find the right answer. To be seen as right. These are related but importantly different goals. Finding the right answer requires being willing to be wrong. Being seen as right requires defending positions even when they are not working out.

The engineer in the approval trap defends their proposals in meetings even after they have stopped believing in them, because changing position feels like an admission of weakness. They dismiss other people’s concerns quickly, because taking them seriously might require updating their position, which might signal uncertainty. They avoid difficult technical questions because a wrong answer in front of others feels more costly than no answer.

The approval trap is a self-defeating strategy because the engineers who are most respected are not the ones who are always right. They are the ones whose judgment can be trusted. And the most reliable signal of trustworthy judgment is not a track record of correct predictions. It is a track record of engaging honestly with uncertainty, of changing position when the evidence changes, of being more interested in the outcome than in the credit.

An engineer who changes their mind publicly when presented with new information is demonstrating the most important form of intellectual confidence: the confidence to not need to be right.

The thing about admitting you do not know

Most professional environments punish admitting ignorance. Questions you cannot answer in a meeting feel like failures. Gaps in your knowledge feel like weaknesses to be hidden. The instinct is to produce some plausible-sounding answer rather than to say clearly that you do not know.

Engineering is one of the few professional contexts where this instinct is particularly dangerous.

In software systems, a confident wrong answer is worse than an honest admission of uncertainty. A confident wrong answer gets acted on. A confident wrong answer becomes the basis for the next decision, which becomes the basis for the decision after that, and by the time the original error is discovered the team has built a significant structure on a faulty foundation.

The engineers who say “I do not know” freely are doing the team a service that the engineers who never admit ignorance are not doing. They are providing an accurate map of where the known territory ends and the unknown begins. They are making it safe for others to admit the same. They are preventing the confident wrong answer from taking root.

I have watched teams where nobody says “I do not know” very long. They make confidently wrong decisions and then spend significant time and money cleaning up the consequences. I have watched teams where admitting ignorance is normal and expected. They make fewer confidently wrong decisions and more good ones, because the uncertainty is acknowledged and investigated rather than papered over.

Changing your mind in public

There is a scene that plays out in engineering discussions regularly. Someone proposes an approach. Someone else raises a concern. The original proposer defends the approach. The concern turns out to be valid. The original proposer is now in a position where they can either acknowledge that the concern was right and update their position, or they can continue to defend a position they no longer fully believe in.

Most people, most of the time, choose the second option. Not because they are dishonest. Because changing your mind in public feels exposing in a way that is hard to do gracefully.

The engineers who are best at this have figured out that changing your mind publicly is not a weakness. It is a demonstration of something that is genuinely rare and genuinely valuable: the ability to let the conversation produce a better answer than you arrived with.

When someone says “that’s a good point, I was not thinking about that constraint, I think you’re right” in a technical discussion, they are doing something that looks like losing and is actually winning. The discussion has moved forward. Everyone in the room has learned something about how the person engages with disagreement. The relationship between the two engineers has been strengthened rather than damaged, because the person who raised the concern had it taken seriously rather than defended against.

The engineers who do this consistently become the people everyone wants in design discussions. Not because they always have the best initial proposals. Because discussions with them produce better outcomes than discussions without them.

Learning from being wrong

The difference between being wrong and learning from being wrong is not automatic. It requires something specific: a genuine examination of why you believed what you believed before being proven wrong.

Most post-mortems, whether formal incident reviews or informal personal reflection, focus on what happened and what to do differently. The more useful question is why it looked right from the inside before it turned out to be wrong. What was the evidence you had? What was missing from the picture? What assumptions were you making without realising you were making them?

This is a harder question to answer than “what went wrong” because it requires reconstructing a past mental state accurately enough to understand why it was mistaken. But it is the question whose answer is most transferable to future situations. “We did not test this edge case” is a lesson that helps you avoid that specific edge case next time. “I assumed that any input from the internal API would be well-formed because I did not consider that the internal API could be called with user-generated content” is a lesson about a class of assumptions that will help you in every future situation where you are reasoning about trust boundaries.

The engineers who accumulate the most useful lessons from being wrong are the ones who go back to the moment before they knew they were wrong and understand it clearly. Not to punish themselves. To build a more accurate model of how their own thinking fails, so they can catch it earlier next time.

The reputation that actually matters

Engineering careers are built on reputation, and reputation is built on outcomes. The engineers who produce good outcomes over long periods of time end up with opportunities and influence that the others do not.

The thing that produces good outcomes over long periods of time is not being right all the time. Nobody is right all the time. It is having a reliable process for getting to good answers even when you start from wrong ones. Being wrong fast. Saying “I do not know” when you do not know. Changing your mind when the evidence changes. Examining your mistakes carefully enough to not repeat them.

The engineer who does these things ends up right more often than the one who defends their positions, hides their uncertainty, and learns less from being wrong. Not because they are more intelligent. Because they have built a feedback loop that continuously improves their judgment, while the other engineer has built a feedback loop that protects their self-image at the expense of improvement.

This is the thing that takes years to understand and that is almost impossible to teach directly. The engineers who figure it out early progress faster than their equally talented peers and cannot always explain why. The engineers who never figure it out plateau at a level where their technical skill carries them but their judgment does not compound.

Judgment compounds when you let yourself be wrong. When you examine the wrongness rather than explain it away. When you update your model of the world rather than your story about why the world was unusually difficult this time.

The best engineers I know are wrong a lot.

They are also the most trustworthy people I have ever worked with, because their goal has never been to appear right.

It has always been to get it right.

Those are not the same thing, and the difference between them is everything.