A lot of this is lessons hard learned from being a reviewer that unintentionally made people feel dejected. Regardless of my intentions, I had to own my impact. For some, my reviews were insightful learning experiences but for others, they were a never ending gauntlet that burned them out. My tone defaults to analytical which comes off as short and critical. I'd also be focused on "my main task" and only mentally "check-in" when replying to an update (particularly when assisting other teams as a subject-matter-expert), losing track of how long the review has been running, how discouraging it is for the person, and how inefficient it is for them.

Goals

Non-goals

Code Author

The primary concern is "how do I make this easier on the reviewer, especially so they focus on the important details?"

Code Reviewer

As a reviewer, you have to balance meeting the needs of the organization (e.g. quality) with the code author (e.g. feeling dejected and checking out).

Improving

Learn from other areas with review cultures, like the game Go, art, etc.

For example, in the game Go, when discussing the game:

Use "Black" and "White" instead of naming the players or using pronouns. This creates an objective discussion which allows both players to learn without their ego getting in the way.

From Sensei's Library: Analyze the Game

Resources