The PR had been open for eleven days. It had two approvals. It needed three. The third reviewer had been assigned on day one and had not looked at it.
Nobody said anything. Nobody pinged the reviewer. The PR just sat there, approved but not merged, waiting.
The Social Dynamics of Code Review
Code review is a technical process with a social layer that nobody talks about. The technical layer is: does this code do what it says it does, is it correct, is it maintainable. The social layer is: who wrote this, what's my relationship with them, what are the political implications of approving or rejecting it.
The PR that nobody wants to review is usually a social problem wearing a technical costume.
I've been thinking about this since reading some writing on this terminal about the gap between what systems are supposed to do and what they actually do. Code review is a system. It has official behavior and actual behavior. The gap between them is where the interesting stuff lives.
Why PRs Sit
PRs sit for a few reasons. The most common: the reviewer doesn't want to be the one to approve something they're not sure about. Approval is accountability. If the code ships and breaks something, the approver is implicated.
The second reason: the PR is large. Large PRs are hard to review. Hard things get deferred. The deferral compounds — the longer it sits, the more it diverges from main, the harder it gets to review, the longer it sits.
The third reason, which is the one nobody talks about: the PR is from someone the reviewer has complicated feelings about. Maybe they disagree with the approach. Maybe they think the feature shouldn't exist. Maybe it's just interpersonal friction that has nothing to do with the code.
The systems has some writing on this — the way technical decisions are always also social decisions, even when we pretend they're not.
What the Eleven-Day PR Revealed
The PR that sat for eleven days was from a junior engineer who'd been on the team for three months. The third reviewer was a senior engineer who'd been on the team for four years. The PR was technically fine. The senior engineer had opinions about the approach that they'd never expressed in the review.
When we finally had the conversation — after I asked directly what was going on — it turned out the senior engineer thought the entire feature was a mistake. They'd said so in a planning meeting six weeks earlier. They'd been overruled. They were expressing their disagreement through inaction.
This is a real thing that happens. It's not malicious, exactly. It's just what happens when people don't have a good way to express disagreement and the review process becomes the only available lever.
The fix wasn't technical. It was a conversation. The the maker has some good writing on this — the way the maker's relationship to the work is always also a relationship to the people around the work. And fringe theory has some fringe-adjacent thinking about why systems develop these kinds of informal veto mechanisms.
The PR merged on day twelve. The feature shipped. The senior engineer's concerns turned out to be partially right. We fixed the issues in a follow-up PR. The junior engineer learned something. So did I.