The PR That Never Dies: How Code Review Became Engineering's Most Uncomfortable Ritual

Open any engineering team's pull request history and you'll find them: the PRs that sat in review for a week, accumulated forty-seven comments, got revised three times, and eventually merged in a state that satisfied nobody. The code works. The author is exhausted. The reviewer feels vaguely victorious. The team has learned nothing useful.

Code review is one of those practices that every serious engineering organization does and almost none of them do well. The theory is sound — multiple sets of eyes catch bugs, spread knowledge, and maintain quality standards. The reality, at a lot of companies, is something closer to a performance. A ritual that looks like collaboration but functions more like a power structure.

Let's talk about that honestly.

What Code Review Is Actually Signaling

Feedback on a pull request is never purely technical. It's always also social. When a senior engineer leaves a comment on a junior's PR, that comment carries weight that has nothing to do with whether the suggestion is correct. It carries the weight of hierarchy, of evaluation, of 'someone with more status than me has an opinion about my work.'

Most senior engineers don't think consciously about this dynamic. They're just leaving feedback. But the junior engineer on the receiving end is processing every comment through a filter of 'is this person telling me I don't know what I'm doing?' That's not oversensitivity — that's a rational response to being in an evaluative relationship with someone who influences your performance reviews.

The result is a review culture where junior engineers make themselves smaller. They preemptively apologize in PR descriptions. They over-explain their choices to head off criticism. They accept feedback they disagree with rather than push back, because pushing back feels risky. And over time, they stop bringing their actual thinking to their work because the cost of having it criticized publicly is too high.

That's a massive waste of engineering talent, and it happens at companies that would describe their culture as supportive and collaborative.

The Nit That Ate the Review

There's a particular flavor of code review dysfunction that deserves its own name: nit dominance. This is when a review is technically thorough but disproportionately focused on style, naming conventions, and minor preference differences rather than correctness, architecture, or actual quality concerns.

'I'd rename this variable to be more descriptive.' 'This could be a one-liner.' 'We usually put the constants at the top.' These aren't wrong observations. But when they outnumber comments about logic, security, or design by a factor of ten, they've crowded out the actual purpose of the review.

Nit-heavy reviews are often a symptom of reviewers who aren't confident enough in their architectural feedback to lead with it, so they fill the space with surface-level corrections that feel safe and unambiguous. Or they're from engineers who've internalized a particular style so deeply that deviation from it reads as sloppiness. Either way, the author ends up spending their revision time on cosmetic changes while the structural question nobody raised quietly ships to production.

The fix here is embarrassingly simple: use a linter and an auto-formatter. Remove style from the human review loop entirely. If your team is still arguing about tabs versus spaces in 2024, you're burning review time on a solved problem.

Gatekeeping Dressed Up as Standards

Here's the darker version of the same dynamic. In some teams, code review has become the mechanism through which certain engineers maintain disproportionate control over the codebase. They're the ones who review everything, approve nothing quickly, and have a seemingly endless list of changes they'd like to see before they'll sign off.

This isn't always malicious. Sometimes it's just anxiety — an engineer who built a system is genuinely worried about changes to it, and review is their only lever. But the effect is the same: PRs stall, authors get demoralized, and the implicit message is that your code is never quite good enough.

Knowledge gatekeeping is the organizational version of this. When only one or two people are qualified to review certain parts of the codebase, every change to those systems becomes dependent on their availability and their approval. That's not a quality control system — it's a bottleneck with extra steps. And it means that the institutional knowledge those engineers hold never actually spreads.

What Review Could Actually Be

This isn't an argument against code review. Thoughtful review genuinely does catch bugs, spread patterns, and help teams stay coherent as they scale. But it requires treating review as a teaching and learning practice, not an approval gate.

A few reframes that actually change the dynamic:

Ask questions instead of making declarations. 'What was the thinking behind this approach?' lands completely differently than 'This should be refactored.' The first invites dialogue. The second closes it. Often the author has a good reason you didn't see — and if they don't, a question surfaces that better than a correction.

Separate blocking feedback from suggestions. Be explicit in your reviews about what actually needs to change before merge versus what's a preference or a 'would be nice.' Treating every comment as equally mandatory is how you get forty-seven-comment PRs that take a week to merge.

Review the decision, not just the code. The most valuable feedback isn't 'this function is too long' — it's 'I'm wondering if this belongs in this service at all.' That's the kind of review that makes engineers better architects, not just better typists.

Let junior engineers review senior PRs. Seriously. It's one of the fastest ways to build confidence and spread knowledge simultaneously. A junior engineer who has to read and evaluate a senior engineer's code learns more in that hour than in a week of passive observation. And seniors get a useful signal about what's actually understandable to someone newer to the system.

The Séance Ends When You Name What's Actually Happening

A lot of dysfunctional code review culture persists because nobody wants to name it. Calling out a senior engineer for gatekeeping or passive-aggressive feedback is uncomfortable. So teams keep performing the ritual, PRs keep dying slow deaths in review queues, and junior engineers keep learning that their instincts aren't to be trusted.

The engineering teams that get this right aren't the ones with the most rigorous review standards. They're the ones where review is psychologically safe enough to be honest — where 'I don't understand this' is as acceptable as 'this is wrong,' and where getting feedback doesn't feel like surviving a haunting.

That's a culture choice, made one PR at a time.