No code reviews by default

Especially because a HUGE benefit of code reviews is exposure and knowledge transfer. For us it's a key area where anyone can get insight into the how and why, plus control their participation from requester/reviewer to passive observer. It's actually a pretty poor place to catch bugs introduced by new, junior devs.

If something hit production and caused a major fuck-up because there was no peer review process, then in all the places I've worked at the first action item in the post-mortem would be "we should introduce peer review." Otherwise someone would ask how we could ensure it wouldn't happen again, and no one would be able to say "because we trust them," and leave it at that. It would sound more like "I trust you will never make that mistake again," which sounds more like a threat. You also can't go to your clients and say "sorry, we let our team deploy stuff without reviewing because we trust them... so please continue to deal with our avoidable problems."

Thing is, I've lead my fair share of teams and I trust my team-mates and colleagues implicitly. It makes for a strong team. But we still do code review (peer review) because we want to build software that works well and support each other. We're not in the job to simply deploy code to prod as quickly as possible.

I'd also add that I think any software engineer should try and have the experience of working in a highly regulated field, like healthcare. It's hard to get an appreciation for why these things exist until you realise you're held to a much higher level of accountability because your oopsie moments can have much larger consequences. For me, it's been hard to go back to my old, cavalier attitude after that.

1. Let's separate the idea of code review from the GitHub Pull Request feature. They are often coupled, but they don't need to be. You could easily have a policy and a workflow that requires reviews, but doesn't care whether they happen before or after a merge. I'm pretty sure this is how things work at Etsy, and I know there to be a diversity of code review practices more broadly in high-performing engineering organizations.

2. Of course code reviews don't catch all bugs. This is the same argument that is frequently used to reject static type systems and memory safety. The purpose of code review is to ensure that more bugs are caught, the kinds of bugs that can be caught through code review. It also helps ensure that a high level of code quality is maintained, and that at least two people understand how a change works, which is good for team cohesion and resilience.

Absolutely not. This is a recipe for disaster and a terrible example to set for any upcoming engineers that haven’t had much industry experience yet.

Code reviews help me be more confident in my own work. Even if 90% of the time it’s fine, there’s always that 10% where a second pair of eyes catches a mistake or offers a suggestion that makes the code even better.

> Code reviews are not a tool intended mainly to catch bugs

Well, not to detract from your point (I agree), but what little research has been done in this area suggests that code reviews are actually one of the best ways to catch bugs: https://kevin.burke.dev/kevin/the-best-ways-to-find-bugs-in-...