How to reduce code review time

Why the wait matters

A pull request (PR) waiting for review blocks its author. They either sit idle or start something else and pay to switch back later. DORA’s 2023 research found that “fast code reviews significantly improve software delivery and operational performance” (opens in a new tab). And it’s not just throughput: Meta found a correlation between slow review times at the 75th percentile and engineer dissatisfaction (opens in a new tab). The slow tail is what people remember.

1. Measure the wait

Time to merge lumps together waiting, feedback rounds, CI and the author getting back to it. The piece you can move most directly is the first wait: from the moment a PR is ready for review to its first review by someone other than the author. It’s close to what some tools call pickup time, though they often start the clock when the PR is opened.

Start the clock at ready for review, since a draft isn’t waiting on anyone. Count working hours, because a PR opened at 5pm on Friday and reviewed at 9am on Monday wasn’t neglected. For a team spread across time zones, agree whose hours count, or the number will mostly measure geography. Leave bot reviews out, so an automated approval can’t make a wait look shorter than it was.

Then look at two numbers: the median for a typical week, and the slow end (the 75th or 90th percentile) for the PRs that sat for days. Meta’s data says the second one is what wears people down. Here’s how PullPro counts each of these.

2. Pick a number

Most teams never say out loud how fast a review should start, so everyone works to their own idea of it. Google’s engineering practices are blunt about the upper limit: “One business day is the maximum time it should take to respond to a code review request” (opens in a new tab). The same guide says quick individual responses matter more than the whole review finishing fast.

Inside that limit, pick a goal your team thinks is realistic, say one to four working hours, and track how many PRs meet it. Count a PR nobody reviewed as a miss, or the number improves exactly when things get worse. And watch review depth alongside it. A speed goal on its own rewards a quick “LGTM”, so keep an eye on how many merged PRs got a real human review.

3. Put a name on it

A review request sent to a whole team is easy for everyone to assume someone else has. Post the PR where the team already works and let one person claim it, or use GitHub’s CODEOWNERS and team auto-assignment to pick a reviewer for you. Either way, check who is actually doing the reviews. On many teams two people do most of them, and their queue becomes everyone’s wait.

4. Nudge the late ones

This one has a randomized trial behind it. Across 147 repositories at Microsoft, an automated reminder on overdue PRs reduced pull request resolution time by 60% (opens in a new tab) over 8,500 PRs. At Meta, a bot reminding reviewers about waiting changes cut average time in review by 7% (excluding weekends) (opens in a new tab), and the share waiting more than three days by 12%.

Remind the person who is actually blocking the PR, and only once it’s overdue. A reminder on every PR is noise, and people learn to ignore noise.

5. Make PRs easy to start on

Half of a fast review is on the author. A reviewer who opens a PR and can’t tell what it’s for tends to close the tab and come back later. Read your own diff first and strip out leftover debugging and unrelated changes. Say what changed, why, and where to start reading; a PR template makes that the default. Ask for review once checks pass, so nobody reviews code that’s about to change. And let CI argue about formatting and lint. Reviewers have better things to look at.

Small PRs help too, but mostly with the quality of the review. SmartBear’s guidance, from its study at Cisco, is to review no more than 200 to 400 lines of code at a time (opens in a new tab), because reviewers catch fewer defects past that. The link between size and speed is less settled than it’s often made out to be: a study of 845,316 PRs across 100 GitHub projects found that “pull request size and composition do not relate to time-to-merge” (opens in a new tab). Keep PRs small because they get better reviews, not because they’ll merge sooner.

6. Make review part of the day

Dropping everything for each review request just trades one delay for another. Google’s advice is to “wait for a break point in your work before you respond to a request for review” (opens in a new tab): after standup, after lunch, before starting the next thing. Plan for it, too. If a sprint is booked solid with feature work, reviews get whatever time is left over.

7. Look at it every week

Bring the numbers to the team: time to first review, how many PRs met the goal, and how many merged with a human review. That’s how you find out whether any of the above is working. Keep it at team level. Rank people and they’ll start optimizing for the number instead of the review.

Where PullPro comes in

That weekly look is what PullPro posts to each team’s Slack channel: time to first review in working hours, bots left out, against the goal you set. The metrics page adds the 90th percentile and the slowest PRs. In between, PullPro posts each PR once its checks pass, lets someone claim it in one click, and reminds the team about PRs nobody has picked up. See PullPro for engineering managers.