[spankalee]

Bikeshedding in a team can be good. If you're all painting the shed, it helps to agree on the color.

More generally, code review is a great opportunity for incrementally gaining or encouraging alignment across the team.

What the team chooses to align on and how strongly are left up to it, so hopefully they choose to not get bogged down in inconsequential details, but completely skipping the pretty cheap chance for reenforcing all kinds of cohesion would be a big mistake in my opinion.

[alex_lav]

You're making a lot of positive-upsided assertions about code review. My point is there is too much opportunity for negative behavior. It's the same as everything in tech, in life, "It can be good if everyone does their part to keep it good". And yet, most don't.

[spankalee]

"most don't" is a strong claim. In my experience, core review has been undoubtedly good. I would never run or join a company without it.

I'm writing code solo for the moment, and code review is maybe the thing I miss the most.

[alex_lav]

> "most don't" is a strong claim.

I'm happy to be reasonable. I guess my greater feeling is that most devs aren't great at identifying when they should identify restraint. For the same reason that most devs are abysmal interviewers, I think devs forget that code review is ultimately a human endeavor. Give your average dev the smallest amount of power and not enough guardrails and legitimate silliness ensues.

> I'm writing code solo for the moment, and code review is maybe the thing I miss the most.

I feel as though "code review" is taking on too many meanings in this conversation. Code review in the form of a second (or more) qualified dev reading and commenting on code for the greater good? Obvious good. Code review in the form of github PRs at a non-FAANG company? Skip it. Kangaroo court.