The Vinta Guide to Pair Programming

Pairing is a powerful approach to improve and reach greater results on a team/project. This post describes the Processes that Vinta's team is following to pair program. To fully obtain the benefits of this approach, take some time to read the Introduction section to understand the styles, benefits, and common challenges you will encounter while pairing.

Disclaimer: Most of the content on this page is compiled from the "References". The hard work was to understand their content, extract important pieces of information and organize them in a processual way.

Introduction

Pair programming essentially means that two people write code together on one screen. It is a very collaborative way of working and involves a lot of communication. While a pair of developers work on a task together, they do not only write code, they also plan and discuss their work. They clarify ideas on the way, discuss approaches and come to better solutions.

Pair programming styles:

Driver-Navigator: It consists of one person 'driving', taking the keyboard and coding or doing the work, while the other one is 'navigating'. The Navigator's job is to pay attention to the work being done by the driver while keeping the big picture in mind. They should guide the driver in the right direction. It is very important that driver explains verbally every decision they make, otherwise the navigator might lose interest and may stop paying attention. It's healthy to switch roles every X minutes.

Ping-Pong: This technique embraces Test-Driven Development (TDD) and is perfect when you have a clearly defined task that can be implemented in a test-driven way. A good strategy for this approach is to have one person writing the tests while the other one tries to pass them. As in the previous approach, you should be switching roles often.

Strong-Style: This is a technique particularly useful for knowledge transfer, described in much more detail by Llewellyn Falco here. The rule: "For an idea to go from your head into the computer it MUST go through someone else's hands". In this style, the navigator is usually the person much more experienced with the setup or task at hand, while the driver is a novice (with the language, the tool, the codebase, ...). The experienced person mostly stays in the navigator role and guides the novice.

Benefits

Awareness of all its potential benefits is important to decide when to do it, how to do it well, and to motivate yourself to do it in challenging times. The main outcomes pairing provides are software quality and team flow.

Team Flow: Is a state when a team optimize it's time by moving into periods of high focus and productivity together. This type of flow is strongly related to the state of flow.

Pairing requires different skills to get it right, and might even influence other processes in the team. For a team to be comfortable and successful at pair programming, they will have to work on skills that help overcome its challenges. Pairing gives everybody on the team a chance to work on these skills together.

Soft-Skills that can be improved during a pair programming session:

• Concentration and focus;
• Task organization;
• Time management;
• Communication;
• Giving and receiving feedback;
• Empathy;
• Vulnerability.

Scientific researches:

The Costs and Benefits of Pair Programming
Using interviews and controlled experiments, the authors investigated the costs and benefits of pair programming. They found that for a development-time cost of about 15%, pair programming improves design quality, reduces defects, reduces staffing risk, enhances technical skills, improves team communications and is considered more enjoyable at statistically significant levels.

The Case for Collaborative Programming
A field experiment was conducted using experienced programmers who worked on a challenging problem important to their organization, in their own environments, and with their own equipment. Findings revealed that all the teams outperformed the individual programmers, enjoyed the problem-solving process more, and had greater confidence in their solutions […]. Teams completed their task 40% faster than the individuals.

Challenges

Pairing requires practice:

• While pair programming has a lot of benefits, it also requires practice and might not work smoothly from the start

Pairing can be exhausting:

• When working alone, you can take breaks whenever you want, and your mind can drift off or shut down for a bit when it needs to. Pairing forces you to keep focus for potentially longer stretches of time, and find common ground with the other person's rhythm and ways of thinking. The increased focus is one of the benefits of pairing, but can also make it quite intense and exhausting.

Intense collaboration can be hard:

• Working so closely with another person for long stretches of time is intense. You need to communicate constantly and it requires empathy and interpersonal skills.
• You might have differences in techniques, knowledge, skills, extraversion, personalities, or approaches to problem-solving. Some combinations of those might not match well and give you a rocky start. In that case, you need to invest some time to improve collaboration, and make it a mutual learning experience instead of a struggle.

Pairing with lots of unknowns:

• When you work on a large topic where both of you don't have an idea how to solve a problem, the usual pairing styles often don't work as well. Let's say you need to use a technology for the first time, or try out a new approach or pattern. Researching and experimenting together works in some constellations, but it can also be frustrating because we all have different approaches to figuring out how things work, and we read and learn at different paces.
• When there are lots of unknowns, e.g. you're working with a new technology, think about doing a spike to explore the topic and learn about the technology before you actually start working.

No time for yourself:

• Being in a constant conversation with each other can be pretty energy draining. Most people also need some time on their own throughout the day. That is especially true for introverts.
• Keep the pair programming to a maximum of 6 hours per day
• When a pair feels that they don't have the collective knowledge to approach a problem, split up to read up and share back, then continue implementation.

Pairing requires vulnerability:

• Vulnerability is often connected with weakness and in most modern cultures the display of strength is the norm. But as the researcher Brené Brown has laid out in several talks and books, vulnerability is actually a very important ingredient for innovation and change.

When to pair

• When dealing with complex tasks;
• When dealing with boring tasks;
• When you get stuck;
• When onboarding a new team member;
• When one person knows the subject matter well and the other doesn't.

Setup

• Define who will be the host;
• The host must track the sessions on Harvest;
• If possible the host should turn on the mode "Do not disturb" on the computer to avoid distractions;
• If you have an unusual keyboard/IDE setup check with your pair if they are okay with it. See if you can have a simple mechanism to switch your settings back to a more standard configuration for these situations;
• Check with your pair if they have any particular preferences or needs (e.g. larger font size, higher contrast, ...).

Local

• Use the host IDE or Text Editor, next time you pair with this person try to use yours, is good to switch to see how other softwares works;

Default setup using a single computer:

• One mouse and keyboard;
• Two monitors;
• Sharing the same space;

Elite setup using a single computer:

• Two mouses and keyboards;
• Two mirrored monitors (or four);
• Separated spaces;
• Separated notebook to take notes and make research.

Remote

The host must use any video-conferencing tool with screen-sharing:

• Meets;
• Discord;
• Zoom;

So that you both can switch the keyboards the host must use Visual Studio Code with Live Share plugin to share:

• Project Codebase;
• Terminal;
• Server (e.g. "8000");
• Try to use the webcam on, since people communicate a lot through gestures and facial expressions it is nice to see the shared screen and your pairing partner's video at the same time.

Processes

1. Scheduling
2. Planning
3. Developing
4. Mini Retrospective
5. Celebrate achievements

1. Scheduling

• Define the task and goal of the pairing.
• Create an event on google calendar inviting your pair.
• Plan the pair programming to a minimum of 1 hour and a maximum of 4 hours per day.
• Try to schedule the pairing on freer days, pair programming can be very energy demanding.

2. Planning

• Read through the story/card and play back to each other how you understand it.
• Brainstorm and come up with a solution.
• Choose the appropriate Pair Programming Style.
• Plan your solution writing subtasks necessary to complete the full task.
• Write the subtasks on the task.

When implementing a feature that requires you to use a technology you are both unfamiliar with:

• Define a list of questions that you need to answer in order to come up with a suitable solution.
• Split up, either divide the questions between you, or try to find answers for the same questions separately. Search the internet or other resources within your organisation to answer a question, or read up on a concept that is new to both of you.
• Get back together after a previously agreed timebox and discuss and share what you have found.

3. Developing

• Develop one subtask at a time.
• Use Harvest with a limit of 25 minutes to switch between roles.
• After each session, you should take a 5-minutes break to drink water or go to the bathroom.
• After 3 or 4 of these sessions, you must take a long break (15–30 minutes). It's important to really take a break and tank energy, get some water or coffee, use the bathroom, get some fresh air. Avoid using these long breaks for other work, like writing emails.

Styles:

Driver-Navigator

Driver:

• Takes the keyboard to write the solutions for the current subtask.
• Should always talk through what is being done while doing so.
• Should always ask for feedbacks when necessary.

Navigator:

• Continuously revise and review what is being coded or typed.
• Should always ask questions if doubts of what is being developed come up.
• As navigator, avoid the "tactical" mode of thinking, leave the details of the coding to the driver - your job is to take a step back and add up to your pair's more tactical mode with medium-term thinking. Plan next steps, potential obstacles and ideas on sticky notes and discuss them after the tiny goal is done, so as not to interrupt the driver's flow.
• Apply the "5-seconds rule": When the navigator sees the driver doing something "wrong" and wants to comment, wait at least 5 seconds before saying something - the driver might already have it in mind, then you are needlessly interrupting their flow.
• As Navigator, don't immediately point out any error or upcoming obstacle: Wait a bit for the driver to correct or write a sticky note to remember later. If you intervene immediately, this can be disruptive to the driver's thinking process.

Ping-Pong

Try to track which type of tasks better suit this approach

• "Ping": Developer A writes a test for the next bit of functionality you want to add.
• "Pong": Developer B writes the functional code until the test passes.
• Each "Pong" can also be followed by refactoring the code together, before you move on to the next failing test. This way you follow the "Red - Green - Refactor" approach: Write a failing test (red), make it pass with the minimum necessary means (green), and then refactor.
• Developer B then starts the next "Ping", i.e. the next failing test.
• Must develop one test at a time.
• Each Developer must write only the test or the functional implementation.

Strong-Style

Driver:

• Usually the driver is new with the setup, system, module or task at hand.
• Reasons and challenges to the solution should be discussed after the implementation session, take notes to remember.

Navigator:

• Usually the more experienced person with the setup, system, module or task at hand.
• Guides the driver on every decision.

4. Mini Retrospective

• Reflect on how you both felt during the pairing session.

Do a quick round of feedback for each other:

• Is there anything you would like to try next time?
• Did you switch the keyboard often enough?
• Did you achieve your goals?
• Adjust this process.

5. Celebrate achievements

• Create your own way to celebrate achievements, like having good cup of coffee or eating something that you like.
• Try to celebrate together.

Conclusion

Writing code together is not easy. It involves different skills and common challenges at the beginning. It is essential to keep the practice a habit so that the team can overcome its initial challenges and start getting all its benefits.

References:

• On Pair Programming. https://martinfowler.com/articles/on-pair-programming.html 2020
• Pair Programming is not a Panacea. https://www.mattgreer.org/articles/pair-programming-is-not-a-panacea/ 2014
• Pairing. https://www.agilealliance.org/glossary/pairing/
• Pair Programming guide. https://tuple.app/pair-programming-guide/scientific-research-into-pair-programming

‍