Pair programming is one of the agile software development practices described by Kent Beck in his book Extreme Programming.
What is Pair Programming?
Of course, pair programming is not just the writing of codes between two people, as also strategies are planned and solutions are designed and executed from different angles. Because even with the same technical background, different developers often find different approaches and solutions to the same problem.
Bringing the pair together
The entry of a developer into a project, whether at the beginning or in more advanced stages, is a critical time both for the new members and for the project itself. The onboarding can be done on several levels, but I strongly believe that the most beneficial solution starts with the formation of a developer-pair.
The organization of a pair by an experienced developer facilitates the necessary knowledge transfer to the new pair member. He is the one who has the best overview of the current status of the project, has the necessary expertise and can also help to remove technical hurdles faster: Did the new member configure the IDE correctly? What about the project settings? Does the pair member have all authorizations for access to third-party systems?
From the moment the new developer is ready to start programming, both developers can select the next task to be done and exchange possible solutions in short, uncomplicated meetings. In this way the novice developer can remove any doubts he may have, and in addition he can explain to his partner how he understood the task and receive direct feedback.
If a problem occurs, it is advantageous for both parties to have a discussion about different approaches or strategies to achieve the solution. This matter is influenced by both the professional and creative background of both sides, and in order to increase the value of these discussions it is necessary to ensure an environment free of criticism and prejudice, thus promoting communication between both pair members.
Facing the HelloWorld together
There are lots of different methods of working with the code, but I personally prefer to separate the roles into driver and navigator.
- The driver is the one with the mouse and keyboard who writes the code and comments on what he and the navigator are doing. He will be responsible for solving small problems without concentrating on the overall problem.
- The navigator is responsible for checking the live code, thinking through all possible effects of the driver’s actions on the overall solution and writing them down for later discussion. But the navigator must not remain passive: If he knows an abbreviation for the driver’s direction, he must communicate this.
If the pair consists of an experienced and a less experienced developer, it is recommended that the less experienced takes the role of the driver. In this way, he can show that he has understood the context of the project and the solution agreed between the two, and finally find his way around the project with ease while familiarizing himself with the code.
The experienced developer will be able to review the code livewithout having to work his way through code discussion tools. In this way a homogeneous programming style can be achieved very soon.
In the long run, this leads to a point where each line of code has inevitably been reviewed by multiple developers, ensuring clean, efficient, and polished code.
Tips for effective pair programming
Time management is a decisive factor in pair programming. Starting with planning the day and determining the joint working time. This schedule cannot and should not take up the whole day as it is quite a demanding technique on an intellectual level, so an average of 4 to 6 hours is more than enough to meet, set up a schedule, rest and take care of other chores.
It is highly recommended to change roles between the pair as well, so that the navigator feels active in the project and the driver can return to an observing perspective. These changes also help in the interpersonal relationship between the two developers to prevent them from snatching control of the keyboard and getting into micromanagement.
The environment is very important, both on a technical and personal level. A single computer (preferably the one of the newbie) with a pair of screens and a large table that can accommodate a keyboard, a mouse and common writing utensils is more than enough. It makes sense to agree on a font size, screen layout and even sufficient contrast if the partner has special needs. In conclusion, I would like to remind you kindly that it is important to maintain proper hygiene and good behaviour in order to avoid conflicts and unpleasant situations for everyone.
As the icing on the cake and as a personal recommendation, it is important to celebrate small victories between the pair. A special breakfast at the handover of a sprint, a game on the video console or the classical handshake symbolize a conclusion, so that they both can set off in search of the next challenge.
Together, but each with a defined role
At this point in the article you have probably laughed once or twice and wondered if it is possible to work in this way. I understand that it is complicated to work in such a reduced space and on the same task as another person who may have a different technical level, a different personal background, a different creative point of view, etc. … so I also point out some practices to avoid.
Trust is the key in a partnership, so it is advisable not to hide anything. It’s useful to explain why you check the phone or email (and you don’t have to go into private details), but if you don’t, it may indicate a lack of interest or commitment to the project, which eventually leads to tension.
The definition of the roles is very clear: the driver leads the action, the navigator controls and takes notes. It very often occurs, that the navigator tries to take the lead and to give the driver specific instructions on what to do or not to do, which then could lead to harmful micromanagement. In the same way, if the driver begins to think at a much higher level of abstraction, he may begin to get lost, taking on the tasks (and probably steal the patience) of the navigator, who will find that the deadlines are not met.
I cannot point out enough the limitation of the pair’s working hours. More than 6 hours is impractical, if not impossible, as it often happens that one of the two is involved in another project (especially in pairs of inexperienced/experienced developers) and then has to take over tasks such as meetings, documentation or administration, which leads to leaving the pair temporarily. It is as simple as it is advantageous to agree on a schedule for pair programming at the beginning of the day.
Bonus track: Pair Programmingin times of COVID-19
Using Pair Programming does not mean that both partners have to be in the same place, especially not in these times. Pair programmingand working at home is possible, but it actually brings with it a number of additional requirements and recommendations that should be considered:
- A sufficiently stable Internet connection is as natural as it is important.
- A solution for screen sharing. If it has remote control capabilities, all the better, although it is not absolutely necessary.
- An environment that is free of background noise and conducive to communication. A sufficiently good headset and a microphone provide the necessary equipment to communicate with each other.
- Since body language is important, video calls are very helpful. There are programs where you can see the camera at the same time as the screen, but you can also use other programs and even other devices.
- Tons of patience. Even with an ideal connection and perfect conditions, problems can occur, e.g. due to input lag or comprehension problems caused by the actual use of shortcuts, macros, etc. There is no magic solution to this, but it is important to maintain communication at all times to express what you want to do, but also what you do not know or do not understand.
