You_As_A_Reviewer

Herein, I want to collect and share my learnings about how a code reviewer should approach code reviews. I’ve sat down with the intention of grouping all the behavioural aspects of us fellow developers when we play the role of the reviewers, as individuals. As it goes with my approach, first I’d like to get some of the so called bad practices out of the way.

Things to watch out for, as a reviewer.

Showing off.

Code review is not the right time or the right place to Showcase your skills and knowledge. It is not to say that you should deliberately miss out on an opportunity to share knowledge or mentor a fellow colleague. It is in-fact one of the best thing to do as long as the intention is to share and mentor.

When you approach review with the intention of making an impression, then it’s an abuse/misuse of a tool/process that would have otherwise led to better quality of code that your team delivers.

Vent.

Code review is not the right time or the right place to vent the latent frustrations you may have with anything in life. This is categorically a cross contamination of a space that was meant for clean collaboration, with irrelevant and potentially toxic elements that, in addition to taking the focus away from the goal of code reviews, could affect the psyche of the author of the pull request. This is not to discount or invalidate your emotions, this is to ensure that your feelings and emotions get the attention that they deserve through the right channels. Bringing them out during code reviews inherently devalues them.

Language.

Usage of unparliamentary language in the code review comments should be discouraged. There is quite a thick block of separation between being casual/friendly and using unparliamentary words in a professional. As friendly as we’d like the space of collaboration to be, we can’t assume how fellow reviewers and the readers of the comments will perceive such comments. Shitty, fucked, crappy and such words may make you feel like you’re a cool and a hip developer but it devalues the importance of the code that’s being reviewed.

Keeping the author waiting.

You as a reviewer owe it the author, the team and yourself to close the review in time. De-prioritising review tasks just because it’s not your main deliverable will lead to a set of inefficient code review practices.

Things to deliberately practice, as a reviewer.

Learning, knowledge sharing, mentoring.

Developing a mindset of being open to learning something new every-time at every new opportunity to interact with a teammate is a virtue. The more appreciation you have for the craft itself, the more this makes sense to you. In my experience the most knowledgeable persons I’ve worked with, are the ones who are open to learning. This attitude in my opinion, forms the basis to the rest of the things I present below.

In the area of being open to learn, also lies the opportunity to share knowledge and to mentor. An opportunity to quote some references to material online that is related to subject matter but isn’t necessary for the approval of the code is one of the many ways in which we can enrich the work environment along with sharing some interesting insights related to change in question. This attitude when imbibed and practised deliberately could be result in greater degree of Job satisfaction, having fun responsibly at work :)

Appreciation.

A code review shouldn’t ever be just about spotting the possible shortcomings of fellow developer’s work. It should also be about spotting the good parts of the code changes that the developer has implemented. This according to me is the highest form of appreciation a developer could receive. We must deliberately practice being generous with encouraging and appreciating comments where they’re due. All the while seeing to it that we’re not faking it. Being honestly appreciative is the key.

Kindness.

Remember that there’s another human being at the end or receiving comments. The constructive criticism that you as a reviewer provide must focus on the work and not on the individual behind the work. Remember to use kind and courteous language to the best of your human abilities. This is easier said than done and hence needs deliberate practice until it becomes our second nature. Assume competence and goodwill on the part of the author and any so called Obvious lapses in the changes are due to lack of right information.

Timeliness.

Leaving a code review request unanswered for longer then a business day should be avoided. In cases where you cannot provide review comments in time, do let the author know about it with estimated time of finishing review from your end. Be understanding if you are contacted personally to remind you about pending review. Other aspect of timeliness is to be aware of how long a certain conversation about a certain topic is going on. The author and the reviewer should know when to end and move on. There are many ways handle such situation but do act in favour of reaching a consensus and merge a good enough version of the code while allowing a scope for making more changes which improves the code overall a separate pull request.