Understanding and Appreciating Pair Programming
Beside test driven development (TDD), pair programming is one of those disciplines to achieve software quality during software development. It is known as two developers working together on a single computer or video conferencing remotely to implement a set of features, with one driving the implementation and the other reviewing and providing direction for the implementation.
Every software developer should follow some technical disciplines when writing codes and take responsibility for not causing production issues that will result in serious impact to the user, i.e., sudden acceleration in car software.
— Uncle Bob Martin
The idea of pairing is to have multiple pairs of eyes reviewing the code, sharing context for new joiners, and allowing work to continue when one of them is not available.
Process
Assuming you have just joined a new team and the team culture practices pair programming and you are expected to pair with one of the team members. The first thing to do is to understand your pair working schedule and have an agreement on the pairing schedule and duration for both of you. Understanding that each team member has their own schedule, it is important to know upfront when to start and stop to have a better planning.
After deciding the time and which story to work on, one of you would take up the driver role by driving the code implementation and providing the task context. Since you are new to the team, your partner would most likely be the driver to drive the implementation. As the navigator, you are expected to try to get as much context by voicing out your ideas, concerns and questions, and switching to the *driver *role when you have gotten enough context to start a new story.
Before starting implementation, it is good to have a clear understanding of the problem to come out with a favourable solution by discussing with your pair. This is to make sure that both of you have an agreement and clear goal to achieve while implementing the story. Most often you will have some disagreement with your pair on deciding a solution but this is deemed healthy as making an informed decision is not straightforward. It takes time to weigh in the pros and cons to decide what is the best for the project. These disagreements may spark some interesting discussion, so do not hesitate to voice out your idea.
Conflict Resolution
When disagreement leads to a dilemma, it is important to call for a meeting with other team members instead of making decisions with assumptions. This is to seek other team members’ opinions especially from those who have wider context on that specific story and to prevent XY problem. Sometimes we see problems at a very specific angle during implementation without questioning if the solution is ideal or how it would affect other business domains.
<n00b> How can I echo the last three characters in a filename?
<feline> If they're in a variable: echo ${foo: -3}
<feline> Why 3 characters? What do you REALLY want?
<feline> Do you want the extension?
<n00b> Yes.
<feline> There's no guarantee that every filename will have a three-letter extension,
<feline> so blindly grabbing three characters does not solve the problem.
<feline> echo ${foo##*.}Discussing with different team members, e.g., Dev, QA and BA, allows access to higher level context and helps answering the initial problem.
Solution to a problem generally involves tradeoffs and compromises on which one requires the understanding of the process and who is going to use it. We usually have a tendency to overthink and design a perfect solution that requires a huge effort of refactoring. With limited time and resources, it is important to take a step back, understand the scope and measure the risk to see if the changes can bring more quality value to the user.
Safety
One thing that most people are not used to in pair programming is that they are not comfortable with another pair of eyes looking at them while writing code. When writing code alone, you could look at an issue at your own pace and not be afraid to make silly mistakes or admit not knowing certain code concepts or syntaxes, but during pair programming, you might be afraid of not meeting your pair’s expectations. It is difficult to align expectations and capability without transparent communication, so it is important to trust your pair, constantly communicate your thoughts with your pair and don’t feel pressured when making mistakes. For example, letting your pair know that you are not familiar with the project code base or language syntax, e.g., *Typescript, *would set the other pair’s expectation, making you more comfortable when searching for documentation while driving the implementation.
Another thing to note is that when you are in a navigator role, remember to listen more and restrain yourself from becoming a driver navigator. This is one of the safety’s killer during pair programming. Imagine if your pair is giving comments on every single line of code you are writing, you might end up not willing to voice out your opinion and thus no communication will be made.
A: "hey you forgot a inverted comma on your string"
A: "can you put the vars in all caps?"
A: "I think you should put that all in a function"
A: "could you rename the function"
B: <turn off the speaker and continue to code>Remote Pairing
It is also encouraged to have regular small breaks, 10-15 minutes, to prevent meeting fatigue especially when pairing remotely. Due to the pandemic situation, remote meetings have become more prevalent. Discussion, agile ceremony and pairing have changed to be conducted remotely via videoconferencing. With the decreasing physical interaction and increasing platform interaction, most of us might suffer from zoom fatigue. So remember to have more regular break checks with your pair. You could follow the pomodoro guideline on time boxing as a reminder for breaks.
- Decide on the task to be done.
- Set the pomodoro timer (traditionally to 25 minutes).
- Work on the task.
- End work when the timer rings and put a checkmark on a piece of paper.
- If you have fewer than four checkmarks, take a short break (3–5 minutes) 5. and then return to step 2; otherwise continue to step 6.
- After four pomodoros, take a longer break (15–30 minutes), reset your checkmark count to zero, then go to step 1.
While working on a project, there will be a time that you need to pair remotely with a cross region team member. Due to time zone differences, it is not easy to find a common time for pair programming, especially when you have several meetings in a day. In that case, you could take this chance for a break or do a code review. For example, when you have to drop off at the end of the day, your pair could continue working on the story and when you come back the next day, you could review the code and discuss the changes in the next pairing session. The pair should be flexible in making adjustments around when to do code review or pair programming.
Pair Rotation
Pair rotation is sometimes practised when a pair has been working together for quite a while. The motivation is to spread context to the other team members so that each part of the system is known and to discover more test scenarios from team members that have more domain knowledge. The frequency of pair rotation depends on the client project and team culture. Some teams rotate pairs multiple times on a single story, whereas others practise pair rotation only at the end of the story. A general rule of thumb is, as and when the working pair feels that they need another pair of eyes to review their code, they should call out for a pair switch. One good benefit of pair rotation is that you would get to know various development best practices, useful development tools or keyboard shortcuts, and learn how to apply these practices with that team member directly without any cost.
You could effectively practise pair rotation by keeping track of a pairing matrix. It could be used to identify who you should pair next by filtering who has never paired with you.
By pairing at least once with other team members, you would contribute in passing knowledge and developing good relationships with other team members. This is effectively having team building outside a specific team bonding time.
Final word
While it is not easy to get used to pair programming initially, it will become easier gradually when good communication is practised. Nonviolent communication is a good way to express your opinions and requests when working with your pair. The goal is to achieve trust in a pair by practicing mutual respect and transparent communication. These will help you feel more comfortable during pairing, which will lead to having more ideas, discussions and positive arguments. With more communication, the chances of coming up with more informed decisions during implementation is higher, leading to better software quality.
References
https://www.researchgate.net/publication/2333697_The_Costs_and_Benefits_of_Pair_Programming