I feel like I've probably seen both sides of all the anti-patterns listed and a few more to boot. A lot of these have some natural root causes. These apply pre

I feel like I've probably seen both sides of all the anti-patterns listed and a few more to boot. A lot of these have some natural root causes. These apply pretty generally to both reviewer and reviewee. - not enough context (why is this change needed, why is the existing code this way) - not enough shared direction (we should do this thing, we've already decided we're not doing this thing) - misaligned expectations of time (review this 1000 line PR for me, I have a fulltime job) - hidden background (why can't we just... / we can't implement that because of this historical precedent) - different personality types / disorders (ASD and other things can mean nitpicks / technical issues are just as "important" as larger issues) - tooling problems (no way to defer submitting just the big things and hold back on the nits) - the code is a proxy for things which are part of the identity of the writer (tabs vs spaces) === The main things that I've seen that seem to help avoid these things are: 0. when possible establish some sort of rapport above and beyond just the review 1. assume positive intent. assume nothing else 2. communicate expectations / constraints 3. communicate appropriate background. 4. don't treat all communication the same, different reviewers sometimes need different approaches. 5. remember that the review is of the code, not the person (this applies to both parties)