On Being Wrong, Uncertain, and Slow

Have you ever watched someone argue passionately for a bad idea, not because they believed in it, but because changing their mind felt like losing? I’ve been that person. And over time, I realized I needed a better way to think.

These are the principles I now try to follow when I think, argue, and make decisions. I do not always get them right. But they remind me of the kind of thinker I want to be.

Being Wrong Is Not the Problem

Being wrong, feeling unsure, or feeling embarrassed about your opinion are not signs of weakness. They are signs that you are actually thinking.

When someone gives a better argument, a good thinker changes their view. That is not weakness. That is how people grow.

In my experience, the engineers who fight hardest to protect their technical opinions are often the ones who are least familiar with the topic. They shut out better solutions because they are protecting their ego, not looking for the best answer.

I have seen this in code reviews, in architecture discussions, in debates about tools and frameworks. Someone proposes an approach, gets pushback, and digs in not because they have a strong reason, but because changing their mind feels like losing.

Being wrong is not the problem. Refusing to change when you are wrong is the problem.

Doubt Without Direction Is Just Noise

There is a difference between healthy doubt and just being negative:

• Healthy doubt says: “I’m not sure this approach is right, let me look into it.”
• Being negative says: “I don’t think this will work” and stops there, without any real reasoning behind it.

I want to actually understand first before I form a strong opinion about a framework, a design pattern, or a technical decision. That means reading the docs, trying it out, and accepting that some things are more nuanced than they look from the outside.

One thing to note: this does not mean you need to be an expert before you can have an opinion. It just means you should be honest about how much you actually know and speak from that place.

Not Knowing Is Fine. Pretending to Know Is Not.

This one took me a long time to accept.

Saying “I don’t know” used to feel like failure. As a software engineer, I felt like I was supposed to have the answer. So when someone asked me something I did not know in a meeting, in a code review, in a technical discussion, I would fill the gap with something that sounded right but was mostly a guess.

This is dangerous. A confident wrong answer can send a team down the wrong path for days.

The engineer who says “I don’t know, but I’ll find out” is more trustworthy than the one who confidently gives a wrong answer.

Now I think about it differently. Nobody can know every language, every framework, every system. Technology moves too fast.

Saying “I don’t know” is not weakness. It is honesty and in software, honesty saves time.

Slow Down to Actually Go Fast

There is a common illusion in software development that moving fast means getting things done faster. Most of the time, it does not.

I have jumped into writing code before I fully understood the problem many times. I would skip reading the existing code, skip asking clarifying questions, and just start building. What felt like saving time ended up costing more because I had to rewrite the feature, fix bugs that came from wrong assumptions, or undo decisions I made too quickly. One hour saved at the start sometimes meant three extra days at the end.

Taking time to understand the problem before writing the first line of code is usually the fastest path to a working solution. Going slow at the start means less rework later.

Speed that comes from understanding beats speed that comes from rushing.

---

My principles are evolving, and these are what currently drive my thinking. They are commitments to stay curious, stay honest, and keep learning.

If you have your own thinking principles, I would love to hear them.

Thank you for reading 👋