How to code review

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?

vs

what is the log here for?

Suggest, not command

use foo() here

vs

how about using foo() here?

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.

Feedback loop

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.

Summary

When in doubt: ask questions.

Comments