Cognitive Bias for Software Engineers
20 Biases That Distort Estimates, Code Reviews, and Team Decisions
Cognitive bias for software engineers | estimates, code review, meetings, hiring, and the biases the AI era added
30+ technical books across 4 languages · Sold on Kindle in 6 countries · From a year of real production use
Overview
Cognitive bias for software engineers, written from both sides: the side that uses a psychological technique and the side that refuses to be fooled by it. 15 chapters covering the planning fallacy in estimates, framing in code review, anchoring in meetings, psychological safety and groupthink on teams, and the biases the AI era added. The countermeasures are mechanisms, not reminders to be careful. Built on Kahneman and Tversky, Cialdini, Edmondson, and empirical software engineering research.
What you will be able to do
- Estimate with reference class forecasting and premortems instead of gut feel
- Write review comments that land, using framing rather than more politeness
- Run a meeting where the first speaker does not set the number for everyone else
- Tell psychological safety apart from being nice, and know which one your team has
- Recognize a dark pattern while it is being run on you, in a negotiation or an interview
Who is this book for
- [Mid-career Engineer] Technically solid, and stuck every time the problem involves other people
- [Tech Lead] Reviewing, estimating, and running meetings for a team, not just yourself
- [Future Engineering Manager] About to inherit hiring and one-on-ones
- [Remote Team] Watching proximity bias decide who gets the interesting work
- [AI-assisted Developer] Wondering how much of the LLM output you are accepting on autopilot
- [Interviewer] Suspecting your structured interview is not as structured as it looks
Problems this book solves
- My estimates come in at half the real number, and they have for years
- The proposal was technically right and the room still said no
- I spend hours on a code review and the next PR arrives with the same problems
- I keep chasing the bug that resembles last month's incident
- My team is polite and nobody raises a problem until it ships
- Remote work moved the interesting work toward whoever is in the room
- I accept the LLM's answer more often than I can justify
Where this book stands
- Practice-first (every bias enters through a situation from the working day)
- Engineer-scoped (estimates, review, debugging, hiring, not general life advice)
- Intermediate (assumes a few years of shipping, no psychology background)
- Two-sided (each technique is shown from the user's side and the target's side)
Why this book
- The engineering shelf and the cognitive bias shelf barely overlap. This book sits in both
- Countermeasures are mechanisms, because being careful fails hardest exactly when bias is strongest: tired, rushed, working from incomplete information
- Covers the biases the AI era added, including automation bias and overreliance on LLM output
- Each technique is written from both sides, so the persuasion chapter also teaches you how to notice persuasion aimed at you
- 27 figures, and the research is cited: Kahneman and Tversky, Cialdini, Edmondson, Communications of the ACM, ESEC/FSE, Project Aristotle
How this differs from other AI books
| Compared to | This book's difference |
|---|---|
| Thinking, Fast and Slow and other general cognitive bias books | Those explain the mechanism. This one places it in a sprint estimate, a review comment, and a design meeting, and gives the countermeasure in that setting. |
| Essential SRE | Reliability is the frame there, and human factors are one input. Here bias is the subject and the whole book is spent on it. |
| Engineering management books | Those start once you have a team. Half of this book is aimed at your own judgment: estimating, choosing a stack, debugging, deciding what to learn next. |
Table of contents
- Introduction Free preview
- 01 Chapter 1: What Cognitive Bias Actually Is Free preview
- 02 Chapter 2: System 1 and System 2, the Programmer's Two Minds Free preview
- 03 Chapter 3: Cognitive Bias in the AI Era
- 04 Chapter 4: The Three Biases That Wreck Your Estimates
- 05 Chapter 5: The Psychological Traps in Technology Selection
- 06 Chapter 6: Cognitive Traps in Debugging and Incident Response
- 07 Chapter 7: The Biases That Bend Learning and Career Decisions
- 08 Chapter 8: The Psychology of Code Review
- 09 Chapter 9: Getting a Technical Proposal Accepted
- 10 Chapter 10: The Psychology of One-on-Ones and Feedback
- 11 Chapter 11: Reaching Agreement in a Meeting
- 12 Chapter 12: Negotiation for Engineers
- 13 Chapter 13: Building Psychological Safety
- 14 Chapter 14: Psychological Traps in Remote Work
- 15 Chapter 15: Interview Bias and Dark Patterns
- Afterword
- References Free preview
- About the Author Free preview
An estimate arrives at half the real number. A proposal that was technically correct dies in the meeting. The same class of bug slips through because last month’s incident is still the first thing that comes to mind.
The usual explanation is a gap in skill. Usually it is not. It is machinery built into the human brain, bending judgment in a direction that can be named in advance.
This book covers 20 of those biases and the psychological techniques built on top of them, scoped to the work software engineers actually do. Each one is written from two sides: the side that uses the technique, and the side that refuses to be fooled by it.
The countermeasures do not ask you to be more careful. Being careful fails hardest at the exact moment bias is strongest, which is when you are tired, rushed, and working from incomplete information. What holds up is mechanism. Reference class forecasting instead of gut estimates. Premortems. Planning poker used for what it actually does, which is remove the anchor. Anonymous voting before discussion. Structured interviews. Blameless postmortems that a leader has honored more than once.
Fifteen chapters, four parts: how bias works, your own judgment, other people, and the team.
Related books
Dive deeper with related articles
FAQ
- Do I need a psychology background to read this?
- No. Every bias is introduced through a situation engineers already recognize: an estimate that came in at half the real number, a technically correct proposal that died in the meeting, a bug missed because last month's incident was still top of mind.
- How is this different from a general cognitive bias book?
- General books explain the bias. This one puts it where the work happens. The planning fallacy chapter is about sprint estimates and reference class forecasting. The framing chapter is about the wording of a review comment. The anchoring chapter is about who speaks first in a design meeting.
- What do the countermeasures actually look like?
- Mechanisms, not vigilance. Reference class forecasting instead of gut estimates. Premortems. Planning poker used for what it actually does, which is remove the anchor. Anonymous voting before discussion. Structured interviews. Blameless postmortems that a leader has honored more than once.
- Is it on Kindle Unlimited?
- Yes. The English edition is enrolled in KDP Select, so Kindle Unlimited subscribers can read it at no additional cost.
Read on Kindle
Included in Kindle Unlimited
Read on Kindle ($9.99)