No code reviews by default

This a far bigger issue for me than a lack of trust. Code reviews should be a high priority for your engineers, especially the senior ones.

People say this a lot then I look at their code reviews and their code reviews are basically the same. As I said in another comment the root cause of this crappyness is the fact that the majority of people can't code review for crap and they're rushing it.

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

This doesn't stop people asking. I have a default comment "This is a code style change and as a rule I don't do code style changes unless it's required by the code style guidelines because everyone has their own preferences for code style. If I was to do this change then I would have to do other change and that would result in lots of pull requests being updated just because the specific reviewer wanted it one way and then another reviewer on another pull request wanted it another way." Sometimes then go and have the code style changed stating "Iain won't do code style changes unless they're in the guidelines" which I personally feel is a bitchy comment about the fact they just bikeshedded on my pull request and I wouldn't the change.

> If the person doesn't want to make the change for the technical problem, then that's a culture problem in the team or company.

Here comes the crux, what if the other person just disagress with your assessment and decides the technical problem doesn't exist or business value of changing it makes it a bad idea to change? For example, in code review I create a table and someone comes a long and says that tables with a large number of columns is a performance issue. I disagree and point out that splitting it out and having multiple tables with joins is a performance issue. Now we have a whole confrontation. Someone points out a valid issue that would affect 1 out of 1 million users and would take 3 days to fix. Again confrontation. Sure you can say with the right culture these issues are easy to work around but the fact is office politics is such a big thing we have a phrase for it which everyone understands. So many people are trying to advance their careers that they all want to be seen as really good. And for most people the way they look good is by making someone else not look good.

1) Catch edge use case / business requirements misunderstandings

2) Mentor new hires/junior engineers on the ways things should be done (e.g. internal culture about some architecture/design).

BUT, I absolutely despise code reviews that nitpick on non documented or 'because I prefer that way' stuff:

1) Task tickets that only have a vague description, have their own 'play detective' about the requirements, but a lot of new ones surface during code review.

2) Requirements are met, but there are internal/personal technical directives that are written nowhere, are not enforced with automated checks and may dramatically change a feature/patch is implemented (I can only think about that guy that worked in a company in which only LEFT JOIN sql statements were allowed).

Fuck that noise.

In my experience, code reviews are awful in the same way that micromanagement is awful. It's based on a lack of trust, first and foremost. It's also insulting. What's more insulting is being forced to deal with unreasonable review comments.

More than once, I had the experience of spending several days working on a feature, only to be blocked by some unreasonable "team member" who has weird fetishes about spacing and variable names and such fluff. It's really frustrating and insulting.

What's more, it doesn't really contribute anything to actual code or product quality.

The overwhelming sentiment I see on comments supporting the mandating of code reviews on every single commit seems to be based on the idea that everyone is a junior who makes obvious mistakes that are easy to catch by just having someone else take a look at the code.

I suppose this should not be very surprising.

I've noticed in the last few years more and more companies prefer to hire beginners (since they are cheap), and there's a huge wave of people who are learning programming to improve their careers and their lives -- which is a good thing for these people -- but it means a lot of teams are full of newbies.

So it makes sense in this context to install a lot of "guard rails".

What I don't understand is why everyone thinks mandating code reviews is a good idea in the general case.

...when they need it. Actually, really good engineers will ask to pair when they need it. Review is a distant second.