Some like them. Some hate them. But code reviews are a good thing. Some may think they are demigods who fart out perfect code, and therefore think them irrelevant. Others think they are absolutely terrible and don’t want to be openly found out, and are therefore scared of them. But they are good.
For one, they provide knowledge transfer. Firstly, knowledge of what someone did. It gives another developer in a team an understanding of how a feature or requirement was implemented, incase the original developer gets stuck in an eternal line at the Department of Home Affairs (so much better than being hit by a bus). Secondly, new methods and interesting techniques can be learned by seeing how someone does it. In addition to this, bad methods and techniques can be corrected, helping developers improve. Reviews are good both for the developer, and the quality of the code base. But how the reviews are done is a topic of contention.
There is a caricatured camp, who normally run around calling themselves archaic terms appropriated from an era in European history (‘apprentice’, ‘journeyman’ and ‘craftsman’). They ordinarily advocate for this idea of ‘pairing’, where there are two developers, two keyboards and one screen plugged into one computer. These developers continually switch between who is writing the code, and who is an active, engaged observer.
Then there is another caricatured group. They are normally known to their masters as ‘resources’. They normally work individually, committing their changes to a source repository branch. When they are done (hopefully after a short period of time), they submit a pull-request for the code they have written to be reviewed by someone. This is either by a peer, or the Lord Baal Architect in the team, who suggests changes where necessary, and merges the changes in when happy.
These are obviously oversimplified, biased versions of each, but the crux each method of reviewing has pros and cons.
Pull request reviews are great for distributed teams, where one can’t sit side by side and online communication is awkward. It is also great for individual problem solving, where talking can become distracting to the thought process. Talking to someone all day is tiring. Especially if they aren’t pleasant. And don’t wash their hands. And make “that’s what she said” jokes all day. And it may be more clear having someone see the end of your thought process, instead of the unstructured safari in your mind.
Yet, with these advantages, I have still found pairing to be beneficial for both the individual software developer, and a small co-located software team for the following reasons:
- Quicker feedback
If I start working on something at 8am in the morning, work hard through the day, and feel I’m ready to submit my pull-request at 3pm, I have to wait until someone has time to take a look at it. In that waiting, I start something else. Then, on the morrow, at 9:34am, Tongai, the senior developer on the team has time to take a look at it. She calls me to her desk, and I start walking her through the code I wrote. She asks me why I chose that particular technique within the commit I made at 11:16am on the eve. I think, but the thoughts of the new thing I’m working on are consuming my mind. Eventually, I vaguely remember it was based on something I saw on StackOverflow. But can’t really remember. It would’ve been so great if she asked me at 11:14 yesterday.
- Deeper learning
Software development learning happens more in the process than in the corrections of the outcome. If new insights and course corrections can be made during one’s thinking, allowing one to apply and internalise that knowledge immediately, learning can be deeper. Also, when the reviewer is going through the code, they don’t have time to think as deeply as you thought about it, and properly understand the context and reasoning compared to if they were part of the development process at the time.
- Awkward scrutiny
Sometimes, while your review is being done, there is this awkward feeling of being a kid at school having your test marked in front of you by Mr. Qengwa. The same thing can happen while pairing, but there is this difference when someone is co-labouring with you, compared to when someone is reviewing post the fact. With one, co-building is the goal. With the other, despite it being constructive, the mood leans towards scrutiny.
Now, all this doesn’t take away from the fact that pairing is kinda hard. And the benefit is highly correlated to the personalities within the pair. Yet, despite this, I’ve still found that the technical learning one gets from pairing is deeper, and the emotional maturity and ‘soft-skills’ (which are really hard skills) that are developed to be more. There are numerous posts on the cyber about pairing well, and mistakes to avoid making. I would recommend DuckDuckGo-ing them.
Patrick Kayongo 