Every debugging session has two suspects: the code and the person reading it. We spend hours on the first one and hardly a minute on the second.
I've been writing about cognitive biases for quite some time already, and the ones that cost the most time show up in the same places again and again: incident channels, code reviews, and those late hours when a fix feels close.
So here's a little quiz. Below are six short scenes from a normal week in software, plus a bonus one. Each scene hides a cognitive bias. Read the scene, guess the bias, and then open the answer.
Let's keep score in the comments. Post the guesses first, something like "1. anchoring, 2. ...", and then check the answers. 👇
Scene 1: The deploy at 14:00
We deploy a new version of the checkout service at 14:00. At 14:05, the error rate goes up. We open the checkout logs, spot a few timeouts from the payment provider, and read them as side effects of the deploy. For the next hour, we read the new code line by line, looking for the bug.
At 15:10, someone from the payments team mentions that their provider started timing out at 14:03.
The fix: before we search, we name one fact that would prove the theory wrong, and we check that fact first.Which bias?
Confirmation bias. We picked the explanation that fit the timing, and then we read every new clue through it. The provider timeouts sat right there in our own logs, and we filed them under the deploy theory.
Scene 2: The first guess in the channel
An alert fires, and five people join the incident channel. The first message reads, "Probably the database." For the next forty minutes, the team checks query times, connection pools and replication lag.
The database looks healthy on every graph, and the team keeps digging anyway. The real cause sits in a config change to the load balancer.
The fix: in the first five minutes, we ask everyone to post one possible cause before anyone starts digging. With three different guesses on the screen, we hold each of them more loosely.Which bias?
Anchoring. We lock onto the first idea we hear, and we adjust too little when new facts come in. Five people followed one quick guess for forty minutes.
Scene 3: The outage everyone remembers
Last month, an expired certificate took down the API for two hours, and the whole company heard about it. Today, the API returns 502 errors, and within a minute three engineers are checking the certificates.
The certificates look fine. The pods restart every few minutes because of a memory leak in a new worker.
The fix: we keep a short runbook that maps symptoms to checks, and we follow it before we follow our memory.Which bias?
Availability heuristic. We judge how likely something is by how easily we remember an example. We remember a painful, recent outage so vividly that we put it at the top of the list for every new symptom.
Scene 4: Two days into the cache
The search page feels slow, so we start building a caching layer. Two days in, the cache works for most queries, and the code looks lovely. Then we run a profiler and find the slow part far away from search, in the image resizing.
We spend the next day finishing the cache anyway, because we've come so far.
The fix: at every milestone, we ask one question: "If we started today, with what we know now, would we build this?" If the answer is a quick yes, we continue. Otherwise, we write down what we learned and move to the real bottleneck.Which bias?
Sunk cost fallacy. We keep investing in something because of everything we've already put into it, even after we learn that the problem lives elsewhere.
Scene 5: "I wrote that, it's solid"
During an outage review, someone asks about the retry logic. The most senior engineer on the team says, "I wrote that module three years ago, it's solid." Everyone moves on to the next item.
A week later, the same outage comes back, and this time the team traces it to the retry logic.
The fix: we check every module with the same care, whoever wrote it. On healthy teams, "let's check it anyway" sounds like a normal, friendly sentence that anyone can say to anyone.Which bias?
Authority bias. We give extra weight to an opinion because of who said it, and we check that part of the system less carefully.
Scene 6: "Found the issue!"
A test fails in CI. We paste the error into an AI coding tool, and it replies, "Found the issue!" with a neat patch that wraps the call in a try/catch. The test turns green, and we merge.
Two weeks later, the support team reports that some users see an empty order history. The try/catch returns an empty list whenever the call fails.
The fix: we ask the tool to argue against its own patch: "What could this change hide?" And we read every try/catch in the diff before we merge.Which bias?
Automation bias. We lean on the answer of an automated system and relax our own checks, especially when the answer sounds confident. We read a green test as proof, and we stop asking what the fix hides.
Bonus scene: The review afterwards
In the review after scene 1, someone says, "Honestly, it was obvious. The provider had issues all week." Everyone nods.
The fix: in incident reviews, we write down what the team knew at each moment, and we judge each decision by that information.Which bias?
Hindsight bias. Once we know the answer, the path to it looks short and obvious. During the incident, that same path sat among twenty other possible paths.
The pattern behind all seven
In every scene, we felt sure early, and we let that feeling choose where we looked next. We all carry these biases, because they come with being human. We protect ourselves with one small habit: before we commit to an answer, we ask what else could explain the same symptoms.
So, what's the score?
Share the score in the comments, and tell me which scene felt the most familiar.
And which bias would we add as scene 8? I'd love to collect a whole list of them. 👇
Top comments (2)
I’ll take a shot: 1. Anchoring, 2. Anchoring (or Bandwagon), 3. Availability heuristic, 4. Sunk cost fallacy, 5. Authority bias, 6. Automation bias, Bonus. Hindsight bias.
Scene 6 hits way too close to home—it's so easy to just accept an AI patch that turns the test green without questioning why it failed in the first place. Great quiz, the questions really make you pause and reflect!
Oleksandr, you are goooood!
Thank you so much for taking time to read and answer 😍