Five different ways to approach pair programming
Pair programming is often advertised as a team feature, it is supposed to be a great way to progress, but how does it actually works?
Obviously this is no piano session and you can’t exactly use four hands on a keyboard at once. Pair programming can be done different ways, each having their own strengths and weaknesses. This article aims at presenting the different ways of pair programming I have experienced so far, along with their advantages.
Dictated mentoring
When one person is more knowledgeable on the work to do and has a more extensive understanding of the language, it can dictate the different steps to the other part of the pair. This is quite useful when onboarding someone new in a part of the codebase, and to teach juniors. The level of details can indeed be adapted, from explaining what functions should be coded to detailing code line by line. And while giving specific instructions, one can also take a guided stroll to different parts of the codebase where the mentor will explain how things go. When onboarding a new member of the team, the session can go as far as committing and creating the pull request during the pair programming session.
The overwatching mentor
In a similar fashion but with a learn by experimenting twist, the mentor can stop dictating what should be done step by step. The junior who is writing code will comment on what he is writing and why. The mentor will answer the junior’s questions and provide advice and solutions should the junior need them. This approach lack the guided-tour part of the previous one, but the lessons learnt are probably memorized more easily but at a slower pace and maybe with a little more stress. It also helps understanding the typical thought process of a newcomer.
Of course, this method and the previous one can be mixed and alternated as needed, you just have to keep in mind that they provide different benefits.
The switching keyboard
This looks similar to one of the two previous methods at first, but the keyboard actually switch hands every 10 minutes, and so do the roles. This can be done as soon as both programmers are confident in the skill of the other to solve the issue (or at least that everybody has understood a previously discussed solution). Each participant fulfilling two roles means that you virtually have four different sets of eyes on the code, which should increase your odds of spotting troublesome things and solving issues, while also preventing growing frustration when you struggle alone with a problem.
The parallelized feature
When you are implementing a feature that can be easily divided (back and front, model and service, two different subclasses…), you can just sit next to a colleague, divide the work and get started on the same branch. A good communication is then the key to know who is doing what, and regular commits and pulls will ensure that the common part is shared as soon as possible. The goal of this method lies in speed rather than sharing knowledge or mentoring someone. It works best when the gap of level between the programmers is not too deep, and when the feature is clear and properly divided.
You should seriously discuss the issue beforehand and then keep in touch about each others’ advancement.
The debug pair
A lot like the previous method but with and exploratory side, debugging can be done in pair. Each person has his development environment set up and running, and will explore different part of the application using their favourite debugging method. This will allow to cover more ground quickly and hopefully get a better understanding of a bug. The implementation of the fix may be done using one of the previous techniques if suitable, if not, choosing the one who will kill the bug is up to you.
Conclusion
As a conclusion, I will simply say that pair programming can be done in various ways, each with different benefits. It should probably not be undertaken just as a trend, but carefully examined as part of solving the current task, and if the benefits of one methods seem adapted, then you can start pair programming a specific task the best possible way.
If you want to experiment these methods with us, we are recruiting
