Code reviews can be a great opportunity for software development teams to learn, mentor, and collaborate with one another. However, they can quickly become cumbersome if colleagues are not thoughtful with one another in how they communicate feedback during the process. All too often teams focus on providing the best technical guidance to developers while ignoring the psychology on how to deliver feedback. Ideally, the code review process touches upon elements of the psychology of the team as well as the technical workflows. Microsoft, for example, has implemented a number of strategies for providing feedback that includes a mix of both of these considerations. A code review model that fails to utilize feedback mechanisms on how team members actually learn and absorb information can risk jeopardizing team chemistry in the middle of a sprint.
Here are some best practices we recommend to increase the effectiveness of providing feedback during code reviews:
1. Conduct code reviews more frequently: provide rewards for completing more tasks
According to a study at Cornell, “people who received immediate, frequent rewards for completing small tasks reported more interest and more enjoyment in their work, compared with people who received delayed rewards only given out at the end of a long project.”
Institute a regular practice of developers submitting smaller, bite-sized code reviews frequently rather than waiting at the end of a process for feedback. If managers regularly reward developers with feedback during each step of the way, even during a work in progress, then developers are more likely to stay motivated during the course of a project.
2. Provide feedback with the same expressions and terms a colleague used when they submitted their initial code review
Adopting the same language, pitch, and tone as a counterpart establishes trust between two parties. Mirroring the way another person communicates is likely to help with problem-solving. In a study, published in 2008 in the Journal of Experimental Social Psychology, 62 students were assigned to negotiate with other students. Those who mirrored others’ posture and speech reached a settlement 67% of the time, while those who didn’t reach a settlement 12.5% of the time.
If you are discussing a change and are communicating through messaging and comments, it’s important to be thoughtful about how your language comes off. Reviewers should strive to maintain a sense of psychological safety to discuss a problem. Both the reviewer and developer should try to use common terms both parties are familiar with.
Of course, these changes should be subtle and a reviewer should not blatantly mimic the expressions of the developer, as that has proven to backfire.
3. Be considerate in how you frame comments to a colleague
A doctor walks up to two recently diagnosed patients with the same critical illness but presents the information differently. The doctor says to one, you have a “95% chance of living”, while saying to another, “you have a 5% chance of mortality.”
How you document feedback and message important information to the developer matters. To improve the cohesion of a team, managers should be thoughtful in their feedback and not assume that there is one way to present a point of view to the developer. Reviewers should be cognizant of the language they are using and document how particular feedback impacted the quality of the review. Reviewers should then have a source of data to understand the best method of delivery.
4. The end of a reviewer’s feedback will have the strongest impact
What may seem like conventional wisdom rarely gets executed in practice. Citing research from Stanford University and the University of Michigan, Daniel Pink explains that people often rate something higher if they know it’s the end. They rate their day better if they know it’s the last day of class, or rate a snack better than prior snacks if it’s the last one. If you want feedback to stick, deliver the most important information at the end. The last bit of information will be the most impactful to the developer.
As a reviewer, if you have a constructive commentary for a developer, don’t water down the significance of the change towards the end of a thread. Remember that the last piece of information delivered will create the strongest impact. If you are batch processing your code reviews by reading through multiple proposed file changes during one block of time, make sure to save the most important change for the very end.
And if you want to vocalize your appreciation for a job well done, the compliment will be strongest if it’s delivered at the end.
5. Frequently check in on how a colleague is approaching a problem — switching costs increase the longer you wait
Asking someone to change methods is hard. Daniel Kahneman, author of Thinking, Fast and Slow writes, explains that individuals value the psychological safety of the status quo and what they currently own, more than the potential upside of switching behaviors. It’s the reason people tend to hold onto shares in a losing company longer than they ought to, and are hesitant to switch passwords even when prompted by a security expert.
Reviewers should keep this psychological tendency in mind when providing feedback to developers. Asking a colleague to make a radical departure from the methods they traditionally use to solve a problem can lead to a psychological backlash creating internal conflict. Even if your preferred method as a reviewer is truly better, it will be much harder to convince a developer to switch at the end of a process than at the beginning.
Asking a developer to approach a problem differently at the beginning of a process can lessen the psychological burden of switching gears. This is why it’s important to check in even during a work in progress or when a function is mapped out, before the approach is decided.
Managers can also attempt to work within the context of how a developer approaches a problem rather than presenting an alternative perspective as a radical departure from the status quo.
Top comments (0)