I wouldn't say I "hate" diff-based code review; it can serve a useful purpose; but I do find that unless I'm very familiar with the code being changed, I don't

I wouldn't say I "hate" diff-based code review; it can serve a useful purpose; but I do find that unless I'm very familiar with the code being changed, I don't have time to fully understand the impact of the proposed changes. It isn't until later, when I need to modify or extend a piece of code, that I do that level of analysis — and of course I often find problems then that no one else had noticed (often in my own code too). In my last job we didn't have a review requirement for commits; we mostly relied on this form of catching problems after the fact (and, of course, an extensive test suite). For experienced developers I thought it worked fine; it was only some of the junior people of whom I thought we should probably be reviewing their code more regularly. In my current job we do have such a requirement, and I have mixed feelings about it. There are still plenty of times I don't manage to catch mistakes before they get merged in, and the delays getting someone to review my PRs can be frustrating. The system clearly has some value, but it also has costs. I think I would allow most developers, after an initial probation period, to commit without approval, keeping in mind that someone who shows a pattern of committing bad code may lose this privilege.