Blog

Though we are exceedingly busy as a company at the moment I have managed to find an hour every week for the last month to finally start catching up with reviewing Ben's (and now Josh's) code.

When it comes to Ben this is a task that has been pushed back off the schedule for a while and I felt could not be put off any longer. Indeed, in an ideal world without schedules and resource restrictions code reviewing would be done thoroughly and often but sadly in a company with only 2 senior developers and projects clogging up the pipeline it is often the first thing off the schedule... that and writing blog posts which is why you will rarely see anything written by me or Andrew. Unlucky for you dear reader I am currently sitting on a plane with no internet connection and no IDE so you will have to read my musings on the matter.

Looking back at the previous code review for Ben and trying to pick things back up with the next chronological project (an internal tool we were writing to try and improve our estimate making based on past accuracy and current confidence) I was glad to see that though there were plenty of mistakes and a few anti patterns, he had not made many of the same mistakes and I was excited to see the markup was all valid! (only those who know me well will understand just how important this is to me)

Though I was visibly happy that he had improved and I made it clear that I was only too aware that the code was months old (and therefore trash in the eyes of the writer regardless of how experienced they are), I was expecting a bit of resentment, annoyance at my insistence in doing them or some pushback. But I was surprised to find that while Josh seemed quite worried about the prospect Ben seemed relatively pleased. In fact, while I was explaining to Josh how the process works he joined in talking about just how useful it can be.

When it came to his review he said there was nothing he disagreed with and assured me that many of the lessons I had highlighted were ones that he has since learnt. He also believed that as I continue catching up I would find him continuing to improve. I am halfway through looking at his code for the next project and it does look like lessons were learnt but I very much suspect that some issues would have slipped into the next project and the next as he learns the hard way something one of us could have pointed out earlier if we had kept up to date with the process. I am hoping the current schedule is one I can keep in future and I can save him some of this pain.

Josh seemed to take it a little more personally but it is his first experience and it is a process I don't think you really get in many other professions. If I was running a kitchen and a new chef made me a good tasting dish I would not then proceed to look at how well they sliced their ingredients, but the jury is no longer out for doing this kind of thing in our profession. As Karl Wiegers said in 2002 and Jeff Atwood echoed 11 years ago in 2006, peer reviews are 'one of the most powerful software quality tools available' and 'are the single biggest thing you can do to improve your code'.

I have personally had what I consider less productive code reviews in the past. Two that come to mind is one where the reviewer disliked a modern language feature simply because they couldn't read it easily and one that have ended in a heated battle because I have a different code style. Both these criticisms and debates are worthy of a separate post, but even in those instances I feel the act of defending my actions and design decisions turned me into a better developer than if no one had mentioned it at all.

Finding enough time for Andrew and I to review each other’s code seems a little farfetched at the moment but as Ben learns enough to start picking up some of the more complicated work I am hoping I too can get in on the code review action. Maybe sometime soon I will be filled with the same anxiety one reserves for code reviews again.