My main goal in a review is to ensure the design of the system and approach to the change is resilient to errors (by me and the author). You have to assume there will be mistakes you can’t catch (still, catch as many as you can), but other factors heavily influence how bad the mistakes will be.

All good points. Maybe having worked a lot with concurrent and distributed system makes me distrustful of relying on unit/integration tests for correctness; I've seen too many concurrency issues pass CI validation. But unit tests also sometimes miss edge cases in more straightforward code, so I'm still a bit more cautious.

I also agree that merge requests should be short and understandable in 10 minutes, but IME this happy state often does not obtain in practice. It shouldn't, but it often does, whether it's mission creep, whether it's turning out that a change is more complex than originally imagined, or whether it is unavoidably complex and cannot be broken down further.

> IMO, the initial reading shouldn't take more than 10 minutes. More than that (so a big diff) it should have been discussed upfront, and the design agreed

Part of the code review process is to verify that the writer actually did build the agreed design too though.