[neo2006]

I don't see code review as an overwatch but a good communication tool and a way to think about problems collectively. Code review reduce bugs because it permit to have people think about the problem from multiple angles. About decisions, I think important design decisions need to be taken prior to the code review steps ,and also reviewed. I'm not sure what context you worked in that gave you that opinion about code review being a sign of distrust and I think the problem lay within the culture in those places not the code review practice it self.

[duncan-donuts]

I don’t mind code reviews so I’m not really defending who you’re replying to. There is another way to think about this tho and I actually have found this practice to be light years more effective than code reviews. Where I work we have a practice where before you start doing a ton of work on your card/ticket you should find someone on your team, explain the problem to them, and show them how you’re going to do the work. This gives your teammates an opportunity to give you feedback before anyone has done anything, and you can both poke holes in design decisions before anyone has done anything they feel strongly about. If you do this process 95% of code reviews are pretty much worthless.

[neo2006]

I fully agree, we also do this and this is the design review I alluded to. That said, I think both have different purpose. The design review is more about the approach and the high-level implementation. The code review is about the implementation details. Also, a great aspect often overlooked around code review is that it's a great teaching tool if used right. Asking question go a long way and make both the reviewer and the reviewee learn. Code review is often looked to as a senior watching over what juniors are doing. In my experience it should be done for all levels and even juniors should review seniors PR as they can bring novel perspective and at least learn from the code by reviewing it.

[epolanski]

I'm gonna rephrase my previous point. What you say makes sense, but only if you understand that it takes away time, money and energies and after knowing it, and the impact of all this time drag you determine it's worth it.

Might apply to huge products making millions $ every day. Sure, delivering a bug will be expensive.

Might apply when you can't trust your colleagues (not skilled, reasonable or experienced enough).

Might apply if your code is niche but mission critical (maybe some safety system on a car or a dangerous tool, or surgery equipment).

Of course I agree with all you said.

But you're writing some Java/TS web app which isn't raking much money, or has still to be launched, or your biggest focus is time to market to beat competitors and you're wasting time on code reviews the author hasn't requested?

In this scenario (my current client) I want to have a team I can trust and gets stuff done. This does not imply that CRs don't happen or design isn't discussed, but it happens when it brings value or it is needed. And I like it that way, where we can build stuff, rather discussing how to build it.

[neo2006]

If we want to include the cost of a code review into the equation we should also include the cost of fixing a big that made it to production which is in most of the cases higher then code review. Skill is not a factor here, I work and worked with some of the best engineers in the world and everyone write buggy code sometimes. Software engineering is a complex practice. If you are writing some prototyping code or some code that will never make it to production or in a very early stage of a startup, sure I can understand your point.