You open it and your stomach drops. Forty-seven files changed. Two thousand lines added. The description says "fixes the thing we discussed." No context on what was tried and discarded, no mention of what to look at first, just a wall of diffs and an implicit expectation that you'll approve it because reviewing it properly would take the rest of your afternoon.
That pull request tells you everything about the person who opened it, and none of it is about their coding ability. It's about whether they understand that a pull request isn't a deposit of finished work. It's a request for someone else's attention and judgment, and treating it as an afterthought after the "real work" is done is one of the clearest signals of where someone actually is in their career, regardless of how many years show up on their resume.
The code was never the hard part
Here's an uncomfortable truth for anyone who thinks writing correct code is the ceiling of seniority: the code inside most pull requests is fine. It compiles, it passes tests, it probably does what it's supposed to do. What separates a senior engineer's pull request from everyone else's isn't correctness. It's whether they made the reviewer's job possible.
A junior engineer optimizes for finishing the task. A senior engineer optimizes for the total cost of the change, and that cost includes every minute someone else spends trying to understand what happened and why. That shift, from "is this done" to "can someone else safely approve this in reasonable time," is one of the actual markers of seniority, and it rarely gets named directly because it's not a skill anyone puts on a resume.
Scope is the first tell
The description is doing real work, or it isn't
Most pull request descriptions restate the diff in prose. "This PR adds a caching layer to the user service." The reviewer already knows that; they're looking at the code. A description that's actually useful answers questions the diff can't: why now, what alternative was considered and rejected, what's risky about this specific change, and what the reviewer should focus their limited attention on.
That last part matters more than people give it credit for. Telling a reviewer "the retry logic in the third file is the part I'm least confident about" isn't admitting weakness. It's respecting their time by pointing it at the place it's most needed, instead of making them apply equal scrutiny to three hundred lines when two hundred and eighty of them are mechanical.
Commit history is a communication tool, not a diary
A commit history that reads "wip," "fix," "actually fix," "remove console.log" is a private diary of how the work happened, and it should stay private, squashed or cleaned up before it reaches a reviewer. That history isn't dishonest to erase. It was never meant for anyone but the person who wrote it.
A commit history that reads as a sequence of intentional, reviewable steps (extract the interface, implement the new provider, wire it into the existing call sites, remove the old provider) does something a diff alone can't: it lets a reviewer approve the change in the order it makes logical sense, and catch a problem in step two without needing to understand step four yet. That structure takes deliberate effort to construct after the fact, and skipping that effort is one of the most common ways senior-level work gets read as junior in review.
What good review culture actually costs
None of this works unless the team treats review time as real work, not overhead squeezed between meetings. If reviewers are expected to approve things within minutes between other obligations, engineers will learn, correctly, that a smaller and cleaner pull request doesn't get reviewed any faster than a huge messy one, because nobody has the time to read either one carefully. In that environment, the incentive to build a clean, scoped, well described pull request quietly disappears, no matter how many blog posts the team has read about it.
Fixing this isn't about writing a better pull request template. It's about a team explicitly agreeing that review is scheduled work with real time attached to it, not something squeezed into the gaps of a calendar already full of meetings. Teams that protect review time see the quality of pull requests improve on their own, because engineers stop assuming careful framing is wasted effort nobody will actually read.
The reviewer's side of this deal
None of this is a one-way obligation. A reviewer who leaves "looks good" on a forty-file pull request without reading it isn't being efficient, they're passing the risk downstream to whoever finds the bug in production three weeks later. And a reviewer who nitpicks variable names on a pull request that never should have been this large in the first place is solving the wrong problem: the issue was scope, not naming, and no amount of comments on naming fixes that.
A good reviewer asks for a split before diving into line comments when a pull request is trying to do too much at once. That single habit, pushing back on scope before reviewing content, does more for a team's code quality over a year than any amount of careful line-by-line commentary on pull requests that should never have existed in their current shape.
What this looks like in practice
None of this requires a formal process or a new tool. It requires a habit: before opening a pull request, ask whether someone with zero context on what you were doing could understand what changed and why within the first two minutes of reading it. If the honest answer is no, the fix usually isn't writing a longer description. It's often splitting the change, reordering the commits, or cutting scope until the answer becomes yes.
That habit costs a few extra minutes per pull request. It saves hours of reviewer time across a team, week after week, in a way that never shows up in a sprint retro but shows up constantly in how fast a team actually ships.
The size argument nobody wants to have out loud
Every team has an unofficial tolerance for pull request size that everyone quietly accepts and nobody writes down. That tolerance is usually set by whoever's largest recent pull request got approved without pushback, and it only moves in one direction: up. Once a five hundred line pull request gets waved through because everyone was busy that week, a three hundred line pull request stops looking large by comparison, and the whole team's baseline shifts without anyone deciding it should.
Why this matters more once you're distributed
This entire argument gets sharper the moment your team isn't sitting in the same room. A confusing pull request in a co-located team gets fixed with someone walking over and asking "wait, what's this doing." A confusing pull request across time zones means the author is asleep by the time the question gets asked, and the answer doesn't arrive until the reviewer has moved on to something else, at which point the review restarts from zero the next day. Teams that work across LATAM and US time zones pay this tax constantly, and the ones who write pull requests as if the reviewer can't ask a quick question in real time (because they usually can't) ship noticeably faster than the ones who don't.
The take
Nobody gets promoted to senior for writing a pull request someone else can review in five minutes instead of fifty. But that skill, treating a pull request as a piece of communication aimed at another person's limited attention rather than a deposit of finished work, is one of the most reliable signals of where someone actually is in their career. It doesn't show up on a title. It shows up every time you open their diff.
