I don't assume my colleagues will always make "reasonable" choices and furthermore correctly express those choices into code any more than I will myself! In fac

I don't assume my colleagues will always make "reasonable" choices and furthermore correctly express those choices into code any more than I will myself! In fact perhaps most of the issues I find in PRs are after reviewing my own ones (often it's silly things like accidentally including files/commits I shouldn't've have). Plus knowing someone else must've approved my PR stops me feeling quite so silly if it does end up breaking something :) The breakfast order analogy to me falls down because not being able to merge a PR into the mainline branch immediately is exceedingly rarely something that holds me up - there's always plenty of other stuff to do. And the time I spend reviewing PRs is valuable in its own right, even if I find nothing wrong (understanding the codebase better etc.). Sure the odd PR or two for a truly trivial change slows up the works a little but they're pretty rare and a it's a small price to pay. Having said all that, I'm genuinely interested in what studies might have been done to genuinely guage the effectiveness of the PR/review process. I've certainly worked on some (open source) projects where it clearly was a major drag on productivity, as very few people had approval rights (wherever I've worked professionally all devs have the same rights - single approval from any other dev is always sufficient).