Exactly what to say in code reviews

🌈 Abstract

The article discusses 7 techniques for providing respectful and effective feedback during code reviews. It covers strategies such as using "I wonder..." and "I'm curious..." to make suggestions in a more open-ended way, as well as avoiding defensive language like "why" in favor of more empathetic phrasing. The goal is to create a collaborative environment where feedback is welcomed rather than seen as criticism.

🙋 Q&A

[01] Techniques for Providing Feedback in Code Reviews

1. What are the 7 techniques the article discusses for providing feedback in code reviews? The 7 techniques are:

• "I wonder..." - Suggesting ideas while opening them up for discussion
• "I'm curious..." - Calling out potential issues while understanding the author's perspective
• "What do you think about..." - Making direct suggestions while leaving room for the other person's thoughts
• "What would happen if..." - Inquiring about edge cases that may not be handled
• "I noticed... What are your thoughts?" - Pointing out observations and inviting feedback
• Using "what" instead of "why" to avoid defensiveness
• Using empathizing words (e.g. "consider", "might") instead of prescriptive words (e.g. "must", "should")

2. When would you use each of these techniques?

• "I wonder..." - When you want to suggest something lightly and open it up for discussion
• "I'm curious..." - When you want to call out a potential issue with the current approach and understand the author's perspective
• "What do you think about..." - When you want to make a direct suggestion while still leaving room for the other person's thoughts
• "What would happen if..." - When you suspect an edge case is not handled, but you want to allow the other person to provide more insight
• "I noticed... What are your thoughts?" - When you notice something that could be improved, but you want to invite feedback on your suggestion
• Using "what" instead of "why" - Whenever possible, to avoid triggering defensiveness
• Using empathizing words - To make your feedback sound more collaborative and less prescriptive

3. How do the "what" vs "why" and empathizing vs prescriptive word choices impact the tone of the feedback? Using "what" instead of "why" avoids sounding accusatory and makes the feedback more open-ended. Empathizing words like "consider", "might", and "could" make the feedback sound less certain and more collaborative, compared to prescriptive words like "must", "should", and "know" which can come across as more commanding.

[02] Dealing with Disagreement

1. What does the article suggest if the other person disagrees with your feedback? The article suggests that using softer language actually invites disagreement and valid reasons why you might be wrong. If the other person disagrees, they should provide a valid reason. If they don't, you can ask them to explain further. The goal is to create a collaborative environment where disagreement is welcomed rather than resented.

2. How does the approach of using empathetic language impact the likelihood of the other person accepting your suggestions? The article states that in the author's experience, using softer, more empathetic language has increased the chance that their teammates accept their suggestions the first time. Rather than feeling judged, the other person sees the reviewer as an ally working towards a common goal.

3. What additional resources does the article recommend for improving code review skills? The article recommends a book called "Code Review Champion" by Dan Goslen, which covers techniques like "Have you considered..." and "Can you help me understand..." in addition to the ones discussed in the article. The author states that the book is a comprehensive resource for early-career engineers and anyone looking to improve their code review skills.