I used to keep a long list of cognitive biases, the kind that reads like a textbook index. It was useless. The ones below are the handful I actually catch myself in, week after week, when I’m building systems or making calls I can’t easily undo. Short list, real stakes.

Sunk cost fallacy

Continuing to invest in something because of what you’ve already spent, not what it’s worth now.

This is the one that gets me with code. I’ve kept a bad abstraction alive for months because I wrote it and it cost me a week. The money and time are gone either way. Now I ask a colder question: if this didn’t exist yet, would I build it this way today? If the answer is no, I rip it out.

Planning fallacy

We estimate tasks as if everything goes right, even though it never does.

Every project plan I’ve written is optimistic, and I know it’s optimistic, and I still write it that way. So I stopped trusting the inside view. I look at how long the last three similar things actually took and use that number instead. When someone wants a date, I give a range, not a point.

Parkinson’s law

Work expands to fill the time available for it.

Give me two weeks for a task and it takes two weeks. Give me two days and somehow it ships. The slack doesn’t go into quality, it goes into polishing things nobody asked for. I now set deadlines that feel slightly too tight on purpose, and I timebox spikes so research doesn’t quietly become a month.

Present bias

We overweight immediate rewards and discount future ones, even when the future cost is much larger.

This is why I’ll skip writing the test today and pay for it with a 2am page later. The fix that worked for me is making the future cost visible now. I make the right thing the default: a pre-commit hook, a template, a CI gate. If discipline has to fire every time, it eventually won’t.

Loss aversion

A loss hurts about twice as much as an equivalent gain feels good.

It’s why I cling to a feature nobody uses and why deleting code feels harder than writing it. The reframe that helps: keeping dead code is also a loss, just a slow one (maintenance, confusion, surface area). I try to weigh both sides instead of only feeling the deletion.

Confirmation bias

We seek and remember evidence that fits what we already believe.

When I’m debugging, I latch onto the first plausible cause and then read every log line as proof I was right. The cure is mechanical: before I commit to a theory, I write down what I’d expect to see if I were wrong, then go look for that. In design reviews I ask someone to argue the opposite, out loud.

Dunning-Kruger

The less you know about something, the more you tend to overestimate how much you know.

I feel most confident right after reading one good blog post about a new tool, which is exactly when I know the least. My tell is when an estimate feels easy. Easy usually means I haven’t found the hard part yet. So I treat early confidence as a flag to go dig, not a green light.

Survivorship bias

We study the winners and miss the failures that never made it into view.

Every “how we scaled to a billion users” post is written by the team that survived. The graveyard of companies that did the same thing and died doesn’t blog. When I copy an architecture because a famous company uses it, I remind myself I’m seeing a survivor at their scale, with their constraints, not mine.

Paradox of choice

More options can make a decision harder and the outcome less satisfying.

Hick’s law is the engineering version: the time to decide grows with the number of choices. I see it in tooling and in product. Ten ways to do one thing is not flexibility, it’s a tax on everyone after me. I try to pick sane defaults and remove options rather than add a config flag for every preference.

Anchoring

The first number you hear pulls every later estimate toward it.

Whoever says “this should take about two days” has just set the anchor, and the whole room drifts toward it. I’ve watched a casual guess become the committed deadline. So I try to form my own estimate before I hear anyone else’s, and when I’m the one guessing out loud, I say it’s a guess.

Recency bias

We give too much weight to whatever happened most recently.

One bad incident and suddenly I want to rearchitect the whole system around a problem that fired once. Recent and frequent are not the same thing. Before I react to the latest fire, I check whether it’s a pattern in the data or just the freshest memory. Usually it’s the memory.