Meta researchers suspected the bystander effect was slowing their code reviews when a group — rather than one person — got asked to look at a change. They tested it, confirmed it, and shipped BystanderRecRnd, a recommender that assigns a single reviewer so the "someone else will take it" delay stops happening. The paper is worth reading on its own. It is also one of five biases that quietly decide which PRs pass fast and which ones get picked apart, independent of code quality.
The other four — halo, authority, framing, ownership — show up every day in reviews that look technical from the outside. This piece walks through each one with where it fires, and the mechanism that stops it. Not vigilance. A mechanism. Reminders to "be careful" survive about a week.
1. Halo effect: the senior PR passes faster
The halo effect is the oldest finding in applied social psychology, replicated so many times it stopped being news. In code review it shows up as this: the same diff, submitted by a senior and by a new hire, gets different scrutiny. The senior's code is "they probably have a reason." The new hire's is "they haven't learned yet."
The inverse also fires. An engineer who shipped a famous bug last year gets careful reviews on code that is objectively fine. The halo rots in both directions.
I have been on both sides of this. The senior PR with a design flaw that got waved through, and the junior-era PR with a reasonable choice that got picked apart line by line. Neither reaction was really about the code.
The amplifiers in a modern codebase are visible:
- GitHub commit count, PR frequency, OSS contributions on the sidebar
- Prior employer (ex-FAANG, maintainer of a known OSS project)
- How carefully written the PR description is — people assume the writing style predicts the code
The mechanism
Hide the author from yourself for the first pass. Open the diff tab, not the PR summary. Form a technical read of the code before you look at who wrote it. The vigilance version — "I will try to be fair" — has been measured and does not work. The structural version — "I read the diff before I see the name" — does.
Pair it with a fixed checklist (security, performance, test coverage, readability). A checklist does not stop you from being charitable to the senior; it stops you from skipping items for the senior and inventing items for the new hire.
2. Authority bias: tech leads get LGTM on auto-pilot
Authority bias is subtle because it does not look like a bias. The tech lead's PR gets approved because, in most cases, the tech lead's PR is actually correct. The bias is the margin. It is the fraction of approvals where the reviewer thought "this looks off" and did not comment, because the reviewer assumed the lead had a reason.
Over a year that margin compounds. The architectural choices that quietly went unchallenged are the ones that survive into legacy debt.
How to use it as a reviewee
The flip side is a tool. When you want a proposal to land, borrow authority deliberately:
- Cite the official docs or RFC for your design choice in the PR description
- Reference industry patterns or a specific paper for an architectural change
- Ask a trusted senior for a pre-review, then mention the feedback was already applied
The ceiling of this technique is low. Borrowed authority does not improve the code; it only lowers the friction of the review. Use it where you are confident the proposal is right and the friction is costing you time.
The mechanism against it
For reviewers: when the author is a senior, switch to question-form comments. "Is this intentional?" lowers the social cost of a reply from the author, so you get the clarification instead of eating the uncertainty. "This is wrong" from a junior to a staff engineer rarely gets sent. "Why this instead of X?" gets sent.
3. Bystander effect: reviews that never start
This is the Meta finding. When a review request fans out to a team instead of a person, the review starts later. Everyone assumes someone else will pick it up. Nobody does. The PR sits.
Meta's team at Facebook rebuilt reviewer recommendation specifically to kill this. One reviewer, named at request time, with the group as fallback. Review start time dropped.
The mechanism
- Default to single-reviewer requests. Group requests are a fallback, not the primary mode.
- When you must request a group, name a point person in the first comment. "@alice primary, @team as backup" removes the ambiguity even if the UI does not.
- A review older than 24 hours gets a direct ping, not a reshare into the group. Resharing distributes the "someone else" button to more people.
4. Framing effect: same bug, different reaction
Dr. Michaela Greiler, who studied code review feedback at Microsoft and now consults on code review culture, notes that aggressive feedback tends to slow down fixes and drag down the quality of the author's next PR, even when the technical content of the comment is identical to a constructive version.
The same N+1 bug, two framings:
- Negative frame: "This N+1 query will cause performance problems. Fix it."
- Positive frame: "If you switch this to eager loading, the query count drops from N+1 to 2. On production traffic the difference should be noticeable."
The technical content is identical. The receiver's reaction is not. One sounds like a problem report. The other sounds like a tip. Michael Lynch, formerly of Google, has a longer set of guidelines for code review comments; three of them do most of the work:
- Talk about the code, not the author. "This line can produce a NullPointerException" is reviewable. "You messed up here" is a feelings reply.
- Attach a why. "Change this" without a reason triggers a defensive reply. "Change this because X returns null in the pagination edge case" triggers a fix.
- Use questions where possible. "Could
fooreturn null here?" opens the conversation. "This is a bug" closes it.
The mechanism
A review comment template with three fields — "what", "why", "suggestion" — forces the framing. The field with "suggestion" at the end makes the comment hard to leave hostile without actively choosing to.
5. Ownership bias: taking the review as criticism
The last one lives on the receiving side. If you wrote the code five minutes ago, your sense of ownership is at its peak, and every comment reads as a judgment of you, not of the diff. The defensive-reply reflex fires. You start arguing with suggestions that, read a day later, you would just accept.
I have the Slack history to prove it: suggestions I defended at 11pm, merged at 9am the next morning without changing a single argument against them. The code did not improve overnight. I did.
The mechanism
- Submit the PR a few hours after you finish, or the next morning. Ownership fades with distance. Comments read differently after one night of sleep.
- Reframe the artifact. The codebase is a team's shared product, not a portfolio of personal creations. The reframe sounds abstract and feels silly, until the first time you accept a suggestion that an hour ago you would have fought.
- Reviewers: name one thing you liked in the PR before any comments. "The test naming is clean" is not politeness; it signals that the review is about the diff, not an attack on the author. Reviews that are 100% suggestions trip the ownership reflex.
Why mechanisms, not reminders
Across all five, the pattern is the same. Reminders to "be aware" of a bias do not survive the next sprint. Mechanisms do. Hiding the author on the first pass is a mechanism. A single-reviewer default is a mechanism. A comment template with a "suggestion" field is a mechanism. Submitting a PR the next morning is a mechanism.
Code review is a technical filter and a social situation at the same time, and the social half is the one that decides whether the technical half ever lands. If you want the full set — 20 biases that distort estimates, meetings, and hiring, each with a mechanism rather than a reminder — the book collects them in one place:
Top comments (0)