As Github gets more and more traction (yes! I’m writing this blogpost on Github) some things I’ve learned as an engineer is that not everything is a given.
For example, reviewing a pull request (or code in general). I’ve been lucky to have a manager who taught me the importance of a reviewer. It is not somebody who just looks at the code, gives a thumbs up and moves on. In his words:
Reviewer takes on more responsibility that the person who submitted the code.
This stresses the importance of good code review for good code quality.
This gets easily explained when thinking about a new employee. There are some questions that a new employee, regardless of their level and experience, will not be able to answer. Examples of such are numerous:
This means nobody should be able to review code the moment they join a company. It takes time to build those skills and different people will learn at different paces. The major advantage a more experienced engineer has is his ability to know what he does not know, and learn that quicker.
Engineers with more experience can help more junior engineers by reviewing their code, that is definitely true. What they should be looking at are higher level questions:
Those questions are well answered by a person with more years of experience.
With that in mind, I’ve created myself a todo list of things to review as I review somebody’s code. I have linked this at the bottom of this post.
That list is not exhaustive and I will try to add on to it as necessary.
That list is also to be taken into consideration based on what you are reviewing. Different level of efforts may be required for different pull request. Examples:
All do not need the same level of attention, but having this list handy allows me to evaluate better code I review and understand my limitations as a reviewer.
I hope after reading this you can appreciate the skill of reviewing as much as I do.