Five Strategies for Removing Violence from Code Reviews
Code Reviews can be tricky, particularly when working on a diverse team. Tensions can flare up, teammates can be offended, and word-fights can break out. this “violent” communication causes the team to slow down and rarely contributes much to the final product.
How does this happen? What happens to a coder when their work is openly criticized?
In the modern coder’s life, nothing is quite as stressful as reading the public comments your colleague has left on your pull request. The words that are typically used in a code review make us feel threatened. They activate our defensive fight, flight, or freeze response. The amygdala (or old/reptilian part of the brain) takes over and focuses all energy on surviving. This is a great feature of our brain when our lives are actually being threatened, but it does not serve us well in a coding environment that requires creativity, problem-solving, and positive energy. That frontal part of our brain that does all that creativity stuff shuts down in these high-stress situations.
So how can we write non-violent code review feedback in a way that does not trigger the writer’s defensive fight, flight, or freeze response? Here are four strategies for removing the ‘violence’ from the code review language.
Talk about the code, not the coder. The problems begin with the use of personal pronouns. In particular “you.” Make your comments about the code - “it” - not the one who writes the code - “you.” This removes the personal threat in your comments.
Don’t ask “Why?” - “Why?” in a code review is an aggressive question. In fact, it’s not really a question at all. You may write: “Why did you write it this way?” but what you are really saying is, “You did this wrong.” Avoid the question of why. Instead, be genuinely curious with your questions. Don’t ask questions that aren’t really questions.
Don’t use the word “should.” “Should” is another word that immediately puts the coder back on their heels. In code, there is no absolute way that something “should” be written. You may have an opinion on how the code “should” have been written. The key is to own that opinion as your own, not appeal to some higher sense of “should”. It can be as simple as saying “I think” or “In my opinion”.
Replay your reactions. Don’t issue judgments, but instead talk about your own experience reading the code. No line of code is objectively good or bad. You as the reader might see something that works for you or doesn’t. Own that. “I was confused when I read this.”
Share your experience. “What’s worked well for me is …” is a fantastic, non-violent way to share your opinion in a code review. Talk about your own experience and how it might relate to the current bit of code you are reviewing.
Let me be clear. Non-violent code reviews are not about weakening or softening the feedback. We aren’t holding back or accepting a lower quality bar in our code. It’s about preventing the coder’s defensive, survival system from kicking in. This keeps everyone working from their most creative and productive selves and ultimately leads to better code.
For more on Non-Violent Communication, Read Marshall Rosenberg, Ph.D’s book by that name or check out the Center for Nonviolent Communication (https://www.cnvc.org/)
