Preach!

It all comes down to empathy and perspectives. Think about the fact that you both want to get this thing done. After all, a reviewer is similarly important to the process and you’re both doing your job to getting through the work. In order to work through the review, its everyone’s best interest to work at the scale that a reviewer can fully grok and “OK” your work knowledgeably. A lengthier change will require more eyes, more meetings, more testing (sometimes by hand), and all of the worst things. The difference between a 20 line change and 100 line change, in terms of review, is exponential (no science to back that assertion, but experience).

Coincidentally, both reviewer and author have feelings. Reviews can be made of both specific lines and of large design assertions without being critical of the person. You, the reviewer, needs to think about the fact that you may not have been there or known the pressures that befell this specific change. Maybe the reason they ended up with that solution doesn’t matter at all — it just matters that you assert your opinions with an empathetic tone. Explain your thoughts through reason, not emotion. The same goes for the author to take reviews as a critique of the code, not the author’s abilities or value.

Well written and a topic that touches a nerve with a lot of Engineers. Thanks Kurtis.