“You’re gonna have to serve somebody...” ~ Bob Dylan

Code review comments present a challenge. How do we respond to them?

When choosing appropriate behavior, it can be helpful to use an analogy that fits the relationship. In an employee-employer relationship, a butler is a good analogy, because a butler is what we will call a pure employee. What does that mean?

A good butler is a good butler because he knows how to serve, and that is what employers pay us to do. Of course, employees often augment the ability to serve with specific skills. For instance, software developers are highly skillful at writing software, understanding client needs, providing rapid business value, and reducing project risks. If a software developer really knows how to do all those things and yet does not know how to serve, that developer will provide little value.

So, how would a butler respond to code review comments? The basic axiom is that a butler’s role is to take work not to make work for the employer.

Scenario: a master asks her butler to set the table for a large dinner. Once complete the master comes in to review the setup (this is akin to a code review that the employer does.) How should the butler respond to comments and questions from her master?

• Master: There are only 20 settings and 22 guest are coming.
• Butler: Would you like me to add two more settings, sir?

That’s a good response. A dubious response would be, “But you told me to set 20 settings.” This would not be helpful.

• Master: There is no salt and pepper on the table.
• Butler: The guests are coming for desert sir. Salt and pepper anyways?

That’s a good response. A dubious response would be, “There's not supposed to be salt and pepper on the table.” That would be too abrupt.

• Master: These crystal glasses are inappropriate, use the pewter set instead.
• Butler: Misses Bigsby, who is very influential in society, is coming and has a preference for crystal. Pewter anyway, sir?
• Master: Yes. Let's use pewter.
• Butler: Yes sir.

Good. It is appropriate for the butler to provide information that the master may not have considered. Miss Bigsby likes pewter. Her preferences may be material to the decision. For the second response, it’s appropriate for the butler to defer, even if she disagrees with the master. The master already knows all the relevant information and it’s time to let go (no matter how much we might worry about Miss Bigsby’s opinion.)

In each case the butler is providing useful information and expressing willingness to defer. He is being  neither defensive nor adamant. Providing information is different than being defensive. Once the master knows all the relevant information providing the information again would be arguing, and that’s not what we’re paid to do (unless that’s part of the job description.)

A software developer who is responding to code review comments, can take a similar approach. Here it is in graphical form:

                                           Just Right
                                                  |                                              
Too Deferential  ------   Giving Information  -------  Too Defensive/Adamant

When responding to code review comments, there will be tension between being too deferential and being someone who gives information. Generally speaking, a good butler will defer to the master. It is helpful though to provide useful information, to help the client to make appropriate decisions. In the context of a code review, this might be called the code defense. We can provide information about why we did something. The art is in providing useful information and then letting go. The best consultants know what information to give and how to give it without being adamant.

Another tension that will occur when responding to code review comments is between being defensive and giving information. Giving an explanation requires a Socratic disinterest in providing useful information. Being defensive, on the other hand, involves protecting both our ego and our sense of control. A software developer understands that he is not the boss and is willing to let go of control. A trusted consultant is not caught up in defending herself. Neither will be useful to a client.

Just as a butler is paid to think and to provide advice, so a software developer is paid to think in order to provide rapid value, risk reduction, and a product that meets the client’s needs. To provide value, a butler must apply his thinking to the problem domain that that master has assigned. Within the context of the code review, we are paid to think about our code. We provide information about the code we wrote and then, having provided that information, once again defer to the employer or the team for the final decision. A code butler is never adamant.

Of course the butler to master relationship is different than the butler to butler relationship. How do we respond when receiving a code review from a colleague? Generally speaking, the guidelines for receiving a review from a master apply to receiving one from a fellow butler too.