Are we ready for code review?

We have been talking about the better ways to do code reviews, and there are plenty. There are great tools to make code sign-off by someone other than the code author a required part of the process. It is important to keep code reviews short and casual. Very little code and only a few people should be involved in each event. Reviews should be done often, as much as a couple of times a day, and everybody on the team should participate regularly. There are ways to limit the conversation to the most important topics – logical flow, proper use of language features, good naming, while leaving formatting, test coverage, and many other issues to the automated code checkers.

The most interesting conversation, as it typically happens, took place after the formal presentation. The biggest problem of code reviews, and all other technical reviews, is that we, the developers, tend to take the critique as a personal assault.  People brought up multiple instances when they tried to communicate code feedback to a colleague, and instead their comments were heard as snarky and demeaning. We discussed learning to be nicer, working on improving Emotional Intelligence and social skills, making sure to provide comments on good things as well as bad.

However, this is just one side of the problem. There are at least two parties involved in delivering feedback: a person who endeavors to give the message, and the person who is to get the information. The person who receives feedback must be open and involved into how feedback is provided. In order to learn from and benefit from feedback, we also need better social skills and EQ, as well as trust in the system and the person who is delivering the feedback.