When you work on a large enough codebase it's impossible to know all of the methods, edge cases, and unexpected impacts of adding or changing code. Code reviews are there to help you and everyone else. Even senior developers might not know that someone else has refactored code or added new reusable methods.

the intent is to reduce the number of bugs The intent covers much more than that.

Code reviews help to share knowledge within the team, making people more aware of what changes

Code reviews help junior to ramp up: feedback given during a code review is not just to spot mistakes, but also ask questions, and it’s a fantastic opportunity for 'juniors' to ask more senior devs why they did this or that, what are the benefit of this design (versus another idea they have), ...

Code review help more experienced developers review their assumptions, and verify their design and implementation are clear. Working code is not enough. We need to aim for maintainable and debuggable code. Only an external reader car judge if the code is obvious or not, and we need those extra eyes to raise questions and verify the stuff we write is obvious enough so that when we come back later to change it, debug it, improve it, we’ll find it obvious and we’ll be able to work on this.

Finally, from my point of view, code review is not about spotting other people mistakes, but more about sharing the blame ;-) Once you manage to make this shift of perception in people minds, then people want to be reviewed. If a bug is later found, all the reviewers own the bug, the responsibility is shared. Nobody wants to be the guy who introduced the issue. When there’s no longer one single person who introduced a bug, people do not fear the review, they ask for it.

All this only works if people are doing it seriously, with empathy. We need to foster a culture of blameless troubleshooting, and to share the knowledge and help teammates to ramp up and make progress. It’s not a competition, it’s team work!

Both love and hate them at different times ;) But I don't know how we lived without them, really. Code reviews serve many purposes:

• it's good way to share knowledge and improve general code quality
• it keeps reviewers up to speed on changes they otherwise wouldn't have seen
• teaches juniors better coding practices
• teaches seniors how to coach juniors
• it's a requirement for various forms of compliance
• catching bugs, as you said

I enforce code reviews, and I enforce discussion about code. First there are obvious mistakes that can be prevented. 2nd a critical viewer reads your code to understand it and can ask the simple question 'why'.

Which if the person cannot answer is an indicator that person did not know the why hence the what and the how should be checked more intense.

I want to improve and I want others to improve. You need to think and talk about it. But than I am the CTO/Lead so it's my job to be annoying because I have to live with the code when the dev is gone. Not that I want them to leave but some are interns/freelancers/students and it's just the way it is.

That's why I review everything and even allow 'loss of productivity' because those things need to be debated and cleared otherwise the mess just grows and grows. And there is this nice quote.

Nothing is as permanent as a temporary workaround (loads of sources all a bit different)

So yes I am a code nazi ;) and yes I believe code reviews help you to keep the code entropy in check.

I think it's good to have a second pair of eyes to spot mistakes.

It especially helps for junior employees, or really any time someone knows much more about some part than someone else.

It's also supposed to prevent malicious code, I think. But note that that only works if unreviewed changes are automatically blocked or reported, which isn't always the case.

One should probably search "// todo", run unit tests, linters and formatters (and obviously compilers) on any code before sending it to review.

To really determine, one would have to know how much time it costs to do, and how much time is saved with it (e.g. bugs and rewrites prevented, by spotting mistakes, enforcing uniform style).

I wouldn't be surprised if it saves about double what it costs.

We use it at work, and I even use it for open source projects with 2 people.