I have recently attended to RedDotRubyConf (in Singapore — June 2017) and I had the chance to listen to one of the best lineups so far. Kudos to (amongst others) Grzegorz Witek for the hard work he put deciding on what talks to accept.

In one of the many presentations, I’ve listened to Vaidehi Joshi speaking about Crafting Better Code Reviews . It particularly interested me because code reviews are usually something quite tricky in the sense that not everyone is really happy to do them.

She approached the code reviews from a perspective of how to make them better, more useful and less boring, therefore more productive.

Raise your hand if you never did a “Terms and conditions” review style. . If you did raise your hand, I either salute you for your commitment level or I blame you for trying to fool yourself believing that you’ve never slacked on a code review.

“While some people take code reviews as simple as that (fixing problems before they arise in production), some other people take it as a review of themselves per extension”.

Back to the outcomes of Vaidehi’s great research, one of them was that you should also positively feedback instead of simply pointing out the “wrong” or less accurate things.

The reasoning behind this idea lies in the fact that everyone is different and while some people take code reviews as simple as that (reviewing code for finding and fixing problems before they arise in production), some other people take it as a review of themselves per extension. Some people take the code review so personally that they extend all the negative comments made as a personal critic rather than just a code review.

The other problem that I can see on the code reviews is that they are mainly done on a written manner. The various forms of written communication, in my opinion, are extremely dangerous in terms of emotions. You either carefully select the words used to express exactly your feelings, or you might end up passing the right contents but with the wrong tone.

The other problem that I see with textual communication is that the perceived message might vary based on the emotional conditions of the receiver. The growth of emojis usage in text is a clear response to this lack of emotions on pure text and it certainly helps but they aren’t always the solution.

Combining these two ideas, and in an attempt to understand better the whole reality of my gut feelings, I’ve started a survey where I try to find any existing correlation between work experience and ability to differ code reviews and personal reviews.

In the meanwhile and until I have enough data to draw any conclusions, keep in mind:

1. Be nice. This does not mean being soft on your code review, but rather, be respectful, give constructive comments and praise when you do see something worthy.

2. If things are not clear, don’t be shy. Ask why. And I mean verbally ask if it’s really needed. Many times a 5 min chat solves problems that would take hours to do it on a chain of comments.

3. Always keep in mind, it’s the code it’s being reviewed not you. Take every comment as an opportunity to learn.