Human Centric Code Reviews

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 include 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:

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

If you are discussing a change and are communicating through messaging and comments, it’s important to be thoughtful on 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 minimic 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 says 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 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 Kaheman, 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.

Discuss

About CodeStream

CodeStream helps development teams discuss, review and understand code. CodeStream links comments and issues directly to the code blocks they refer to, making them instantly available to everyone on the team.