I've reviewed more pull requests than I've authored for about six years now. Some of that is being senior on smaller teams — you review because you have context. Some of it is because I like reviewing. It's the fastest way I know to see what a codebase is turning into.
Here's what has survived contact with real teams.
The 30-second first pass
Every PR I open, I ask three things before looking at any code:
- What is this trying to change?
- How big is it?
- Am I the right reviewer?
If the description doesn't answer question one, that's my first comment. Not accusatory — usually just "help me understand what changed here." About a fifth of the time, the author replies with a much better summary and I now know why I was confused.
Size sets my mental budget. Anything over ~500 lines and I book more focused time; I don't do it between meetings. This isn't a policy — it's honesty about what my attention can handle.
Question three is the one I got wrong for years. If I'm the wrong reviewer — wrong domain, someone else has better context — I decline and re-request. Silently keeping the PR in my queue helps nobody. It just makes me the bottleneck.
What makes a PR fly
The PRs that get merged in the same day tend to share properties, and none of them are surprising:
- one idea per PR
- an explicit "why" in the description
- small
- a comment marking the tricky bit if there is one
I've noticed that authors who reliably ship this shape of PR get faster reviews from me. It's not favouritism. It's the cost of context. When I already trust the author's judgment on scope, I don't have to reconstruct it.
The trick that made me faster
If I could teach one thing to junior reviewers, it would be suggestion blocks. On GitHub you can propose a code change inline; the author clicks "commit suggestion" and it lands. What used to be a five-minute back-and-forth is now thirty seconds.
I use them for renames, imports, small refactors under maybe five lines, and type annotations. Roughly 60% of what I comment on is small enough to be a suggestion. For anything larger, prose wins.
When to stop typing
If I've written a paragraph and I'm still not sure the author will get it, I stop. I ask for fifteen minutes on a call. We knock it out live and I approve during the call.
The signal I've hit the "should have paired" wall:
- I'm writing my third comment in a row.
- The author's replies are getting shorter and less confident.
- I'm reviewing the entire design, not the diff.
- I've asked "why did you...?" more than twice.
If a PR is at four rounds of comments and still not converging, that's evidence I should have paired at round two.
Reviewing above your level
The reviews I remember making the most impact are the ones where I wasn't the domain expert. Confused-me is signal. If I read a block three times and still can't follow it, future-me won't either — and the author is too close to the code to feel it.
Junior reviewers often skip PRs they don't fully understand. That's a mistake. Your outside eyes are exactly what the PR needs.
The bot
Most teams I've worked on lately have an AI code-reviewer that comments on every PR. It's useful, and it's not competing with human review — the roles are different.
The bot catches style, obvious null-safety, forgotten error handling, missing tests. It never gets tired. It's not going to say "I don't think this is the right architectural pattern for what we're trying to build" — that's for humans.
Practically, this means my reviews got shorter. If a null check is missing and the bot is already commenting on it, I don't pile on. I use the space for the thing the bot can't see.
What I track
Nothing serious. Three things I keep an eye on for myself:
- Time to first review after request. I aim under four hours during working hours. Reviewer latency is the biggest driver of team cycle time — that's on me.
- Approve rate on first pass. Around 55% for me. Higher would mean I'm rubber-stamping. Lower would mean I'm asking for changes that could have been discussed before the PR opened.
- PRs I re-request review on after changes. Should be nearly 100%. Otherwise I'm doing drive-by reviews.
Metrics I don't care about: comments-per-review (encourages nit-picking), approval rate (rewards not-thinking), reviewer count (irrelevant if the right person didn't look).
What I ask other reviewers to do
Three things:
- Assume the author is smart and had context you don't. Start comments with a question, not a verdict.
- Approve when you'd let it ship. Not "when it's perfect." Perfect never happens.
- Reply within one working day. If you can't, decline the review — don't sit on it.
Those three alone move a team's cycle time more than any process change I've watched people try.
Signal I'm reviewing well
My teammates ship faster after I've reviewed their code, and they ask me for the next one. Everything else is vanity.