Code Reviewing is one of the greatest tools we have as software developers, to help us improve the quality of our code. It can be incredibly beneficial, but it can also be a source of pain and overall, a waste of time instead of a time-saver.
Like with many things in life, knowing why we do something, can be a good way to do that thing at its best and not to abuse it. Let’s begin then to unpack what a code review is not:
- It is not your nice, daily half an hour of shooting at your team mates and pointing fingers at their mistakes. If you do code reviews because you find pleasure in finding other people’s code mistakes or lack of use of best practices, then you shouldn’t be doing code reviews in the first place.
- It is not a place for teaching. If you have best practices that you think your team mates should know and use, then there should be a time, prior to starting your project if at all possible, where such best practices and guidelines are established, accepted and understood.
- It is not where discussions should occur. Never mind long and opinionated ones! This is where comments should be kept short and to the point. No repartee, no attempts to justify/defend yourself.
What, then, is code reviewing for? I have outlined 4 points:
- It’s a way of sharing responsibilities. When we are code reviewing, we are “carrying the weight together”, so to speak. We are quitting the old “I don’t care, it’s not my code” mentality that many of us tend to have, in favour of a “we’re in this together” attitude.
- It is a great way to learn from each other. This might, at first sight, seem to be in contrast with the second point of the previous list, but stay with me here: I have learnt so much more in my career through friendly, non-aggressive opinions and suggestions from my colleagues, than I have from those forceful, unfriendly and aggressive comments from those who thought they knew better than anyone else (or than me, at least). As a matter of fact, not only have I not learnt anything substantial from them, but I have actually hated them (the comments, not the people!). No matter how good you are, people deserve your respect, and even if they have less experience than you, you were once like them.
- It’s where some bugs and blatant errors are found. At the end of the day, this is the real point of doing code reviews. When you do one, focus on finding errors and bugs that whoever wrote the code may have missed, and suggest quick way to fix them. Sometimes you’ll even find the same error occurring more than once. Resist the temptation to write witty comments like “I can’t believe you’re doing this again”, or “stop doing this for heaven’s sake!!!!!!”. Be professional, and if you think there is something that needs to be discussed, do it personally, in a friendly and not humiliating fashion.
- It may be a way of improving the code quality. As outlined before, best practices should have been priorly discussed, but if you find some piece of code that you reasonably think could be made more efficient, suggest it nicely. A more facultative “Maybe use
function2(), it would run faster” is better than a mandatory “replacefunction1()withfunction2()“ kind of thing.
At the end of the day, what needs to be remembered is that your collaborators/colleagues/team-mates are professionals like you, regardless of the individual amount of experience. But, ultimately and more importantly, they are human beings! And human beings work better, produce more and tend to be happier in an environment where they are understood, appreciated and respected. And code reviewing can be an incredibly powerful helper in this, if used wisely.
Question: what are your rules and what has been your experience with code reviewing? Share your thoughts on Facebook or Twitter.
---