> Pull requests discourage trust. Proposing every code change that somebody else has to approve doesn't feel encouraging...<p>I can't get behind this one. Sure, you can spin it this way, and maybe if you were in a traumatic environment with jerks as reviewers you might think this is a universalizable statement. But in a good team with good communications, pull requests are a good way of getting folks on the same page<p>> Pull requests don't prevent bugs.<p>Objectively false. (And trivially falsifiable; I'd bet every reader here has either found a bug in someone else's PR or had a reviewer find a bug in their PR in the last month. I know I have, on both counts.) They don't prevent _all_ bugs, but they do prevent some bugs. Lots of research on this, the general push for "shift left" is based on empirical findings that it costs less to fix a bug the earlier in your process you catch it.<p>If the author meant "don't prevent all complex bugs", then sure, but I feel that's an unreasonable demand for any process; you don't have to catch all bugs in order to provide a positive ROI.<p>> We rely on fast iterations with user feedback.<p>If your business model is not hurt by shipping bugs to users, then the value of fixing bugs before you ship is low. More mature products/companies don't really have this option.<p>> Pull requests slow down. Code reviews aren't high priority for engineers. They have to make time to clean up their review queue. In reality, PRs are an afterthought and not what you want to spend your time on as an engineer.<p>I think this is the actual problem. Many orgs have a code review process that makes it painful for developers to iterate quickly on their ideas. You can avoid this problem by not doing code reviews, or you can fix this problem by doing code reviews better. The latter is hard though! If you make "PR response time" a metric for your team, create a slackbot to nag on outstanding PRs, and generally as an engineering leader keep the focus on fast reviews as a priority, then you can make this a cultural strong-point instead of being a source of drag.<p>"Accelerate" by Forsgren et. al. talks a lot about 1) the value prop of, and 2) some techniques for, speeding up the cycle time from commit-to-production and idea-to-production. This is not easy, but I think in most cases (i.e. for most company/team sizes), dropping code reviews is throwing out the baby with the bathwater.<p>More generally, I think this post is falling into the (very common) trap of giving uni-directional advice; "reviews slow us down, therefore they are bad", rather than more nuanced analysis like "for our stage where quality is far less valuable than iteration speed, we think it's not a good investment of time and effort to build a strong mandatory reviews process". This is a fine position to take, though it's less snappy and I suspect won't get you onto the front page of HN. But you don't need to make claims about how code reviews damage trust or don't actually provide value to justify this tradeoff.<p>And if you're honest about why you're making the tradeoff, you'll be better placed to change the decision when the tradeoff falls in the other direction; a company that builds into its DNA the idea that "Code reviews harm trust" is going to avoid mandatory code reviews well past the point that they would provide positive ROI.