[millstone]

Code review makes you vulnerable to priority inversion. I need this change in now, to meet some deadline, but the reviewer has other priorities. Reviews pile up.

When this happens, a common response is to go work on something else, but this only exacerbates the problem: now you have a bunch of commits awaiting review which are dependent in various ways. If I merge this commit I have to go and fix up that one, and that other one. My work becomes quadratic, nursing a bunch of commits along while waiting their turn through a tiny review pipeline. 5% can be 100%.

[chris_va]

This can happen if code reviews are not done well, I agree.

Things can be just as bad if code is not written well.

Doing either well requires good engineering practices and skill. It is part of the profession that you acquire over time, like anything else that can improve development.

Now, sometimes you are at the mercy of a system not filled with really experienced engineers. In such a system, though, I think skipping code reviews for expediency will probably be even worse in the long run.

[millstone]

I was speaking more about the team organization. Code reviews increase in cost as the team becomes more heterogenous and more distributed. If your team consists of a kernel engineer in Paris and an Angular developer in San Francisco, code reviews will be high cost and low value no matter how experienced the devs are.

I agree with you, even in the ideal case of a co-located homogeneous team, it's possible to screw up the process.

[chris_va]

Completely agree.