✋ The 17 biggest mental traps costing software engineers time and growth

Bad estimates and flawed project decisions? Uncover 17 hidden thinking errors and learn to fix them for better code and team success

Jun 01, 2025

Software engineers often think of bugs as code-level mistakes. But some of the biggest problems in our careers come from mental errors, not syntax errors. These aren't obvious. They live in our decisions, judgments, and habits.

Cognitive biases and logical fallacies shape how we estimate tasks, judge others' work, choose tools, and learn from mistakes. If you don't spot them, they cost you time, mislead your thinking, slow your growth, and hurt people around you.

This post covers 17 biases and fallacies. Some are well-known. For others, I’m sure this is the first time you've hear them. Let me know which ones are new for you.

⭐ In this post, you'll learn

Why smart engineers make bad estimates and how to fix that
How to spot flawed thinking in code reviews, planning, and tech choices
Why engineers resist change even when it’s needed
How bias affects how we judge others and our own work
Practical examples of these errors in day-to-day work

🧠 #1 Planning fallacy

The planning fallacy is the tendency to underestimate how long a task will take, even when you've done similar tasks before.

Why it matters: This leads to missed deadlines and poor project planning. Engineers commit to tight timelines and end up working under pressure because they believe things will go smoothly.

Practical explanation: You might say a feature will take "a day or two" but forget the edge cases, integration, testing, and unexpected blockers. Even if the last three features overran by 40%, you still think this one will be different.

Projects go off track when teams don't account for reality. This bias isn't solved by experience alone. You need deliberate effort to add buffers and use past data, not gut feeling.

🔄 #2 The XY problem

The XY problem happens when someone asks about a solution (Y) instead of the actual problem (X) they’re trying to solve.

The XY Problem - Sketchplanations — source

Why it matters: Teams waste time solving the wrong problem. Discussions get stuck in unproductive directions.

Practical explanation: A developer asks, “How do I merge two JSON files in bash?” when the real problem is transforming a dataset. They get low-quality help because the question hides the context.

Good engineers ask clarifying questions. Don’t assume the first problem someone presents is the real one. Dig into what they’re trying to do.

😰 #3 Impostor syndrome

Impostor syndrome is the belief that you're not as competent as others think you are, despite evidence of your skills.

imposter syndrome : r/ProgrammerHumor — source

Why it matters: Engineers hold back ideas, avoid taking lead roles, or hesitate to ask questions. They assume others are smarter and know more.

Practical explanation: You ship production code every week, but after a tough bug or a comment from a senior engineer, you question if you belong. You avoid contributing in design reviews because you're afraid of sounding stupid.

This bias limits growth. People learn slower and miss opportunities because they silence themselves. The truth is, even senior engineers feel this way at times.

📈 #4 Dunning-Kruger effect

The Dunning-Kruger effect is when people with low ability overestimate their skills, while experts underestimate theirs.

Why it matters: Junior engineers may feel overly confident and make risky decisions. Seniors may doubt themselves too much and avoid stating opinions.

Practical explanation: A new developer might say, “This API should be easy,” and start refactoring core logic. Meanwhile, a more experienced engineer might say, “This part of the system is tricky,” even after working on it for years.

This leads to overconfidence in early stages and self-doubt later. Awareness helps you calibrate your confidence and ask better questions.

🔨#5 Law of the instrument

This is when you overuse your favorite tool for every problem.

Why it matters: Engineers miss better solutions because they default to familiar ones.

Practical explanation: You know React well, so you use it for everything, even when a simple server-side page would work better.

Choose tools based on fit, not comfort. Expand your toolbox.

🪞 #6 Self-serving bias

This is the tendency to credit yourself for wins and blame others or luck for failures.

Stealing the Credit - TV Tropes — source

Why it matters: It blocks honest reflection and learning.

Practical explanation: You say the feature shipped fast because of your smart design, but when it’s delayed, you blame meetings or unclear specs.

Accountability helps you grow. Excuses don't.

🧑‍⚖️ #7 Fundamental attribution error

This is the tendency to blame people’s traits instead of looking at context.

The Fundamental Attribution Error - Sketchplanations — source

Why it matters: You misjudge colleagues and miss root causes of issues.

Practical explanation: You think a teammate is careless because of a bug, when the real issue was poor requirements or unclear communication.

Assume people are doing their best. Fix systems, not just individuals.

🛠 #8 IKEA effect

The IKEA effect is when people overvalue things they’ve built themselves.

What is the IKEA effect example explained - sketch shows a person that put an IKEA table together by themselves, and although it's not a perfect build they still love it, because they put it together — source

Why it matters: Engineers get attached to code and resist changes, even when refactoring is needed.

Practical explanation: You write a custom build script. Later, someone suggests replacing it with a standard tool. You push back, not because it's better, but because it's yours.

This slows down improvement. Code should be judged on utility, not personal effort.

🚲 #9 Bike-shedding

Bike-shedding is spending too much time on trivial details while ignoring important problems.

r/Design - [X-post r/XKCD / the front page] An XKCD on industrial Design — source

Why it matters: Teams get caught up debating easy things instead of solving hard ones.

Practical explanation: You spend 30 minutes debating folder structure in a meeting, but only 5 minutes on designing the data model.

Watch where your team’s time goes. Don’t confuse easy discussions with valuable ones.

🧑‍🏫 #10 Authority bias

Authority bias is when you give too much weight to opinions from senior people or perceived experts.

Why it matters: Good ideas get ignored if they come from junior voices. Bad ideas get followed if they come from the top.

Practical explanation: A staff engineer suggests a tool they haven’t used in production, and the team goes with it without questioning. No one wants to challenge the authority.

Titles don’t make someone right. Arguments should stand on evidence, not seniority.

🧍 #11 Conformity bias

Conformity bias is the tendency to align with the group, even if you disagree.

Why it matters: Engineers may hold back objections in design reviews or planning sessions, leading to poor decisions.

Practical explanation: A new engineer notices a flaw in the proposed architecture but stays silent because everyone else seems to agree.

Speaking up is uncomfortable, but groupthink is worse. Diversity of thought improves systems.

🧱 #12 Not invented here (NIH)

Not Invented Here is the bias against using external solutions in favor of building your own.

A cartoon of a dialogue with the brain. The brain asks a question that keeps its human from going to sleep.

Why it matters: Teams reinvent the wheel and waste time building things that already exist.

Practical explanation: Instead of using a stable open-source library, you build an internal tool with less functionality. You justify it by saying, “It’s tailored to our needs.”

This leads to long-term maintenance cost and slower delivery. Use existing solutions when they work.

🎉 #13 Bandwagon effect

The bandwagon effect is the tendency to adopt trends just because others are doing it.

The bandwagon effect: someone struggles to decide at a path forking between a long empty road of 'what they think' and one full of people and fun of 'what everyone thinks' — source

Why it matters: Engineers may push tools or patterns that aren't a good fit, just to follow the crowd.

Practical explanation: You move to microservices because “everyone is doing it,” not because you have a scaling problem.

Trendy tech can work, but not in every context. You need to ask, “Does this solve our real problem?”

🔥 #14 Survivorship bias

Survivorship bias is focusing on the winners and ignoring the failures that didn’t survive.

Why it matters: You hear about successful startups using bleeding-edge tech and assume that’s the reason they succeeded.

Practical explanation: You read a blog post where a company scaled with Rust and Kafka. You think you should do the same, ignoring the 50 startups that tried and failed with that stack.

Look beyond success stories. Ask what didn’t work and why. Survivors are not always representative.

🧠 #15 Availability heuristic

The availability heuristic is the tendency to judge something based on how easily you can recall examples.

The Availability Heuristic illustration: Plane crashes, cold snaps, and winning lottery tickets are shown as examples of uncommon but widely reported events that might affect the significance we associate with them. — source

Why it matters: Engineers make decisions based on what’s recent, not what’s relevant.

Practical explanation: If you recently fixed a big caching bug, you might over-prioritize caching concerns in your next project. If a service went down last week, you might now overestimate that risk.

This creates blind spots. Just because something is top of mind doesn't mean it's common or important.

⚓ #16 Anchoring bias

Anchoring bias is when people rely too heavily on the first piece of information they see.

Why it matters: Early estimates, guesses, or suggestions can distort later judgments. Even if they’re wrong, they stick in our heads.

Practical explanation: A team lead says a task should take 3 days. Everyone else starts their thinking from that point, even if it’s based on nothing. It becomes the anchor.

You need to reset expectations with real data. Don't let bad anchors shape your planning or tech choices.

🔍 #17 Confirmation bias

Confirmation bias is the tendency to look for evidence that supports your beliefs and ignore evidence that contradicts them.

chainsawsuit by kris straub - Tuesday, September 16, 2014 — source

Why it matters: Engineers may resist valid criticism, cherry-pick benchmarks, or over-trust their own assumptions.

Practical explanation: You believe framework A is faster, so you test only the cases where A wins. You ignore or dismiss the cases where framework B performs better.

This bias leads to poor technical decisions and tribalism. Stay skeptical of your own assumptions, not just others’.

🎯 Conclusion

These biases don’t show up in your terminal. They show up in decisions, code reviews, meetings, and planning. Left unchecked, they slow you down and damage your team.

Start noticing them in your own work. Write better estimates. Ask better questions. Challenge your first instinct. Challenge your team with data.

Which of these are new for you?