[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.