A senior engineer proposes changing a perfectly functional algorithm. The suggestion introduces unnecessary complexity and marginal performance gains that will never matter in production. A mid-level developer spots the issues immediately but approves the change anyway.
Why?
The answer isn’t technical—it’s psychological.
Code reviews are supposedly objective evaluations of technical merit. In reality, they’re complex social negotiations influenced by power dynamics, cognitive biases, and unspoken hierarchies. Understanding these psychological forces is crucial because they determine which code ships, which patterns persist, and ultimately, the quality of our systems.
The stakes are higher than most teams realize. When good developers accept bad suggestions, it’s not stupidity—it’s human psychology overriding technical judgment.
1. Authority Bias: When Experience Becomes a Weapon
The authority bias describes our tendency to attribute greater accuracy to the opinions of authority figures. It’s why patients hesitate to question doctors and why employees defer to managers even when those managers are clearly wrong.
In software teams, seniority creates authority. A “Senior Principal Engineer” carries weight that a “Software Engineer II” simply doesn’t, regardless of who’s actually correct.
Consider this scenario: A junior developer spots that a proposed database query will cause N+1 problems at scale. But the suggestion comes from a tech lead with fifteen years of experience. The junior developer faces a psychological dilemma:
“Maybe I’m missing something. They’ve been doing this much longer than me. If this were really a problem, wouldn’t they see it?”
This internal dialogue leads to self-doubt. The junior developer either approves silently or phrases their concern as a question rather than a statement: “Could this possibly cause N+1 issues?” The tentative framing invites dismissal.
Meanwhile, the senior engineer interprets any pushback as the junior “not understanding the context” or “needing more experience.” Even when the junior is completely correct, authority bias creates a self-reinforcing loop where experience trumps evidence.
The most insidious aspect? Senior engineers often don’t realize they’re wielding authority bias. They genuinely believe their suggestions win on merit, not realizing that social proof and hierarchical pressure do half the work.
2. The Halo Effect: When Past Success Blinds Us
The halo effect occurs when one positive trait colors our perception of everything else about a person. If someone is attractive, we assume they’re also intelligent and kind. If someone built a successful product, we assume all their technical opinions are sound.
In code reviews, the halo effect manifests around “star” developers—those with visible accomplishments or impressive backgrounds. When someone who “built the authentication system” or “worked at Google” suggests a change, teams unconsciously lower their critical standards.
This creates dangerous blind spots. A developer might have expert knowledge in distributed systems but mediocre judgment about frontend architecture. Yet their halo extends everywhere. Their React suggestions get less scrutiny because people remember their brilliant work on the API layer.
The effect compounds in code reviews because reviewers see the author’s name before reading the code. That name triggers associations—”Oh, it’s Sarah, she’s brilliant” or “This is from Alex, he knows what he’s doing.” These mental shortcuts bypass critical evaluation.
Teams can counteract this by implementing anonymous code review pilots, where author names are hidden until after initial review. Results are often startling—code that would sail through review from senior developers faces genuine scrutiny when authorship is unknown.
3. Groupthink: The Silence of the Skeptical
Groupthink describes how groups prioritize harmony over critical thinking. Members suppress dissenting opinions to maintain consensus, leading to poor decisions that everyone privately doubts.
Code review groupthink follows a predictable pattern:
The first reviewer (often someone senior) approves a pull request with positive comments. Subsequent reviewers see this approval and feel social pressure to conform. “If Lisa approved it, it must be fine. Who am I to question?”
Each approval makes the next more likely. By the time the fourth person reviews, expressing concerns feels like disrupting consensus. Even if you spot problems, the social cost of being “that person” who blocks a PR with three approvals outweighs the technical benefit of raising concerns.
This dynamic is particularly strong when reviewers know each other personally. Nobody wants to be seen as difficult, pedantic, or standing in the way of their colleague’s work. The desire to be supportive teammates overrides the responsibility to catch problems.
Groupthink explains why critical issues sometimes pass through multiple reviews unchallenged. It’s not that everyone missed the problem—it’s that each person assumed someone else would raise it, or that multiple approvals meant they were overthinking it.
The solution isn’t more reviewers—it’s cultivating a culture where dissent is valued. Teams need explicit permission to be the second person who raises concerns, not just the first.
4. The Curse of Knowledge: When Experts Can’t See Confusion
The curse of knowledge is a cognitive bias where people who understand something find it impossible to imagine not understanding it. Once you know how something works, you can’t unknow it—and you lose empathy for those still learning.
In code reviews, this manifests when experienced developers propose solutions that make perfect sense to them but are cryptic to everyone else. They write terse, elegant code leveraging advanced language features or domain-specific patterns. When questioned about clarity, they’re genuinely confused—”It’s obvious what this does.”
But it’s only obvious if you already understand it.
A senior developer writes:
users.stream()
.collect(groupingBy(User::getDepartment,
mapping(User::getSalary,
collectingAndThen(toList(),
list -> list.stream().mapToDouble(Double::doubleValue).average()))));
To them, this is clean functional programming—a straightforward group-by-and-average operation. To a junior developer, it’s an intimidating wall of nested method calls that will require significant mental effort to understand.
When the junior suggests a more explicit loop-based approach, the senior dismisses it as “verbose” or “not idiomatic.” The curse of knowledge prevents them from recognizing that their “clean” solution increases cognitive load for most of the team.
The irony? The junior developer’s suggestion might be better for the team’s actual skill distribution, even if it’s less elegant by expert standards. But the curse of knowledge makes experienced developers optimize for readability-to-experts rather than readability-to-the-team.
5. Status Quo Bias: The Comfortable Weight of Existing Patterns
Status quo bias is our preference for the current state of affairs. Change feels risky and effortful, even when the status quo is demonstrably worse than alternatives.
In codebases, this manifests as pattern replication. If error handling has always used try-catch blocks in a certain way, new approaches face higher scrutiny than code that follows existing patterns—regardless of whether those patterns are actually good.
A developer proposes using a Result type for error handling instead of throwing exceptions. The suggestion is technically sound and would improve code clarity. But it’s different from how the codebase currently works.
Reviewers raise concerns: “This doesn’t match our patterns.” “Other developers won’t know how to work with this.” “It’ll be inconsistent with existing code.”
These concerns sound reasonable, but they’re often status quo bias in disguise. The hidden assumption is that existing patterns are good, or at least good enough. The burden of proof falls on change, not on continuation.
This creates path dependency—early architectural decisions become permanent not because they’re optimal but because deviation carries psychological costs. Teams end up with systems where “we’ve always done it this way” trumps “this new way is better.”
The counterintuitive solution is establishing a high bar for consistency. Instead of “be consistent with existing code,” aim for “be consistent with our best practices.” If existing code is suboptimal, new code should improve the standard, not replicate the problem.
6. Confirmation Bias: Seeing What We Expect to See
Confirmation bias leads us to favor information that confirms existing beliefs while dismissing contradictory evidence. We unconsciously seek patterns that validate our worldview.
In code reviews, confirmation bias shapes which problems we notice. If you believe a certain developer writes buggy code, you scrutinize their PRs intensely and find issues—confirming your belief. If you believe another developer is brilliant, you skim their code assuming it’s fine—and miss problems.
This creates self-fulfilling prophecies. Developers who are trusted receive less rigorous review, so issues in their code slip through, but when problems emerge later, the root cause investigation focuses elsewhere. Meanwhile, developers viewed skeptically receive intense scrutiny, catching minor issues that reinforce the perception they need careful watching.
Confirmation bias also affects architectural debates. If you believe microservices are the right approach, you’ll notice every limitation of the monolithic alternative while downplaying microservices’ complexity costs. Your code reviews will subtly push toward your preferred paradigm.
The challenge is that confirmation bias operates unconsciously. You can’t simply decide to stop doing it. Instead, teams need structural interventions—rotating review assignments so developers review a diverse set of authors, or explicitly tracking approval rates across reviewers to identify patterns.
7. The Dunning-Kruger Effect: When Confidence Exceeds Competence
The Dunning-Kruger effect describes how people with low competence overestimate their abilities, while experts underestimate theirs. Incompetence prevents people from recognizing their own incompetence.
In code reviews, this creates a paradox: the developers most confident in their suggestions are often the least qualified to make them, while those most qualified hedge their recommendations with caveats.
A junior developer who learned about design patterns last week enthusiastically suggests applying the Strategy pattern everywhere. They’re confident this is the “right” approach because they don’t yet understand the trade-offs. Meanwhile, a senior developer who’s dealt with over-architected systems for years knows when patterns help versus when they add accidental complexity—so they phrase suggestions tentatively.
Paradoxically, the junior’s confidence is persuasive. They sound certain. They cite principles like SOLID and clean code. They reference famous engineers and blog posts. This projection of expertise can override the senior’s more nuanced but less confident guidance.
The effect reverses for true experts. Developers with deep experience understand edge cases, trade-offs, and context-dependence. This knowledge breeds appropriate humility—they know there are no universal answers. But this humility can be misinterpreted as uncertainty or lack of conviction.
Teams need to recognize that appropriate uncertainty is a sign of expertise, not weakness. When a senior developer says “it depends on the context,” that’s often more valuable than a junior developer’s confident proclamation of “the right way.”
8. Sunk Cost Fallacy: Defending the Code We Wrote
The sunk cost fallacy occurs when we continue investing in something because we’ve already invested significantly, even when cutting our losses would be wiser.
For code authors, this manifests as defensive behavior in reviews. You spent three hours implementing an approach. When a reviewer suggests a completely different direction, your psychological response isn’t “is this suggestion better?” but “was my time wasted?”
This emotional investment makes criticism feel personal. Even when reviewers are tactful and focus on the code, not the coder, authors feel attacked. The suggestion to rewrite implies your judgment was flawed, your solution insufficient.
The result is predictable: you defend your approach. You explain the reasoning, the constraints, the trade-offs. You’re not actually defending the code—you’re defending the decision to invest time in it.
Reviewers aren’t immune either. If a reviewer spent significant time understanding a complex PR, suggesting major changes feels like admitting they wasted that time. There’s psychological pressure to find ways the existing approach works rather than recommending starting over.
The sunk cost fallacy is why smaller, incremental PRs are psychologically easier to review well. When someone invests 30 minutes in an approach versus 30 hours, they’re more willing to pivot. The emotional stakes are lower.
9. Power Dynamics: The Unspoken Hierarchy
Every team has a power structure, whether formal or informal. Titles, tenure, past accomplishments, and personal relationships create hierarchies that profoundly influence code review dynamics.
A mid-level developer reviews their manager’s code. They spot questionable decisions but approve anyway. Why? Because your manager controls your career progression, performance reviews, and project assignments. The professional risk of critiquing their code outweighs the technical benefit.
Similarly, contractors reviewing full-time employees’ code face pressure to be agreeable. They’re aware their contract renewal might depend on being “easy to work with.” Critical feedback feels like professional risk.
Gender and race dynamics add another layer. Research on bias in code review shows that code from women and minorities faces higher scrutiny and lower acceptance rates. Women are more likely to have PRs rejected and their suggestions dismissed, even controlling for experience and code quality.
These dynamics create silence. People with less structural power hesitate to push back against those with more, even when they’re technically correct. The code review becomes performative—going through motions rather than genuine collaboration.
Addressing this requires explicit cultural work. Teams need psychological safety where critique flows in all directions without professional consequences. This means managers who genuinely welcome feedback, organizations that reward constructive criticism, and vigilance against demographic bias.
10. The Recency Effect: Why the Last Comment Wins
The recency effect describes how we disproportionately weight recent information. In code reviews, this means the last comment in a discussion often carries undue influence, regardless of its quality.
A PR generates discussion. Five comments debate an approach. The thread grows long and complex. Finally, a senior developer drops a comment at the end supporting one direction. Discussion stops. That becomes the decision.
The recency effect makes this final comment feel dispositive, even when earlier arguments were stronger. Because it’s fresh in memory and came from authority, it eclipses everything before it.
This creates a tactical opening for manipulating review outcomes: wait for others to comment, then weigh in at the end with your preferred direction. You benefit from recency plus status effects.
The pattern is particularly problematic in asynchronous review discussions that span days. By the time the thread resolves, participants barely remember the initial concerns. The most recent suggestion—simply by virtue of being recent and resolving a lengthy discussion—becomes accepted.
Teams can counter this by requiring explicit resolution of earlier concerns rather than letting discussions peter out. Before merging, someone should summarize: “We discussed X, Y, and Z. Here’s what we decided and why.” This forces acknowledging all arguments, not just the latest.
11. Social Desirability Bias: The Politeness Tax
Social desirability bias occurs when people respond in ways they think make them look good rather than being truthful. We want to appear thoughtful, collaborative, and reasonable.
In code reviews, this manifests as excessive politeness that obscures real concerns. Instead of “This approach is wrong,” reviewers write “Have you considered…?” Instead of “This will break at scale,” they write “I’m wondering if we should think about performance…”
This indirection serves social cohesion but sacrifices clarity. The author might interpret tentative concerns as optional suggestions rather than critical issues. The review becomes a dance of politeness where everyone tries to be nice while actual problems go unaddressed.
Junior developers are particularly susceptible. They phrase every concern as a question to avoid seeming presumptuous: “Could there be a null pointer issue here?” They’re hedging—if they’re wrong, it was just a question. If they’re right, they softened the criticism.
But this hedge-speak reduces impact. When everything sounds tentative, authors can’t distinguish genuine blockers from nitpicks. The politeness tax obscures signal with noise.
The solution is cultivating directness without rudeness. Teams should normalize clear statements: “This will cause N+1 queries” instead of “Might this possibly cause potential query issues?” Directness isn’t unkind—it’s respectful of everyone’s time and clarity.
12. The Availability Heuristic: When Recent Bugs Haunt Reviews
The availability heuristic makes us judge likelihood based on how easily we can recall examples. If you recently experienced a plane crash news story, you overestimate flight danger. If your friend was robbed, you overestimate local crime.
In code reviews, recent bugs warp judgment about code risks. If the team just fixed a race condition, reviewers become hypervigilant about concurrency—seeing threading issues everywhere, even in single-threaded code. If a null pointer exception just caused a production incident, reviewers obsess over null checks while missing other problems.
This reactionary reviewing feels prudent but creates tunnel vision. You’re so focused on preventing the last problem that you miss new ones. The availability heuristic makes recent failures disproportionately salient, skewing your mental model of what’s likely to go wrong.
This also affects which code gets reviewed more carefully. A file that recently had bugs gets intense scrutiny on every change. Meanwhile, files without recent issues get casual review, even if they’re equally complex and risky.
The phenomenon creates cycles. A file with one bug gets extra review attention, uncovering more bugs, which reinforces the belief this file is problematic, leading to even more scrutiny—a self-fulfilling prophecy where problem areas attract attention while quiet areas accumulate hidden debt.
Counteracting this requires systematic risk assessment rather than memory-based judgment. What actually makes code risky? Complexity, coupling, lack of tests, and infrequent changes—not recent bug history.
13. In-group Bias: Why Outsiders’ Suggestions Get Dismissed
In-group bias describes how we favor members of our own group over outsiders. We trust insiders, question outsiders, and interpret ambiguous behavior charitably for our group while assuming the worst of others.
In software teams, this manifests around team boundaries. Engineers from the Core Platform team review a PR from the Data Science team. Despite working for the same company, tribal psychology activates.
Platform engineers scrutinize the PR more harshly. “Data Science doesn’t understand systems programming.” They question decisions that they’d accept without comment from their own team. Suggestions for improvement are framed as corrections of incompetence rather than collaborative refinement.
Meanwhile, the Data Science team feels defensive. Platform is being territorial and pedantic. What Platform frames as helpful standards feel like gatekeeping.
Neither side recognizes they’re enacting textbook in-group bias. Each team genuinely believes they’re being objective, that their skepticism is warranted, that the other team really does lack understanding.
This dynamic intensifies with contractors, offshore teams, or newly hired developers. The in-group (existing full-time employees) unconsciously raises standards for outsiders while granting insiders benefit of the doubt.
Research shows this plays out in open source too. Contributors from less-recognized companies or universities face higher barriers to contribution acceptance, even controlling for code quality. The GitHub bias research demonstrates how in-group membership significantly affects whether code is accepted.
14. Anchoring Effect: Why First Impressions Stick
The anchoring effect occurs when initial information disproportionately influences subsequent judgments. If you see a shirt priced at $200 then marked down to $80, it feels like a deal—even if $80 shirts normally cost $50.
In code reviews, the first comment anchors the discussion. If the first reviewer says “This looks great, just minor style fixes,” subsequent reviewers unconsciously adopt that frame. They look for minor issues while assuming the approach is fundamentally sound.
If instead the first comment says “I’m concerned about the scalability of this approach,” subsequent reviewers scrutinize for scaling issues. The initial frame shapes what everyone looks for.
This makes reviewer assignment order matter psychologically. Having your most experienced reviewer go first means their concerns anchor the discussion—other reviewers feel permission to raise issues. Having them go last means earlier “looks good to me” approvals create momentum that’s hard to stop.
The anchoring effect also explains why pull request descriptions are so influential. If the author writes “Quick fix for a bug,” reviewers anchor on “quick” and “fix”—they expect something small and obviously correct. Major architectural concerns feel out of place.
But if the description says “Experimental approach to improving performance,” reviewers anchor on “experimental”—scrutiny increases, questions feel appropriate, and the bar for approval rises.
Authors can strategically use anchoring by framing PRs carefully. But teams should recognize they’re being anchored and consciously re-anchor on objective criteria: does this code work, is it maintainable, does it follow standards?
15. Diffusion of Responsibility: When Multiple Reviewers Means No Reviewers
Diffusion of responsibility explains why people are less likely to help in emergencies when others are present. Everyone assumes someone else will act, so nobody does.
In code reviews, this manifests when PRs are assigned to multiple reviewers. Each person thinks “The others will catch issues, so I can skim quickly.” Everyone does this. The result? The PR gets four superficial reviews instead of one thorough one.
This is particularly insidious because it creates false confidence. The author sees four approvals and assumes the code has been thoroughly vetted. Management sees high review participation. But nobody actually scrutinized the code carefully—they all diffused responsibility to the group.
The phenomenon intensifies with “review notifications” versus “review assignments.” When ten people get notified about a PR, everyone assumes someone else is handling it. Days pass with no review because each person figured others would volunteer.
Surprisingly, single-reviewer assignments often produce better outcomes than multiple reviewers. One person knows they’re responsible. They can’t diffuse to others. This focused accountability leads to more careful review.
If you need multiple reviewers for different expertise (backend and frontend changes), explicitly partition responsibility: “Alice, please review the API changes. Bob, please review the UI components.” Clear assignment prevents diffusion.
16. Fundamental Attribution Error: Judging Code by Character
The fundamental attribution error describes how we attribute others’ behavior to personality while attributing our own behavior to circumstances. When someone cuts you off in traffic, they’re a jerk. When you cut someone off, you were late for an important meeting.
In code reviews, this manifests as character judgments masquerading as technical critique. When you write messy code, you had tight deadlines and unclear requirements. When a colleague writes messy code, they’re careless or don’t care about quality.
This attribution pattern is particularly toxic because it’s invisible to the person making it. You genuinely believe you’re evaluating code objectively. But you’re actually pattern-matching: “This developer always writes buggy code” versus “This was a tough problem with time pressure.”
The error creates vicious cycles. Once you’ve decided someone produces low-quality work, confirmation bias ensures you find evidence supporting this view. Their code gets extra scrutiny, more issues are found, reinforcing the negative assessment.
Meanwhile, developers you’ve attributed positive character traits (“thoughtful,” “detail-oriented”) benefit from the halo effect. Their code gets benefit of doubt. Issues are explained away as understandable oversights rather than carelessness.
Countering this requires conscious reframing. Instead of “Alice wrote buggy code again,” think “This code has bugs—what circumstances led to that?” Instead of “Bob is so careful,” think “This particular PR is well-tested.”
Judge code, not coders. Focus on the artifact, not the person.
17. Overcoming the Psychological Obstacles
Recognizing these biases is necessary but insufficient. Knowledge doesn’t automatically change behavior—you can know about confirmation bias and still exhibit it. Teams need structural changes that make unbiased reviews easier than biased ones.
- Anonymous code review pilots remove author identity during initial review, eliminating halo effects, authority bias, and in-group bias. Once technical feedback is provided, authorship is revealed for discussion.
- Review checklists counter availability heuristics and confirmation bias by forcing systematic evaluation. Instead of “does this feel right,” reviewers confirm “are there tests?” “is error handling appropriate?” “are variable names clear?”
- Rotating review assignments prevent in-group bias and fundamental attribution errors. When everyone reviews everyone occasionally, you can’t build fixed judgments about individuals.
- Explicit escalation paths for disagreements provide alternatives to groupthink. If you disagree with an approval, there’s a clear process for raising concerns rather than staying silent.
- Blameless incident reviews reduce fundamental attribution errors by examining systems, not people. When production issues arise, the question isn’t “who messed up” but “what circumstances allowed this.”
- Outcome tracking reveals bias patterns. If certain developers consistently have lower acceptance rates or longer review times, investigate whether technical factors or bias explains the difference.
18. The Junior Developer Paradox: Fresh Eyes See Clearly
Here’s a paradox: junior developers often spot issues that senior developers miss, yet their concerns are most likely to be dismissed.
Junior developers bring fresh perspective uncontaminated by assumptions. They haven’t internalized “how things work around here.” When something seems odd, they question it rather than assuming there’s a good reason.
A junior developer asks: “Why do we parse the JSON response twice?” A senior developer, familiar with the code’s history, dismisses it: “That’s how the API client works.” But the junior is right—it’s inefficient legacy code that nobody questioned because it became invisible through familiarity.
This fresh-eyes advantage is systematically wasted because authority bias, the curse of knowledge, and power dynamics suppress junior contributions. Senior developers explain away concerns rather than investigating them. The message sent: your intuition isn’t trustworthy yet.
Teams lose enormous value this way. Junior developers’ questions often reveal implicit complexity, technical debt, or outdated assumptions that senior members stopped seeing. But only if teams actually listen.
The solution requires explicit cultural commitment: junior insights are valuable, questions reveal problems not ignorance, and “I don’t understand this” is useful feedback rather than confession of inadequacy.
19. Conclusion
Code reviews fail not from lack of technical skill but from unexamined psychology. Authority bias makes us defer to seniority over correctness. Groupthink silences dissent to preserve harmony. Confirmation bias makes us see what we expect rather than what exists. Understanding these forces—from the halo effect to the fundamental attribution error—transforms code review from technical theater into genuine collaboration. The smartest teams build systems that counteract these biases through anonymous reviews, explicit disagreement protocols, and cultures that value junior insights. Better code emerges not from better developers, but from better psychological awareness.
