I recently got to see a terrific talk about Better Code Review by Doc Ritezel at the March SF Ruby Meetup. His slides are posted here and are worth a look. Meetup talks can be a mixed bag, but with detailed examples and useful takeaways, I found the talk itself to be that rare mixture of entertaining and thought-provoking.
Doc’s talk follows in the wake of another huge discussion about hostile workplaces, this time at Github. His presentation focused on what a positive workplace looks like and what’s missing from most workplaces in terms of code review. He first illustrated the difference between authoring and reviewing code, then covered what can go wrong on each side of the table through a few example scenarios. These scenarios were, sadly, recognizable by more than a handful of audience members. Finally, he made a few suggestions about how to modify feedback to be more positive.
If you’ve ever participated in code review, either through static comments on Github or real-time pair programming interactions, you know how easy it is to spoil someone’s day by saying the wrong thing. If you’re the author, to use Doc’s parlance, you could be working with an otherwise-great reviewer whose comments suck all the pleasure out of working with them. Likewise, it’s important as an author to know how to be open to feedback. Building software is a highly collaborative process, and understanding how giving feedback can go wrong is important.
I found myself noticing Satir Categories in some of the slides that Doc presented. One of my recent reads, “More on the Gentle Art of Verbal Self-Defense,” by Suzette Haden Elgin, talks about personality categories developed by Virginia Satir, widely known as the originator of family therapy. I definitely noticed my own personality in the group. There are five categories, and you might recognize yourself in one of them, too:
The Blamer places permanent responsibility on anyone else’s shoulders. Although the Blamer could be identified by someone who loves shouting and pointing fingers, in reality the Blamer can speak with a soft voice. Professor Snape, for instance, was pretty good at cutting people down with his voice at a minimal volume.
A good way to identify the Blamer is the use of absolute language: “always,” “never,” “only,” “everybody,” “not even once” and so forth. For example, “Never use strings as hash keys,” “Only smart people use vim” or “Always use git add -p.”
It’s worth thinking through this a step further. Imagine phrases that don’t necessarily use these keywords but imply an absolute rule like: “When you don’t use git rebase, a kitten dies.” Notice that there’s an implied “Always,” like “always use git rebase.” Or maybe “these tests are so redundant,” which carries an implication that “every test should be unique.”
The Blamer’s actions universally carry a single subtext: I disagree with your code, so you should feel ashamed.
The harm that results from placing shame on another teammate, someone who is presumably making an effort to work with you on building something complex can have far-reaching consequences at the individual and the team level. These issues are beyond the scope of this post, but for now, let’s just say placing shame is something to be avoided if you want to foster collaboration.
The Placater feels quiet anxiety and fear while trying to please everyone. Playing the victim role comes naturally to the Placater, as does using appeasement to defer any decision-making responsibility. You won’t identify the Placater by tears or yelling; they’re most likely too tightly wound.
Key phrases sound like “Let’s do things your way” and “I don’t know enough about this.” What’s sad here is that the Placater really does know what they want, but doesn’t feel comfortable putting themselves in a position where they might be wrong later. After all, being wrong would open the Placater up to persecution, which they fear above all else.
The Placater’s actions have their own subtext: I wish I wasn’t here.
Okay, now imagine that the Blamer and the Placater have to do a code review. The Blamer wants to shame the Placater for disagreeable code, and the Placater takes the abuse while trying to make the Blamer like them personally. This is a dangerous dynamic to have in place because it will re-enforce the blamer’s pointy finger and make the Placater feel even more victimized than they already do. If this is happening on your team, it’s time to get some help for yourself or for your team.
The Computer, in addition to being named the same as the thing in front of you, is another Satir Category. People in Computer mode hide as much emotion as possible. Science fiction loves this part of the strong, silent masculine image such as the character Dr. Spock from Star Trek.
In hiding behind a facade of detachment, the Computer is able to avoid projecting emotions, and thus avoids placing blame on the other person. Any blame is therefore directed at the code, or something abstract. This category is marked by a lack of referenecs to “I” or “me,” or really to any person at all.
Although Doc mentions using “I” and avoiding “you” as positive takeaways in his talk, this is a half-measure compared to the total detachment of the Computer. While it has obvious utility for reviewers who are purposefully trying to avoid shaming an author, becoming the Computer can also be useful for authors dealing with the Blamer.
The Distracter cycles through Blamer, Placater and Computer giving an impression of disorganization, panic, silliness or all three. Although this mode is trickier to pin down, think about it this way:
Reviewer [Placater]: “I’m not sure, but you might want to parse out the xml here. There are a few libraries to choose from, feel free to choose any of them.” Author: “Ok, I’ll use Beautiful Soup” Reviewer [Blamer]: “No, don’t ever use Beautiful Soup.” Author: “Ok, I won’t use that one. Is there one you prefer?” Reviewer [Computer]: “There are several libraries preferred within the Python community.”
In this case, the reviewer gives the author a choice, but doesn’t support the choice being made by the author. Besides being very confusing to the author, it also puts them in a no-win situation because it doesn’t matter which action the author takes. Anything they do appears to be wrong in the eyes of the reviewer.
The Leveler matches up what they are thinking and feeling with their words and body language. This is also defined as congruence which I wrote about here. This is someone taking in the context of the situation and being straight-up about what they are saying without resorting to blamer, computer or placater mode.
The advantage of leveling is that you know you are getting an honest response upon which you can rely. The downside is that it might be very harsh or more intense than someone is ready to hear which can throw your audience off guard.
In a code review situation, this is the mode I personally appreciate even if the feedback I am getting is not puppies and kittens. Even if the reviewer is not totally happy with my work, if they can manage to avoid the other modes mentioned, it’s easier to get on with the business of correcting what needs to be fixed or to engage in more of a discussion.
What do I do with these?
- If you feel like you are in hot water in a code review, go to computer mode. In fact, think of this as “safe mode” for your conversations. It will be harder to work through choices because you are not expressing much of an opinion, but you won’t be taking as many risks. This buys you time to figure out what’s going on or to get in touch for a face to face conversation. However, if you are speaking in Computer mode most or all of the time, it might be a sign that you are shying away from voicing an actual opinion
- Unless you’re pretty sure that the other person is in leveling mode, don’t match Satir modes. For example, two blamers will end up in violent disagreement that will be challenging to repair. Two placaters will find it challenging to come to a decision. Two computers, well… there’s a reason why it was Captain Kirk and Spock. If Star Trek had been Spock and Spock, the Enterprise would never have undertaken a mission as risky as exploring unknown galaxies.
- Avoid using Distractor mode as much as possible unless you deliberately want to look crazy in your code review.
Where do I even start?… It can be really hard to sustain an emotionally safe work environment. Since making software is highly collaborative, the challenge is increased even further. I am hopeful that the days of choosing CS as a major because you won’t have to work with people or talk to anyone are over, but even then, we’re still left with the fact that we are human. In fact, many of us who work in tech come from a background of being taunted at school or picked on by parents to the extent that we were driven inward, towards the machine, towards the code and away from the responsibility of external relationships with real people.
- One quick win is to practice avoiding words that signal blamer mode (always, never, only, everybody, anybody, ever, not even, once) If you know of things you’ve said in a code review that are in blamer mode, can you think of a way to re-phrase them?
- Watch this talk by Jenn Turner about Non-violent communication from Cascadia.js. She brought the house down and her talk was recorded.
- Read more about Satir Modes in More on the Gentle Art of Verbal Self-Defense or start at the source with Virginia Satir’s groundbreaking classic, New Peoplemaking.
- Read about non-violent communication in the book, Non-violent Communication: A Language of Life by Marshall B. Rosenberg and Arun Gandhi
Forgive yourself for mistakes you’ve made and take a deep breath! You get to try again tomorrow.
A big thanks to Doc for helping me put together this post and to Sarah Mei for organizing the SF Ruby Meetups.
