Confirmation Bias in Tech: Why We Choose Solutions Before We Understand Problems
Confirmation bias, the tendency to seek out evidence that supports what we already believe and dismiss anything that challenges it, is part of being human. We all carry it. We all act on it, often without realizing it. But as technologists, we like to think of ourselves as rational, evidence-driven people. We deal in logic, in systems, in reproducible outcomes. Surely we’re above the petty cognitive shortcuts that trip up everyone else.
We are not. And the consequences of pretending otherwise show up in production codebases every single day.
What Is Confirmation Bias, Really?
At its core, confirmation bias is the mind’s way of protecting its existing investments – sounds like a bit of sunk cost added in. Once you’ve formed a belief, or spent three years mastering a particular framework, your brain becomes a remarkably efficient filtering system. Evidence that supports the belief gets amplified. Evidence that challenges it gets quietly deprioritized, reframed, or discarded entirely. You’re not lying to yourself. You’re just… curating.
The insidious part is that it doesn’t feel like bias. It feels like experience. It feels like pattern recognition. It feels like knowing what you’re talking about. And sometimes it is those things. The problem is that from the inside, wisdom and rationalized preference feel identical; which means you can’t tell the difference without doing the uncomfortable work of actually stress-testing your assumptions.
Most people skip that work. It’s not fun. It doesn’t feel productive. And it carries the terrifying risk of discovering you might be wrong about something you’ve been confidently recommending for years.
The Framework Trap
Let’s make this concrete. Ask a front-end developer which library or framework to use for a new project. Before they ask a single question about requirements, team size, expected scale, maintenance burden, or timeline, there’s a good chance you’ll already have your answer. And that answer will, with remarkable consistency, be whatever they happen to know best.
A React developer will say React. An Angular developer will say Angular. A Vue devotee will mention that actually, have you considered Vue? The recommendation materializes instantly, confidently, and entirely independently of any information about the actual problem being solved. It’s almost impressive.
And when you push back, when you have the audacity to ask why this particular tool is the right fit for this particular situation, the justifications come rolling out. “React has the largest community.” “Angular is enterprise-grade.” “It’s the most downloaded library in the ecosystem.” These are facts. Real, verifiable, technically-accurate facts. They are also almost entirely beside the point.
“Most downloaded” does not mean “most appropriate for your use case.” It means a lot of people are using it, many of them for reasons that have nothing to do with your requirements. Popularity is a proxy metric, and a fairly weak one at that. But it sounds authoritative, it’s easy to look up, and it conveniently supports the conclusion that was already reached before the conversation started.
This is confirmation bias doing what it does best: arriving at the destination first and then constructing a plausible-looking route to justify the journey.
The F-150 Problem
Here’s an analogy that might sting a little. The Ford F-Series pickup truck has been the best-selling vehicle in the United States for over 4 decades. 40+ consecutive years at the top of the sales charts. By the logic we routinely apply to technology choices, “it’s the most popular, therefore it must be the right answer,” the F-150 should be the obvious vehicle recommendation for every single person who needs a car.
Need to commute twenty minutes to an office in a dense urban neighborhood? F-150. Live alone and park on the street in a city where spaces are approximately the width of a yoga mat? F-150. Care deeply about fuel efficiency and your carbon footprint? F-150. Have never once in your life needed to tow anything larger than a bicycle? Congratulations, have you considered the F-150?
Obviously this is absurd. The F-150 is a genuinely excellent truck that is perfectly suited to a specific set of use cases: hauling things, towing things, driving on terrain that would destroy a sedan, and projecting a particular image in certain parts of the country. For many people, it’s exactly the right vehicle. For many others, it’s an expensive, oversized, fuel-consuming mismatch for their actual needs.
The most popular option is not the same as the right option. These are different concepts and it’s somewhat embarrassing that we have to keep re-explaining this. Yet in technology conversations, we collapse them constantly. Because the popular option is the one we already know, the one we already know is the one we’ve already decided to recommend.
Why This Actually Matters
This might all seem like a minor inefficiency. A developer recommends a familiar tool, the team builds with it, the product ships. So what’s the problem?
The problem is usually quiet and slow. It’s the startup that built a heavyweight enterprise framework for a 3-person team and is now drowning in architectural overhead that serves no one. It’s the client who needed a lightweight, maintainable solution and got a monument to the lead developer’s resume instead. It’s the 6 months of onboarding friction because the technology chosen wasn’t what the team actually knew, it was what the loudest voice in the room knew. It’s the rewrite 2 years later that everyone saw coming except the person who made the original decision.
We like to talk about serving our clients and users. We like to talk about making sound technical decisions. Confirmation bias is quietly, persistently incompatible with both of those things. And the fact that it feels like expertise while it’s happening makes it considerably more dangerous than ignorance would be. At least with ignorance, you know you don’t know. Confirmation bias comes with its own confidence included.
How to Actually Do Better
The good news is that confirmation bias isn’t a personality flaw. It’s a cognitive pattern, and cognitive patterns can be interrupted – if you’re willing to be deliberate about it. A few habits that genuinely help:
Ask before answering.
This should be obvious and yet it apparently needs to be said: no technology recommendation should precede a clear understanding of the requirements. Not a rough understanding. Not an assumed understanding based on past projects that seemed similar. An actual understanding, arrived at by asking actual questions and listening to the answers. If your recommended solution is the same regardless of what the requirements turn out to be, that’s not experience talking – that’s bias.
Deliberately look for reasons your default might be wrong.
Finding evidence that your preferred solution works is easy and essentially meaningless. Your brain will do that for free without any effort on your part. The useful exercise, the one that takes real discipline, is to actively seek out its failure cases. Where has this approach broken down? What kinds of problems does it handle poorly? What would a smart person who disagrees with you say, and can you actually refute it? That discomfort is not a sign that you’re doing something wrong. It’s a sign that you’re doing something right.
Broaden your circle and mean it.
Surrounding yourself with people who think differently. Different technical backgrounds, different philosophical approaches, different relationships with whatever the current consensus happens to be is one of the most effective ways to interrupt an echo chamber. But only if you actually listen to the disagreement rather than waiting for your turn to explain why they’re mistaken. A diverse team that gets steamrolled by the most senior voice in the room is just a homogeneous team with extra steps.
Stay genuinely curious about approaches you don’t use.
This doesn’t mean you need to become a generalist who refuses to commit to anything. It means understanding the landscape well enough that your recommendations are actually informed. Read the case studies from teams who chose differently. Understand not just what competing solutions do, but why thoughtful people chose them. You don’t have to agree. You do have to understand.
Question your certainty proportionally to how comfortable it feels.
The recommendations that feel most obvious, most natural, most like common sense are precisely the ones most worth interrogating. Certainty that requires no effort is usually borrowed from somewhere – from habit, from familiarity, from the last ten projects that happened to be similar enough that the pattern held. That’s not a reason to abandon the recommendation. It is a reason to verify it.
The best technical decisions start with questions, not answers. The uncomfortable truth about confirmation bias is that the beliefs most worth scrutinizing are the ones that feel the least like beliefs. The ones that feel like obvious facts, like settled knowledge, like things only a fool would question. Those are exactly the ones to question first.
