Nonviolent Code Review

A collection of thoughts on non-violent code review. As the title suggests, this is an attempt to apply the ideas of NVP to code reviews.

Of course, not all reviews can or should be so elaborate as to follow all the suggestions in this document. But as communication gets more complex and contentious review gets, the these patterns may prove helpful.

Four elements of feedback

 * 1) Observation: what do I think is happening here?
 * 2) Concern: what bad things may happen if this is done?
 * 3) Principle: on which principles is this concern based? Which principles does the code violate, and in what way?
 * 4) Request: how can the concern be addressed? How can the desired change be made without violating agreed-upon principles?

Three kinds of conflicts

 * 1) Misunderstandings or lack of information. This can be subtle. Ask carefully to establish a shared understanding. Avoid assumptions.
 * 2) Difference in value or judgment. Work together to formulate a specific trade-off. Then find the appropriate person to make the call on the trade-off. Typically, that person would be a (technical) product owner.
 * 3) Ego bullshit. This includes "not invented here", "we have always done it that way", "I spent a lot of time on this", "I'm not stupid", etc. This happens in all of us. Spot it, forgive yourself and others; smile, shake your head, give your inner child a lollipop, and move on.

Golden rules

 * If something seems silly, ask why it is done that way before saying it's silly. Someone probably failed to see an important aspect - maybe it was you.
 * Make sure answers given during code review make it into documentation.
 * Follow MOS:WTW. In particular, avoid judgmental terminology.
 * No stonewalling: when criticizing, always provide a clear way forward.
 * The person writing code should have autonomy over how the code is written. This autonomy is limited only by agreed-upon principles.
 * Matters of preference can be discussed, but should not block a patch.
 * Back off when frustrated or angry. Take some time to calm down, then start asking questions.
 * Be clear about what you consider a blocker, as opposed to a matter of preference, or a request for clarification.

See also:
 * see also Compassionate Coding by Aniket Kadam.