Reviewers: respond fast, read the design first Intermediate

This page answers: how fast a reviewer should respond, in what order to read a PR, and when to approve despite open comments.

Respond fast, but don’t break your focus

Google sets a ceiling: “One business day is the maximum time it should take to respond”. At the same time: don’t interrupt yourself during focused coding; review at natural break points (after standup, after lunch, between two tasks).

More important than total time is that each individual response arrives quickly:

• If you can’t review everything in time, reply “I’ve looked at the design, details this afternoon” — still better than silence.
• Google notes that most complaints about the review process are resolved just by reviewing faster.

Practical habits for a backend team:

• Two fixed review windows a day (e.g., 10:00 and 15:00).
• An oversized PR: ask to split it into a chain of small PRs; if it can’t be split and there isn’t enough time, comment on the overall design and hand it back so the author isn’t blocked.

Design first, details later

Loading diagram…

• Read the description, then the files with the main logic (usually the service and tests), and only then DTOs, modules, config.
• Reading the tests first sometimes helps understand what the PR intends.
• If the design is wrong, stop and comment immediately — the author may be building further on it.

Approve with comments

Google allows approving with unresolved comments if:

• the author can be trusted to fix them, or
• the comments are optional, or
• they’re minor (sorting imports, fixing a nearby typo).

Say which case it is: “Approved, fix the 2 nits before merging, no need for me to look again”. When two people are in different time zones, one unnecessary review round costs a day.

Reviewers are responsible too

Google: reviewers have “ownership and responsibility” for the code they review, just like the author. If you can’t read carefully, say “I only looked at part X”; don’t approve the whole PR.

How to write comments so the author knows what must be fixed: see Writing comments.

Reviewer checklist

1. First response within one business day; if you can’t, say when you’ll look.
2. Read the description; should this PR exist? Is there a simpler way?
3. Read the main logic first; if the design is flawed, comment immediately and stop nitpicking.
4. Go through the “look here first” table: transactions, security, migrations, naming.
5. Do the tests check real behavior, cover edge cases, and fail when the code is wrong?
6. Every comment has a severity label; blocking ones have a reason (data, principle, convention), not a preference.
7. At least one praise: when there’s something genuinely worth praising.
8. Approve as soon as the PR definitely improves the code; say clearly whether the remaining comments need another look.

Next: Writing comments and handling disagreement.