Code review in most teams has drifted into two failure modes at once: a rubber stamp on large changes nobody has capacity to read properly, and a pile of comments about naming and formatting on small ones. Both feel like process and neither catches the defects that matter. Fixing it is mostly about removing what machines should do and being explicit about what humans are for.
Start by automating everything mechanical. Formatting, import order, linting, type checking, test execution, coverage thresholds, dependency scanning - all of it belongs in CI, failing the build before a human looks. Every comment a human writes about a missing semicolon is a signal that the pipeline is incomplete, and it costs reviewer attention that should have gone somewhere else.
Then say what review is for, because unstated expectations produce inconsistent reviews. A useful list: is this solving the right problem, will it behave correctly under concurrency and failure, are the edge cases handled, does it introduce a security or privacy issue, will the next person understand it, and is it tested where it matters. Those are judgement questions, which is precisely why a person is doing this.
Size is the strongest predictor of review quality. A change of two hundred lines gets read; a change of two thousand gets approved. If a piece of work is inherently large, split it into a sequence of small merges behind a flag rather than one enormous one at the end. Reviewers should be allowed - encouraged - to send back anything too large to review honestly, and that should not be treated as obstruction.
Latency matters more than people expect. A review that sits for two days blocks the author, who context-switches to something else and has to reload the problem when comments arrive. Same-day review as a team norm removes a surprising amount of friction, and where a change is genuinely urgent, reviewing together on a call takes twenty minutes and beats a day of asynchronous back-and-forth.
On tone, one convention helps more than any style guide: mark comments as blocking or non-blocking. Much of the friction in review comes from an author unable to tell whether a remark is a requirement or a musing. Say which, and prefer questions to instructions - asking what happens when this is empty is more useful, and lands better, than asserting that it is broken.
