Code review is supposed to be a quality gate. A second pair of eyes catching what the first pair missed. In theory, it works. In practice, it's riddled with psychological blind spots that nobody talks about.
I've been a professional developer for eleven years. For the last three of those years, I've been studying behavioral psychology on the side — specifically how cognitive biases affect technical judgment. What I've found has fundamentally changed how I approach code reviews, both as a reviewer and as the person being reviewed.
Here are five biases that are almost certainly affecting your code reviews right now, along with concrete strategies to counteract each one.
1. Confirmation Bias: Seeing What You Expect to See
What it is: The tendency to search for, interpret, and remember information that confirms your pre-existing beliefs while ignoring contradictory evidence.
How it shows up in code reviews: If you open a PR expecting it to be good (because the author is someone you respect, or the feature seems straightforward), you'll unconsciously skim. Your brain pattern-matches against "looks fine" and moves on. If you open a PR expecting problems (because the author is junior, or the feature is complex), you'll scrutinize aggressively — and you'll find issues, even if they're trivial.
I ran an informal experiment on my team last year. I took the same code change — a moderately complex refactoring of a caching layer — and attributed it to two different authors. One was a staff engineer with a strong reputation. The other was a recent hire. I asked four senior developers to review the change separately.
The results were striking but not surprising. Reviews of the "staff engineer's" code averaged 2 comments each, mostly positive observations. Reviews of the "new hire's" code averaged 7 comments, including nitpicks about formatting and variable naming that were functionally identical to patterns used throughout the codebase.
Same code. Same quality. Different expectations led to dramatically different reviews.
What to do about it:
- Blind review when possible. Some teams have experimented with anonymizing PR authors during review. It's not always practical, but even occasionally doing it can calibrate your self-awareness about how much author identity affects your feedback.
- Write your review hypothesis first. Before reading any code, write down what you expect to find. "I expect this PR to have issues with error handling because the feature touches external APIs." Then explicitly look for evidence against your hypothesis. Force yourself to find things that contradict your expectation.
- Use a checklist. A structured review checklist ensures you evaluate the same criteria regardless of your expectations. Security. Error handling. Edge cases. Performance implications. Test coverage. Check each one explicitly instead of relying on gut feel.
2. Anchoring Bias: The First Thing You See Sets the Standard
What it is: The tendency to rely too heavily on the first piece of information encountered when making decisions.
How it shows up in code reviews: The first file you see in a PR sets an unconscious standard for the rest of your review. If the first file is well-structured and clean, you carry that positive impression forward. Your brain assumes the rest will be similar quality and reviews less carefully. If the first file has issues, you enter "problem-finding mode" and apply that lens to everything else — sometimes flagging things that are perfectly fine.
This is also why PR ordering matters more than most people realize. GitHub shows files in alphabetical order by default. If api/handlers.go happens to be clean but utils/parser.go has problems, the review quality for the parser will be affected by what the reviewer saw first in the handler.
There's a more subtle form of anchoring in code reviews: the PR description. A detailed, well-written PR description anchors the reviewer toward the author's intended narrative. Reviewers end up evaluating whether the code matches the description rather than whether the code is actually correct. I've seen bugs sail through review because the PR description was convincing enough that reviewers were essentially reading to confirm the narrative rather than independently assessing the code.
What to do about it:
- Randomize your review order. Don't review files in the order they appear. Start with tests, then move to the most critical business logic, then periphery. This breaks the anchoring chain.
- Review the code before reading the PR description. Form your own understanding of what the code does, then compare it to the author's description. Discrepancies between what you see and what the author describes are some of the most valuable findings in a review.
- Take a break between files. If a PR touches multiple modules, review each module in a separate sitting. This prevents positive or negative impressions from one module from bleeding into your assessment of another.
3. The Halo Effect: One Good Thing Colors Everything
What it is: The tendency for a positive impression in one area to influence your judgment in unrelated areas.
How it shows up in code reviews: If a developer writes elegant algorithms, you'll unconsciously assume their error handling is also solid. If someone structures their tests beautifully, you'll trust their production code more than it deserves. The halo works in reverse too: a developer who writes verbose, ugly-looking code that actually works perfectly gets scrutinized more harshly on correctness than someone who writes pretty code with subtle bugs.
I fell into this trap badly early in my career. There was a developer on my team whose code was genuinely beautiful. Clean abstractions, thoughtful naming, consistent style. I approved their PRs faster and with fewer comments than anyone else's. A year later, we discovered a category of race conditions in their code that had been there for months. Their code was beautiful and broken, and my halo-effect-influenced reviews had let the bugs through.
The halo effect also extends beyond code quality to communication style. Developers who write articulate PR descriptions and respond thoughtfully to review comments get more favorable code reviews. Their actual code quality becomes secondary to the impression created by their communication.
What to do about it:
- Separate aesthetics from correctness. Make two explicit passes: one for "does this work correctly?" and one for "is this well-structured?" Conflating these two concerns is how the halo effect sneaks in.
- Focus on tests. Tests are the great equalizer. Regardless of how the code looks, ask: "Do the tests cover the edge cases? Would the tests catch a regression?" This shifts evaluation from subjective impression to verifiable behavior.
- Rate dimensions independently. When leaving review feedback, mentally score each dimension separately — correctness, readability, performance, security, test coverage. Resist the urge to give an overall "this is good/bad" assessment.
4. IKEA Effect: Defending Code You Helped Design
What it is: The tendency to overvalue things you've had a hand in creating, named after the disproportionate pride people feel in furniture they've assembled themselves.
How it shows up in code reviews: If a developer discussed their approach with you before writing the code, you've already invested in the design. When you review the PR, you're not objectively evaluating the code — you're defending a decision you helped make. Finding problems feels like finding problems with your own judgment, which is psychologically uncomfortable. So you find fewer problems.
This is why "design review then code review" workflows, while well-intentioned, can actually reduce code review effectiveness. The person who approved the design is the worst possible code reviewer because they're biased toward confirming that the design they approved was correct.
I saw this play out on a project where the tech lead reviewed all designs and all code. Their approval rate was 94% on first review. When we rotated in a reviewer who hadn't been part of the design discussions, the first-review approval rate dropped to 61%. The second reviewer wasn't harsher — they were simply unbiased. They caught issues the tech lead couldn't see because the tech lead was too invested.
What to do about it:
- Separate design reviewers from code reviewers. If you participated in the design discussion, you should not be the primary code reviewer. You can be a secondary reviewer, but someone with fresh eyes should be the first pass.
- Explicitly label your involvement. When reviewing code where you were involved in the design, start your review with: "Note: I was involved in the design discussion for this change, which may bias my review." This transparency helps both you and the author calibrate your feedback appropriately.
- Ask adversarial questions. Force yourself to complete this sentence: "The biggest problem with this approach is..." Even if you agree with the approach, articulating the strongest possible counterargument exercises the critical thinking muscles that the IKEA effect suppresses.
5. Availability Bias: Fighting the Last War
What it is: The tendency to overweight recent or memorable events when evaluating probability and making decisions.
How it shows up in code reviews: If your team just dealt with a production outage caused by a null pointer exception, every code review for the next month will have disproportionate focus on null handling — even in code where null is impossible. If you recently read about a security vulnerability in a library, you'll scrutinize dependency choices with an intensity that doesn't match the actual risk.
Availability bias turns code reviews into a rotating spotlight. Whatever the most recent problem was gets all the attention. Everything else — all the other categories of bugs and design issues — gets neglected.
I tracked my own review comments for three months and found a clear pattern. After a production incident related to database connection pooling, 40% of my review comments for the next two weeks were about connection management. Before the incident, it was around 5%. The actual risk hadn't changed. Only my perception had.
The flip side is equally damaging. Categories of bugs your team hasn't encountered recently become invisible during review. If you haven't had a security incident in a while, security review becomes cursory. Not because the risk has decreased, but because no recent event makes it feel urgent.
What to do about it:
- Use a review checklist that covers all categories. A checklist prevents the availability-driven spotlight effect by ensuring every category gets explicit attention regardless of recent events.
- Track your review comment categories. Keep a simple tally of what categories your review comments fall into. If you notice 80% of your comments are about one category, you're probably neglecting others.
- Rotate review focus areas. Some teams assign each reviewer a specific focus for each review cycle: one person focuses on security, another on performance, another on error handling. This ensures coverage across all categories regardless of individual biases.
The Systemic Problem
These five biases don't operate in isolation. They compound. You open a PR from a respected developer (halo effect), glance at the first file which looks clean (anchoring), remember that you helped design this approach (IKEA effect), expect it to be solid (confirmation bias), and focus your review on the one issue category you remember from last month's incident (availability bias). The result is a review that feels thorough but is actually a series of psychological shortcuts dressed up as technical judgment.
The uncomfortable truth is that unstructured code review — just reading through changes and leaving comments based on what catches your eye — is far less effective than most teams believe. The biases are too numerous and too deeply wired.
What works is structure. Checklists. Rotation. Separation of concerns. Deliberate processes that route around the brain's tendency to take shortcuts.
This isn't just my opinion. The research on structured decision-making consistently shows that systematic approaches outperform unstructured expert judgment in virtually every domain studied. Medicine, law, investing, hiring — and yes, code review.
If you're interested in the broader intersection of cognitive biases and structured decision-making, I've found the principles collection on KeepRule genuinely useful for building personal checklists and decision rules that counteract these patterns — not just in code reviews, but in any domain where your brain is inclined to take shortcuts.
What You Can Do This Week
Add a review checklist to your team's PR template. Even a simple five-item list (correctness, security, edge cases, performance, tests) measurably improves review quality.
Try one blind review. Have a colleague submit a PR without attribution and review it. Notice whether your approach changes when you don't know who wrote the code.
Track your review comments for a month. Categorize each comment and look for patterns. Where are you spending all your attention? What are you consistently missing?
Separate your design reviewers from your code reviewers. If this is organizationally difficult, at least make it the norm for complex changes.
Read your own reviews from six months ago. Look at PRs you approved that later turned out to have problems. Can you identify which bias was at work?
Code review is one of the few quality practices that's nearly universal in software development. We should be much more honest about its limitations — and much more deliberate about compensating for them.
What biases have you noticed in your own code review practice? I'd be especially curious to hear from team leads who've tried to systematize their review process. What worked and what didn't?
Top comments (0)