How to code reviewMon, Jan 23, 2017
Code review is one of most important tools when it comes to social software development. But there’s an aspect that may ruin the whole experience as code-review becomes point of inter-personal tensions due to various reasons.
By carefully constructing the language you can make a difference for everyone involved.
Here are my notes from personal experience.
As a reviewer
Address the code, not the author:
why are you logging here?
what is the log here for?
Suggest, not command
how about using
Ask questions for everything else
Yes, not sure how to phrase it - ask questions…
As an author
Do not take things personally
Just don’t: it’s not about you, it’s about the code. Easier said than done, but still, do not take things personally: it will improve everyone’s well-being. There’ll be people targeting you personally, in that case: reread the paragraph.
Code review is a necessary feedback: look at any critique as just a feedback.
Ask questions, even the stupid ones
Be the one who ask questions. Clarify things. Avoiding asking question is like a snowball - accumulates and grows into a bigger problem.
Collective reviews for big changes
Sometimes big changes are unavoidable and they are hard to review. People may avoid reviewing the code. In order to get a review through - get everyone together and give a quick presentation or walk though. This will facilitate understanding and bring questions if any. In the end, the goal is to get enough +1.
When in doubt: ask questions.