According to recent Gartner research, nearly 50% of employees across industries will continue to work remotely when the pandemic is over.
While we’ve had more than two years to adapt our working styles to the remote-first world, there are still lessons to learn about how best to facilitate remote work, and how best to share knowledge and skills training when face-to-face is not an option.
At Rangle, we’ve always been advocates for pair programming, both for internal learning and during our client engagements. We believe the best way to learn is by doing, and so when we were faced with some challenges on a recent client project, we relied on our pair programming skills to achieve our goals.
In this blog, we’ll review the benefits of pair programming (specifically for remote work), the patterns and techniques we found helpful, and the overall benefits it can have not only for developers but for the business as a whole.
Understanding the benefits of pair programming
Pair programming, where two developers work together at a single workstation to either demonstrate techniques to each other or share the tactical and strategic work of programming in concert, is the old adage “two heads are better than one” in action. As a core part of agile methodology, pair programming ensures that learning happens in a mutual, free-flowing way, where even if one developer “knows” more than the other, there is often an exchange of ideas that’s mutually beneficial. Pair programming also improves focus, minimising distractions and helping the team to accomplish tasks more efficiently. Best of all, working together improves the quality of the software, as peers can review each other’s work in real-time, making the work of code review or quality assurance much easier.
During our recent client engagement, there were four styles of pair programming we used most frequently to facilitate learning and improve the quality of our work:
- Driver-Passenger: First, as a brief onboarding exercise, we used a “Driver-Passenger” pattern: The driver is the expert, and the passenger is watching the road ahead – taking in the surroundings, and asking questions about the various landmarks. This is useful as a jumping-off point, but to be effective, pair programming should include various styles, not just this demonstration role. In the early days of our client engagement an expert pairee onboarded new team members in this style. The information covered would then feed into the Available and Offline states for the passenger to learn or complete research for the team.
- Driver-Navigator: The second style is “Driver-Navigator.” In this pair programming role, the navigator provides the directions, which the driver executes. For the purposes of our client engagement, this was also a short-term onboarding phase role for us. The navigator is often the ‘teacher’ in this scenario, giving fairly explicit directions and being careful to explain them when necessary. As the driver gains confidence, the roles can be switched and/or the directions can become less explicit. This project required a lot of research, and so when each developer set out to gather knowledge, they would come back and then take on that navigating role. This would switch when the next developer would come back with research. This style naturally evolves into the “Pilot-CoPilot” role.
- Pilot-CoPilot: “Pilot-CoPilot” describes when one developer is actively coding, and the other is maintaining situational awareness — observing techniques, looking for potential bugs, and keeping track of the big picture, including side issues and potential new tasks. Switching roles can happen at any time, and may occur based on task completion, a timer or how the pair is feeling about the work. During our client engagement, this style was our most typical pair programming experience. We maintained active communication not just among the development team, but also among our cross-functional teams. To facilitate this, the CoPilot would often keep an eye on our Slack channels and other communication tools so the pair could remain responsive to questions and follow-ups without creating distractions.
- Ping-Pong: Finally, the “Ping-Pong” style of pair programming is when the pair passes control back and forth at a faster pace, often in a Test Driven Development scenario (one collaborator writes a test and the other writes the code to pass the test). We found this mode useful in executing demos and complex manual tests. It was natural for each person to have a set of tasks, and this would speed up the execution of multiple steps and make demos of work in progress flow smoothly.
Best practices for pair programming
It's important to maintain verbal communication during pair programming. It should be an active process for both developers, otherwise, it’s hard to do for extended periods; breaks and switching out the roles help each person maintain focus and contribute to the overall quality of the end product, as well as the learning experience.
Throughout our client engagement, we were reminded of the importance of sticking to best practices for pair programming. When working remotely, we ensured that our pair programming took place while in a virtual meeting room. While cameras are off, communication is still flowing, and questions are answered quickly. This also allows for more detailed conversations and discussions without the barrier of a messaging platform or email. Chat applications are also a drawback because they compete for the developers’ attention, whereas verbal communication between the pair is less disruptive.
When the pair works offline, such as during research tasks, tackling some protracted debugging or updating documents, it is best practice to schedule a block of time for this and regroup at the end. Remember that sharing learning with your partner is a great way to help the information stick in both people’s minds.
Finally, scheduling and planning the day is an important piece of effective pair programming. After the day's priorities have been established in the daily scrum meeting and any outside obligations are understood, the day is divided into blocks of time for active pairing and for individual work. During this engagement, we tried to replicate the availability of an open office environment by communicating when we would be ‘Active,’ ‘Available,’ or ‘Offline’ throughout the day:
- Active: Pair programming or collaborating on design, implementation, and testing; attending meetings
- Available: Working on a task but open to being interrupted for questions or advice (this approximates the office environment)
- Offline: Alone time to focus, investigate and report back. While offline, responding to chats or emails may be delayed.
These states help bridge the gap between the remote work environment and the typical office setting. Moreover, including a time when collaborators are not available gives team members a set time to focus each day. Experiment with how much of the day is spent in each state to find out what is most effective for your team. We have found that three to six hours of active time each day is best for pair programming.
Why remote work pair programming is mutually beneficial
It’s easy to see how pair programming benefits the development team, but it has a ripple effect of impact on the larger product team and your business. The underlying practices, beliefs, and benefits of pair programming can be used in any team's work environment. The efficacy, team mentality, and focus it creates leads to better product outcomes. We've found that pair programming breaks down silos within and between teams, reducing the feeling of isolation that remote work can create. Pair programming is also a risk mitigation tool — knowledge sharing is a key benefit of pair programming, and unplanned absences or employee turnover becomes less of an issue when the team has good context-sharing practices in place.
When working remotely, it can be hard to interrupt a colleague, making you feel like your questions are a bother. When they are explicitly available, however, it’s a sign of permission that can reduce the anxiety of potentially taking their focus away from their work.
Also with remote workers, it can be easy to feel “out of the loop”, and also easy to miss out on information shared in ad hoc conversations or meetings. Keeping a flow of conversation happening in a virtual meeting, on the other hand, ensures that these conversations are open and everyone can share in them. Moreover, working in this mode makes it easier to coordinate hybrid work environments. Employing pair programming means it’s not a deal breaker when some team members are in the office, while some work from home.
Finally, remote pair programming is an excellent way to ensure individual workspace accommodations for people with disabilities. Setting up remote pair programming is an opportunity for pairees to define their processes and expectations in a concrete way, which allows them to maintain the protocols agreed on by the team without any team member having to enforce or regulate the environment. In the course of our client work, for example, it was possible for pairees with ADHD to maintain personal environments that were supportive of their working style without concern for how it might impact those around them. To illustrate this, one of our team members found it beneficial to walk around while planning or problem-solving. While this might be distracting to the other team members in an office environment, working remotely meant that this developer was free to work in the way that best suited them.
Creating a great culture is not about the add-ons to work, like parties, volunteer opportunities, or what’s available in the break room. The most important part of culture is how it feels to do the work itself, and how supportive the day-to-day environment is for everyone on the team. With remote pair programming, developers and other team members have the opportunity to construct their day in a way that suits them best and stay connected with their colleagues in a healthy and supportive way. If you’d like to learn more about how we actively create a great culture at Rangle, check out Hiring the whole person: The why and how of a great talent acquisition program.