Ask HN: How do you do code reviews without getting silly over little things?
I've had good experiences with code reviews where someone corrected my logic, saw an easier way to do something I was doing, stopped me from being lazy, etc. I've also had a lot of dumb code reviews where I used a variable name that conflicted with one of ten conflicting standards or I did something in five lines instead of one because it was easier to read.
The problem I see is once code reviews are in place and you have a big enough team you get code review specialists who don't add any value but create an awful lot of work. I've literally seen companies consider any change made in a code review to be a bug fixed so you get folks who pride themselves on flagging things in code review even though there is zero, and often negative, substance to the flag.
How do you get the good parts of a code review without the bad parts?