Coding buddy - Interesting approach to Code Review

How often do you ask your peers to review your code? If not very often then here is an idea for you - find a coding buddy! The buddy system can be implemented in 2 simple steps. But firstly, here is the idea behind the buddy system:

Individuals can do great things, but two highly motivated peers can accomplish even more when they work together. Surely there's at least one programmer you work with who you admire or at least respect enough to adopt the buddy system with.

So step 1 is to find a person meeting the above criteria, he will be a second "half of an awesome part-time coding dynamic duo". It has been proven, that this approach really works - there are lots of well-known dynamic duos like:

• Batman and Robin
• Tango and Cash
• Mario and Luigi
• Starsky and Hutch
• Crockett and Tubbs
• Bert and Ernie
• Cheap and Dale
• Laurel and Hardy

Your duo can join this small hall of fame! ;)

Now it's time to move to step 2 - peer review. Let me start with clarifying what kind of peer review I'm thinking about. Peer review can have multiple variations. For sure, with you coding buddy you don't want to do very formal, systematic and rigorous reviews (inspection) you should be much more flexible and more into quick and informal meetings (peer deskcheck).


I think informal nature of peer deskcheck is the factor that makes is so effective. You can comfortably chat with your buddy and explain to him what is the business objective for given piece of code and what was your approach to the problem. It's a great way to make sure that your idea makes sense and you are on the right course.

Those are only direct benefits, indirect benefits include:

• improved team work - reviews help people to "accustom" to helping each other
• increased familiarity of code base - sharing knowledge is always important, reviews give developers a chance to teach others about their piece of code
• prevent individuals from going dark
• increased quality - "reviews motivate us to practice superior craftsmanship because we know our co-workers will closely examine our work. In this indirect way, peer reviews lead to higher quality."
  

And that would be it, try to implement those two relatively simple steps and check on your own if it improves your code, check if other people understand your design and learn from it.

What are the next steps? (assuming that it buddy system works)

• find more coding buddies as it means more ideas, more views which afterwards should lead to even better code and even better knowledge sharing
• learn about different types of peer reviews, other types can be also useful. (chapter 3 of Peer Reviews in Software: A Practical Guide)
  
• try to change your company's software engineering culture to include peer reviews as a part of the process which you follow, every one can benefit from it (chapter 2 of Peer Reviews in Software: A Practical Guide)

Finally, I couldn't stop myself from posting this cartoon:


Last words ...

• This post was inspired by Jeff Atwood's post "Who's your coding buddy". I know Jeff that you don't read such a obscure blogs like this one but thank you for your post!
• Quotations and images used in this post are from Jeff Atwood's post and from Karl Wiegers' Peer Reviews in Software: A Practical Guide