Be Willing to Change Your Mind
November 19, 2022
Photo by tabitha turner on Unsplash
I heard something not too long ago that stopped me in my tracks. I was listening to a podcast while doing some yard work. The guest on the show was an author who had recently unpublished a book of theirs, citing it has caused more damage than good. They had come to realize their stance on an issue was wrong.
The host said something profound. “You changed your mind!” she exclaimed. “Do you know how rare that is today?”
It’s true. Humans are often unwilling to change their minds on many things. We get entrenched in our opinions often without being open or willing to listen to another perspective. Unfortunately, software engineers are some of the least likely people to change their minds; I’ve been one of them. We learn to think so critically and deeply about complex ideas that it is hard to shift them once we make our conclusions.
However, growth and learning are often predicated on being willing to change - or at least morph - our understanding of the world. We will only learn if we are willing to change and challenge our current mental models.
Why Don’t We Change Our Minds?
If changing our minds is foundational to learning and growth, why are we so resistant to it? I think there are a few reasons.
First, engineers have subtly been trained not to do so. Our industry has long touted the phrase “strong opinions loosely held” which has enforced the need for engineers to create a strong opinion - even on things they don’t care about. It sounds good at first, but it often becomes a way for engineers to use passion and intensity as a means to get their idea accepted, regardless of whether it’s the best idea in the room. The louder you are, the more right you must be.
Second, changing our minds often feels like admitting were aren’t good enough. Putting our own idea down to prefer someone else’s idea feels embarrassing. We start to think we can’t cut it as an engineer. It’s imposter syndrome all over again.
Last, we are afraid that changing our minds means we are weak leaders. We are worried that if we admit we were wrong about something, we will lose our credibility or following (as if we had one anyway). Or perhaps we fall prey to the sunk cost fallacy touting that “we’ve already come this far.” Leaders are often more willing to ruin their culture and credibility rather than admit they were wrong about something and then course correct. These are legitimate concerns, to be fair. It is challenging to admit being wrong or to be willing to take a fresh perspective on something. To learn, though, we have to be willing to do so.
Toolboxes vs. Multi-tools
One way I’ve become more willing to change my mind is by focusing on collecting tools for my toolbox rather than trying to find the perfect multi-tool.
There are many different tools in a toolbox, each with unique capabilities. Almost every time I’ve needed to build something (outside of an Ikea shelf), I need several of those tools in the box. If I was missing just one of those tools, I wouldn’t be able to finish the task.
The same thing happens in software. Knowing different languages, patterns, and processes will allow teams to find the right solutions for their problems. Teams should be collecting tools rather than trying to find a perfect one-size-fits-all approach.
However, I focused on doing just that for a long time. Instead of collecting tools, I tried to find the perfect multi-tool to do everything. I thought I would have all I needed if I could only find one with a sharp enough knife and the correct combination of screwdriver widgets.
The problem was I kept coming up short with every “multi-tool” I bought. No process was perfect, and no pattern would fit every scenario. But still, I kept looking for the fabled ideal solution. I also noticed that even though I knew these tools were coming up short, I would quickly defend them. I had sunk so much time into picking the “perfect multi-tool” that I was much more zealous in defending it, which is silly if you think about it.
By building a toolbox, I’m more willing to put down a tool that isn’t working in favor of another. I’m also much more willing to replace or supplement my existing tools with new ones rather than searching for a singular perfect tool to replace my entire toolbox.
Good, Better, and Best
Another helpful way I’ve been rethinking how and when to change my mind is by remembering that not everything is a right or wrong decision. Many ideas fall along a spectrum of good, better, and best.
This is especially true in software engineer. We often have an array of options to choose from when faced with a problem. The solutions we come up with are rarely entirely wrong, but there will likely be better ideas too. There will also be worse ideas, but even those ideas aren’t wrong either.
If we approach these decisions with a mindset of right vs. wrong, we are likely to miss the best solution. We’ll be so focused on defending our idea that we won’t listen to other solutions - even when they are extensions of our own idea!
This happened to me not too long ago. I had spent a lot of time thinking about a solution to a problem, and I was optimistic it would work really well. During a design session, one of my teammates threw out an idea that was pretty aligned with what I had thought about already, but I was so convinced I was right that I didn’t pay attention. It wasn’t until the next day that I realized, “oh, that is a much better idea!” 🤦
Let’s practice willingness to change our minds. Let’s bring humility to the table when discussing trade-offs with our teams. We don’t have to change our minds on everything either. When you have an idea worth advocating for, advocate, for it!
The point is we need to be willing to. We must be reflective and humble enough to question our conclusions and opinions. We need to let go of bravado and be willing to come to the table admitting we were wrong about something. It takes strength to do those things. But we won’t reach our full potential until we do.
Happy coding!
If you enjoyed this article, you should join my newsletter! Every other Tuesday, I send you tools, resources, and a new article to help you build great teams that build great software.
Dan Goslen is a software engineer, climber, and coffee drinker. He has spent 10 years writing software systems that range from monoliths to micro-services and everywhere in between. He's passionate about building great software teams that build great software. He currently works as a software engineer in Raleigh, NC where he lives with his wife and son.