The Pull Request That Time Forgot: A Survivor's Guide to Review Purgatory

Somewhere in your organization's GitHub right now, there is a pull request that has been open for longer than some of your coworkers' tenures. It has comments. It has approvals — partial approvals, the kind where one reviewer said LGTM and two others have been 'reviewing' in the legal sense that they are technically alive and capable of reviewing. It has a junior developer who submitted it in good faith and has since had to rebase it four times because main kept moving.

This is review purgatory. It is not an accident. It is a system.

How Review Purgatory Gets Built

No engineering team sits down and consciously decides to implement a process where PRs age like unloved cheese. It emerges organically from a set of individually reasonable behaviors that combine into something unreasonable at scale.

Senior engineers are busy. That's true and worth acknowledging. They're in meetings, they're unblocking other people, they're writing architecture documents that may or may not get read. Code review is important but it's rarely urgent, and urgency is what drives calendars at most companies. So the PR sits in the queue, and the senior engineer intends to get to it, and somehow the week ends.

Meanwhile, the junior developer who submitted the PR is navigating a uniquely uncomfortable form of professional limbo. They can't merge. They can't move on to the next ticket without risking a dependency nightmare. They can ping the reviewers — but pinging senior engineers about their own PR feels like a social minefield that nobody gave them a map for. So they wait. They rebase. They wait some more.

The Silence That Isn't Neutral

Here's what the PR queue communicates that nobody ever says out loud: silence is a power move, even when it's unintentional.

When a senior engineer doesn't review a PR for two weeks, the message received by the submitter is not 'I'm very busy, please be patient.' The message received is a rotating cast of anxieties: Is the code bad? Did I violate an unwritten convention? Did I step on someone's domain? Is this feature even wanted? Junior developers, who have the least context for disambiguating these possibilities, are also the most likely to assume the worst-case interpretation.

The silence compounds. A PR that gets no feedback in the first 48 hours is statistically likely to sit for much longer — reviewers see the age on a PR and unconsciously interpret it as someone else's problem. The longer a PR ages, the larger the perceived review burden becomes, because now there are comments to read, context to rebuild, and possibly a conflict to resolve. Aging PRs repel reviews the way old leftovers repel volunteers in the office fridge.

The Gatekeeping That Wears a Quality Hat

Not all review delays are passive. Some are active, and they tend to follow a recognizable pattern.

The senior engineer opens the PR. They find something they don't like — not a bug, not a security issue, but a stylistic divergence from their personal preferences, or an architectural choice that differs from how they would have done it. They leave a comment. The junior developer addresses the comment. The senior engineer comes back three days later, satisfied with that change, and finds two more things they don't like.

This is not code review. This is a moving goalpost wearing a code review costume. Each round of feedback is technically valid, but the cumulative effect is a process that never resolves, because resolution requires the reviewer to actually approve something, and approval requires commitment.

Knowledge hoarding operates the same way, just less visibly. When a senior engineer is the only person who understands a particular subsystem and they are also the required reviewer for any changes to that subsystem, you have created a single point of failure that is also a single point of control. The PRs queue behind that person not because the code is bad but because the organizational structure has inadvertently given one individual veto power over an entire domain, with no process to escalate or time-box the review.

The Actual Costs Nobody Tracks

Organizations measure a lot of things. They measure sprint velocity, deployment frequency, time-to-merge on a good day. They rarely measure the cost of a junior developer who spent eleven days in PR purgatory and quietly started updating their LinkedIn.

Review bottlenecks are a retention problem dressed up as a process problem. Junior developers who consistently can't ship — not because their code is bad but because the review system doesn't serve them — don't stay junior developers at your company for long. They become junior developers at your competitor's company, where someone reviewed their first PR within 24 hours and made them feel like their contribution mattered.

Senior developers lose something too, though it's subtler. Every PR that ages in the queue is a context-switching tax when they finally do review it. They have to rebuild understanding of the code, the feature, and the conversation that's happened in the comments. A review that would have taken twenty minutes on day one takes forty-five minutes on day twelve. The delay doesn't save time. It just redistributes the cost to a worse moment.

What a Functional Review Culture Actually Looks Like

The fix isn't complicated, which makes it frustrating that it's so rarely implemented.

Review SLAs — actual, enforced time limits on how long a PR can sit without feedback — change behavior more reliably than any amount of cultural messaging about the importance of code review. When 'I'll get to it' has a deadline attached, people get to it.

Distributed review ownership means no single person is the required reviewer for any domain. Two or three people who understand a subsystem means the queue doesn't back up when one of them is in back-to-back meetings all week.

Feedback that distinguishes between blocking issues and preferences means junior developers can understand what actually needs to change versus what the reviewer would personally do differently. Labeling a comment as nit: or non-blocking: is a small habit that dramatically reduces the ambiguity that makes PRs feel like moving goalposts.

And honestly? Reviewing a junior developer's PR on the same day it's submitted, even for ten minutes, is one of the highest-leverage investments a senior engineer can make. Not because the code is always perfect. Because the message it sends — your work is worth my attention — is the kind of thing people remember when they're deciding whether to stay.

The PR is still sitting there. Day twelve. The junior developer just pushed a rebase. Nobody has commented yet. The clock is running.