At x264 we've been doing code reviews for years -- the effect is so dramatic that I'd never do anything else ever again if I could help it.
Every single patch is reviewed by (at a minimum) both main devs, and preferably some other people too. The effects are many.
Everyone understands, to some extent, all the code that's committed. We don't end up with black boxes that only one person has any idea about.
A huge number of bugs and bad design decisions are caught. There isn't a programmer in the world who can't benefit from another person's perspective. Code review forces discussion about the choices made in a patch.
Finally, it also lets less-experienced programmers join in; you don't have to be a super hacker in order to comment on parts of a patch, and we welcome comments by literally anyone. There have been many bugs or dubious choices that were found by people who had very little knowledge of the overall codebase.
Working without code reviews is the sign of either an egotistical programmer or a project that has been so resource-crunched that the result will end up as a pile of hacks anyways. I would never recommend it outside of testing and prototyping.
Development is mostly prototyping -- you may work on a big project but you end up prototyping a solution to each of the small problems that happens (you know exactly how to solve a problem? great it takes little time to actually write the code, which means you will spend most of your time working on what you don't know) during the development.
After you have tryed different approaches to solve a particular problem and selected the best one, you want to hand the authority to decline that solution over to somebody who hasn't worked closely at the problem and has looked at only one solution for a few minutes? That can only end badly.
Development is mostly prototyping -- you may work on a big project but you end up prototyping a solution to each of the small problems that happens (you know exactly how to solve a problem? great it takes little time to actually write the code, which means you will spend most of your time working on what you don't know) during the development.
There's a difference between hacking it and doing it right. You hack something to see if it works, and if it does, you discuss it with others and decide the best way to do it right.
One of the largest features I wrote for x264 took 80 minutes to prototype, but a couple weeks of on-and-off work to make it work in all cases, find most of the bugs, and make it efficient. This involved discussing it with other people!
After you have tryed different approaches to solve a particular problem and selected the best one, you want to hand the authority to decline that solution over to somebody who hasn't worked closely at the problem and has looked at only one solution for a few minutes? That can only end badly.
No, that can only end well. If you think that changes to code are better if you don't discuss them with other people, you're simply a terrible programmer. Programming is a team activity, and if you don't trust the other people on your team to read it over and talk about it with you, you or your team are completely dysfunctional.
> After you have tryed different approaches to solve a particular problem and selected the best one, you want to hand the authority to decline that solution over to somebody who hasn't worked closely at the problem and has looked at only one solution for a few minutes? That can only end badly
Conversely, any design decision that you can't justify or explain to someone else when called on it is probably a bad decision.
Your assumption is that "code review" means you hand over the code anonymously, and someone looks at it in isolation and either accepts or rejects it. (At the risk of No True Scotsman-ing) a real code review process involves feedback, questions, and two-way communication. It also requires that other team members be open-minded about other people's code and design decisions, which is a bar that not all dev teams pass.
That's not really how code review works though, it's a multi-way conversation between the people reviewing the code and the original author. If people suggest ways you could have done it differently and you worked out why those suggestions are unworkable, you tell them and then they can learn from your experience. On the other hand, if you make mistakes, they can tell you about them and you can fix them.
Now, if you think you won't make any mistakes at all, and any input any other developer might have is garbage compared to what you came up with in the first place...then you're an arrogant developer and I can't imagine anyone wanting to work with you.
Every single patch is reviewed by (at a minimum) both main devs, and preferably some other people too. The effects are many.
Everyone understands, to some extent, all the code that's committed. We don't end up with black boxes that only one person has any idea about.
A huge number of bugs and bad design decisions are caught. There isn't a programmer in the world who can't benefit from another person's perspective. Code review forces discussion about the choices made in a patch.
Finally, it also lets less-experienced programmers join in; you don't have to be a super hacker in order to comment on parts of a patch, and we welcome comments by literally anyone. There have been many bugs or dubious choices that were found by people who had very little knowledge of the overall codebase.
Working without code reviews is the sign of either an egotistical programmer or a project that has been so resource-crunched that the result will end up as a pile of hacks anyways. I would never recommend it outside of testing and prototyping.