No code reviews by default

> Pull requests discourage trust.

Good. You shouldn't trust my code until it's been reviewed. I don't even trust my own code until its been reviewed! I've gotten much better with time specifically because of the things I've learned from reviews, but having another pair of eyes on my code still frequently uncovers things I overlooked while in the weeds.

> Pull requests don't prevent bugs.

This is just wrong. It doesn't prevent all bugs, but nothing does. Reviews, testing, static analysis, requirements, proofs - they're all designed to improve confidence in software. They all work to varying degrees, but none of them are perfect.

> Pull requests slow down.

Good. This is a feature. If a change is big enough that it takes significant time for another qualified engineer to review, there's a high chance that an issue will be uncovered. At the very least, it ensures another engineer is familiar with the changes.

If reviews drag on because engineers don't treat them as high priority, then that's a culture problem - not a problem with reviews.

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.

> Any issues of style should be in the style guide. Anything not in the style guide can be ignored. Or the style guide should be updated.

I find that there are two components of style:

- Formatting

- Clean abstractions, modularization... everything else that goes into making you a great (not just passable) programmer

Formatting should be handled by tools like others have said. For everything else I have the options:

- Turn the style guide into a book which no one will ready anyway

- Ask them to read an actual book but it isn't practical in the scope of a PR, and even after reading the ideas take a while to digest

- Attempt to mentor the employee via the PR, often appearing pedantic because it's hard for a novice to appreciate what they don't know.

- Code that passes CI is working code - screw everything else!

I take the mentoring route whenever it's presented to me but have generally found that some other team members (especially as they get older) have no interest in best practice and become annoyed by the code review process. If the mentee has persistence it tends to work out but moreso over 6mth-1yr timeframes. For mentees without the patience we drop the code review and keep them in areas of the code base where they can't do too much damage.

I guess what I'm trying to say is that our culture is willing to bend the processes to fit individual's strengths, and overall our workplace is pretty happy/chill. Maybe the engineering quality takes a hit but I can definitely sympathize with where the OP is coming from.

We do code reviews because people make mistakes, because code reviews are learning opportunities; not because we trust or not trust each other.

I've had a lot of trouble getting people to do proper reviews. A minimum to me is that you actually compile and execute the code in some way to check its sane. Better would be the reviewer actually adds to the test suite for the code to prove their expectations of how it works.

In almost all cases it's very hard to get people to look outside the web browser for the diffs. Diffs show you something, but never the whole context.

The other problem I've found is stamping down on style arguments: they have no place in code reviews, and a lot of the time you get a round of "please change this variable to be named something else" - which might be valid, but raises the question of why the reviewer didn't do it, and more often leaves a weird authority gap - I have no power to just reject such a request because I think it's invalid, nor does the business have anyway to resolve the issue. In fact if there's a dispute at all, very rarely is there any process for bringing in a third party to mediate or break the stalemate (which is hilarious in some ways since everyone by now should realize 2-party systems can't achieve consensus).

Code reviews are very, very cargo-culty and I've not seen them ever include a thorough design: people give up on the very near edge cases, and so the whole system falls apart because it's just a hurdle to get through and not a collaborative or constructive process.