Finally, we are in an era which acknowledges some of our anti-heros like Deadpool and Batman along with our all powerful, infallible Superman. Its time, that we also acknowledge the dark knight behind the optimized code delivered by any team: the code reviewer. Code review is one such Dev function that has always taken the backseat while coding takes the centre stage.
Initially, when I was fresh out of college, I used to find the concept of code review a hinderance to productivity. To be honest, I used to love my code and everytime somebody pointed out the chinks in my code, I would do whatever I could to avoid doing that change.
Well, when mentors can’t teach you something, Karma finds its own peculiar ways to make you realize your faults. I still remember pulling off an all nighter at office to hot fix an out of memory error, just because I had ignored some of the review comments to prevent heap space overflow. It was with time and experience, that I realized the fatality of taking the code reviews personally.
Now that we have established, the importance of a good review, I want to share a couple of things that I have found lacking in the coding teams simce I have started to do frequent code reviews.
- First, is the tendency of a reviewer to be light on certain code reviews due to their own work pressures or constrained timelines. I have always advised my team to play devil’s advocate when it comes to code reviews. This practice has not only helped us to optimize our code by laying a strict emphasis on TDD and minimal run time complexity but also minimized the known nemesis like null pointer exceptions.
- Second, is the tendency of a developer to dole over their own code and love each and every line of it. This kind of attachement to ones code is the beginning of what could be a really bad habit for a developer’s career. While, its important to love your work and write code which reads like poetry and achieves its said objectives, the thing which is equally important is to develop a sense of detachment towards ones own code when its ready for review. Its extremely pertinent to base the counterpoints to the suggested changes on well read logic rather than baseless speculations.
While these two are the standout observations in our code reviews, another thing which is really important is, to think ahead while doing the review. Reviewers need to make sure that the code does not only meet the said objectives but does so in a way which is optimised and poses minimal collateral damage.
I hope you will ponder over these things when you review your next code or submit your next pull request for review.
And pardon me if I was overtly philosophical !!