- Introduction
- Confirmation Bias
- Anchoring Bias
- Dunning–Kruger Effect
- Sunk Cost Fallacy
- Overconfidence Bias
- Final Thoughts
Introduction
Hey everyone! So I’ve been into cognitive biases for a while now — those little mental traps that mess with how we think and make decisions. And recently I thought: wait a second… if we're all wired this way, then these biases must be sneaking into our coding too, right? Turns out, they do. Big time. So I did a bit of digging, and here’s what I found — a list of the most common cognitive biases that show up when we write, test, and debug code (sometimes without even realizing it).
Confirmation Bias in Coding
The tendency to interpret new evidence as confirmation of one's existing beliefs or theories.Ever written some code, ran one test, saw it work… and moved on? Yeah — that sound like confirmation bias.
It’s when we look for proof that our code works, instead of trying to break it.
For example:
“I just wrote an Unit Test and it works fine. ”
But reality? You just proved it works in one case. You didn’t prove it can’t fail in five others.
How to fight it:
Write tests that challenge your code, not just validate it.
Try weird edge cases. Intentionally break inputs.
Ask teammates to review it — fresh eyes catch what you’re blind to.
Anchoring bias
The anchoring bias is a cognitive bias that causes us to rely heavily on the first piece of information we are given about a topic.Say you estimate a task will take 3 hours.
Even if it's clearly bigger, your brain keeps trying to make it fit that 3-hour anchor.
Or you pick a certain library early on, and then force the rest of the architecture to bend around it — even when better options show up later.
Example:
“Well, I already started with X, so I’ll just keep going…”
How to fight it:
Revisit early decisions with fresh eyes — especially after you learn more.
Ask yourself: Would I make the same choice if I was starting from scratch today?
Share estimates with a team before committing.
Ask teammates to review it — fresh eyes catch what you’re blind to.
Dunning Kruger effect
The Dunning–Kruger effect is a cognitive bias in which people with limited competence in a particular domain overestimate their abilities.When you’re new to coding, it’s easy to think you know way more than you actually do.
That’s the Dunning-Kruger Effect — beginners feel overconfident, while seasoned devs tend to underestimate themselves.
Example:
“I can totally build this feature in one afternoon!” — newbie ( I had this :D )
“Maybe I’m not that great...” — experienced dev
How to fight it:
Keep in mind that confidence grows with experience, as well as awareness of what you don't know.
Sunk Cost Fallacy
The phenomenon whereby a person is reluctant to abandon a strategy or course of action because they have invested heavily in it, even when it is clear that abandonment would be more beneficial.Ever spent hours or days writing a feature or refactoring code that just isn’t working—and felt like you can’t stop or start over because you’ve already put so much into it? That’s classic sunk cost fallacy.
For example:
“I’ve already written 200 lines of code on this, so I can’t just throw it away now.”
But sometimes, the best move is to cut your losses and start fresh, no matter how much time you’ve already spent. ( Or ask for colleague support )
How to fight it:
Ask yourself: If I were starting today, would I still build it this way?
Be willing to delete or rewrite code that’s not working.
If past effort is gone — don’t let it trap your future decisions.
Overconfidence Bias
Overconfidence bias is a type of cognitive bias that causes us to think we are better in some areas than we really are.Ever thought, “This is a tiny change, no need to test it” — only to have it break something in production later?
That’s overconfidence bias.
For example:
“It’s just one line, what could possibly go wrong?”
But small changes can have big consequences if you don’t double-check.
How to fight it:
Review your changes carefully, don’t skip the checklist.
Assume your future self might forget details — leave comments or documentation.
Stay humble about what you think you know.
Final Thoughts
That’s it for now! I hope you learned something new and useful today.
Keep an eye out for these mental traps next time you code — it can make a real difference.
Wishing you a smooth and bug-free day!