I think the underlying problem with this debate is a widespread failure to understand the purpose and practicality of reviews. Actually I see this pattern repeated with many other practices in our field : tests for example. It's a kind of mass delusion, imho.
Yes having human #2 look at whatever code human #1 wrote with the goal of improving it and catching errors, is in the abstract a good idea.
But _requiring_ all code to be reviewed before merge to main, while allocating no real resources to that activity, while also expecting high velocity of development, is magical thinking.
It typically leads to "software engineering theater". Code reviews look to be happening, but for the most part they're not. And worse: some things don't get fixed because the participants see review as an obstacle unworthy of their energy to surmount. Some great features don't get developed because the engineer with some spare creativity perceives that their weekend efforts may be for naught due to ensnarement in review webs.
I think the author is on the right track by at least refusing to enter into the delusion, and rejecting the magical thinking.
Yes having human #2 look at whatever code human #1 wrote with the goal of improving it and catching errors, is in the abstract a good idea.
But _requiring_ all code to be reviewed before merge to main, while allocating no real resources to that activity, while also expecting high velocity of development, is magical thinking.
It typically leads to "software engineering theater". Code reviews look to be happening, but for the most part they're not. And worse: some things don't get fixed because the participants see review as an obstacle unworthy of their energy to surmount. Some great features don't get developed because the engineer with some spare creativity perceives that their weekend efforts may be for naught due to ensnarement in review webs.
I think the author is on the right track by at least refusing to enter into the delusion, and rejecting the magical thinking.