Block vs approve

Disagree on the diff with evidence: correctness risk, operational cost, consistency with existing patterns. If you are circling after two rounds, take it offline (huddle, whiteboard), then post the decision on the PR so the record stays complete. Escalate to a tech lead when the disagreement is architectural and stuck — see collaboration.

Google's guidance favors approving improvements over holding for perfection. The reciprocal duty: authors must not dump unfinished design into review to "start the clock." Meet in the middle — ready PRs, fast substantive feedback, nits labeled.

Walking through a stuck thread

After two rounds of the same argument, stop typing. A 15-minute huddle plus a posted conclusion beats another day of comments. The PR is the archive: "Decided to keep the double-write for two weeks; rollback is flag-off; follow-up T-123 removes the old path."

Avoid force-of-will merges while a blocking thread is open. Renegotiate the blocking bit instead: downgrade it to nit: with a ticket, or change the code.

Authors: push back with evidence ("benchmark shows allocations are flat") not ego. For valid nits you will not fix now, file the ticket or land a 10-line follow PR immediately.

If the disagreement is taste (naming, extra extraction) and the change already improves code health, approve and optionally nit. If it is a lock on a large table or a public API you cannot undo, block.

Common mistakes

• Blocking on taste while a safer, smaller improvement sits unmerged.
• Approving an unsafe migration to be "unblocking."
• Thread circling. Two rounds, then huddle, then write the decision on the PR.

Check yourself

1. When do you block rather than approve-with-follow-up?

When the change is wrong, unsafe, or expensive to undo — migrations, public APIs, authz holes.

2. The thread has gone two full rounds. What next?

Take it offline, then post the decision on the PR.

Key takeaways

• Block safety and irreversibility; approve improvements with tracked polish.
• Two rounds then huddle; the PR keeps the record.
• Authors meet reviewers in the middle: ready diffs, labeled nits.

Further learning

Google Engineering Practices: Code ReviewGoogle’s Engineering Practices documentationeng-practices

Next: ops and security in review.