Cognitive Biases are Features, not Bugs

Why experience doesn’t protect us from cognitive biases — and which safeguards help me make better technical and professional decisions.

When developers talk about errors, they usually mean errors in code, architecture, or processes. We have tests, logs, reviews, and reproducible examples for those.

The more difficult errors happen before I write a single line of code: in how I perceive the problem, what I assume about its cause, which options I consider, and how accurately I assess my own abilities.

Even after more than three decades as a developer, I’m not immune to them. Experience helps me recognise certain patterns earlier. But it can also make me dangerously confident.

So the goal cannot be to eliminate my cognitive biases altogether. The goal is to develop ways of working that limit the damage they can do.

Experience doesn’t protect you from bias

Cognitive biases are often presented as minor defects in an otherwise rational mind. You learn terms such as confirmation bias, anchoring, or the sunk-cost fallacy and hope that knowing them will make you slightly less irrational.

It doesn’t work that way.

I can explain confirmation bias and still spend most of my debugging time looking for evidence that supports my first theory. I can understand the sunk-cost fallacy and still cling to a technical solution because I’ve already invested three weeks in it. I can have decades of experience planning projects and still underestimate the time needed for integration, testing, and the final twenty percent.

Knowing the name of a bias does not make it disappear. Sometimes it merely gives me a more sophisticated vocabulary for defending my original decision after the fact.

Confirmation bias while debugging

Anchoring in effort estimates

The planning fallacy is part of the job

The sunk-cost fallacy in architecture and personal projects

Status quo bias in legacy systems

The availability heuristic: the last disaster defines the architecture

Overconfidence and the seniority effect

The not-invented-here effect

Groupthink and polite agreement

AI doesn’t eliminate my biases

Coding agents can propose alternative solutions, formulate counterarguments, and analyse code. That can help broaden my perspective. But an agent still works with the context I give it.

If I build a false assumption into the prompt, the system may produce an exceptionally convincing elaboration of that exact assumption. If I ask for arguments in favour of my preferred architecture, I will receive arguments in favour of it. If I define the problem too quickly, the agent may optimise the wrong solution with remarkable efficiency.

AI can therefore act both as a corrective and as an amplifier of my biases. It becomes particularly useful when I explicitly ask it to challenge my first judgement:

  • Which assumptions am I overlooking?
  • What alternatives are there?
  • What speaks against this approach?
  • Under which circumstances would this solution fail?
  • What simpler explanation would also fit the observations?
  • Which parts of my plan are probably too optimistic?

Even then, the system does not provide objective truth. But it can create friction — and friction is often exactly what premature certainty needs.

Other people’s biases are easier to see

I can usually spot selective perception, overconfidence, and emotional attachment in colleagues with remarkable clarity. In myself, the same processes feel very different:

  • like technical experience,
  • like intuition,
  • like pragmatism,
  • like high standards,
  • like a sense of responsibility,
  • or simply like common sense.

That is the bias blind spot: the tendency to recognise bias in others while considering ourselves comparatively objective.

Self-observation alone is therefore not enough. I need feedback, reviews, tests, measurements, and people who are allowed to disagree with me. Not because other people are automatically right, but because my own perspective is inevitably limited.

Good work needs safeguards

I will not get rid of my cognitive biases. So instead of relying on my own rationality, I try to build small safeguards into the way I work:

  • Write down hypotheses before I begin debugging.
  • Actively search for evidence that would disprove them.
  • Document effort estimates together with their assumptions.
  • Revisit major decisions after some distance.
  • Before investing further, ask whether I would still start this way today.
  • Explicitly name alternatives when making architectural decisions.
  • Distinguish measurements from memorable anecdotes.
  • Make uncertainty visible instead of hiding it behind seniority.
  • Ask other people to look specifically for weaknesses in my solution.
  • Use AI not only for validation, but also as an opposing position.

None of these methods makes me objective. They merely reduce the likelihood that an unnoticed bias will take control on its own.

The goal is not perfect rationality

Software development takes place under time pressure, with incomplete information, historical baggage, social dependencies, and limited attention. Perfect rationality would be unrealistic even under ideal conditions.

For me, professional work therefore does not mean always being right. It means expecting that I may be wrong. It means making decisions in ways that allow errors to become visible early and remain relatively cheap to correct. And it means not confusing a belief I once formed with my identity.

I will never get rid of my cognitive biases as a developer. But I can learn to give them less uncontrolled power over my projects, my decisions, and my professional life.