I do sometimes feel bad when I do code reviews. But only when I find out after code was merged, that I missed something when I approved the changes.<p>The process is frustrating on the other side, when reviews come back 2-4 times. Only because "I should be better than this!" If there's more than 2 rounds of comments on a pull/merge/patch, I'm upset that I didn't catch the small things the first time around, and that (even though only on a very small level, I'm wasting the time of the reviewer). Otherwise I'm happy to explain why my way is better, or when it's not. I learn something that makes me a better programmer, and the codebase gets better for it.<p>If the other devs on your team don't like code review, perhaps they need an assignment that doesn't require code review? Because if I'm reviewing your code and that bothers you... I'd be hard pressed to trust ANY of the code you write.<p>Also: If you find you're wasting a lot of time for style, mandate a code formatter. Then if you have CI, create a separate job for code style, you can check that first before you even start to review code, it'll save everyone time in the long run. Then, you'll only have to comment on logic. Style is VERY important when doing code review, every 1/1000th of a second I spend trying to parse the style conflicts takes away from the ability to notice an error in the code. If you're concerned about security or performance at all, you don't need additional overhead of having to read code through style errors.