In Agile and XP software development, pair programming (also called peer programming) is a technique where two developers work side by side on the same computer. This doesn’t mean that there are two people trying to use the same keyboard and mouse at the same time. It means that two developers work together as a team on the same computer.

Basically, one person enters code on the keyboard (the driver). The other person focuses on the direction the programming is going in (the navigator). Together, the two developers work to solve the same problem so they arrive at the same goal using the best and most efficient path they can find.

How does pair programming work?

However, there is a little more to pair programming than just two developers working at the same computer. And it’s not about one developer sitting and watching the other. The idea is to have both developers actively communicating and collaborating with each other to develop high-quality software code. 

The driver and the navigator

The two developers work as a team with each having specific roles of driver or navigator. The driver’s job is to do the hands-on work of entering code. The navigator’s job is to support the driver by reviewing code, asking questions, and making suggestions where appropriate that can help you write cleaner code. With the driver focused on entering code, the navigator is free to focus on the next few steps and the overall direction of their work.

This is why it’s important for the pair programming team to communicate while writing code. They each need to know what the other is thinking. This makes it easier to come to a consensus that leads to the best and most efficient approach for writing code.

The four eyes principle

You may have heard somebody say something like “I need another pair of eyes.” The idea is that if somebody else reviews your work, they can help you to find errors that you missed. For example, an editor might find typos that a writer missed. The writer may have missed these typos because his brain “sees” the words or phrases he meant to write.

This is basically the four eyes principle. While working in a pair programming team, the four eyes principle ensures that at least two people are reviewing and approving the code writing activities. In the end, the code you produce will be of a higher quality and a better value to your customers.

Determining how to proceed

After getting an assignment, your development team needs to decide how to proceed. They might want to talk about which techniques to use, who will drive and who will navigate, what challenges they might face, and so on.

Don’t make the mistake of getting locked into the driver or navigator role. Be sure to take turns in each of these roles. This helps each of the developers to keep their minds fresh and alert and helps them to more easily check each other’s work as they go. There is no prescribed time interval for switching roles. It’s up to the developers to determine how often they will rotate. Just make sure that each team member gets the equal amount of time in each role.

What are the benefits of pair programming?

It might sound like it’s counterintuitive that two developers working together at the same computer can be productive. It might seem like they would get in each other’s way. 

But, if you are willing to give pair programming a try, you might enjoy some of the following benefits:

• More agility: Pair programming can make software development more agile. The two developers working together can more easily adjust goals and priorities as they work than one engineer working alone.
   
• Better quality code: Because programmers are constantly communicating with each other, they have a clearer idea of what they want to do and where they want to go. This clarity can reduce the risk of errors (and the time you’d have to spend fixing them).
   
• Training and onboarding: Introducing pair programming early to a new hire can reduce the amount of time it takes for new employees to get up to speed. Pairing new developers with senior level developers helps the new people learn the architecture, company standards, and the tools used much more quickly.
   
• Knowledge distribution: You don’t want to limit institutional knowledge to just a couple of employees. If they leave, they take that knowledge with them. Working in pairs lets you spread the knowledge around so it’s easier to cover for employees who are absent or leave the company.
   
• Developing working software much more quickly: When developers working alone run into a problem, they might have some downtime while they try to figure out a solution. Instead of stepping away from the problem for a while to clear their heads, they can talk to their pairing partner to discuss ideas and possible solutions. This can help them to get back to writing quality code much faster.
   
• Increased teamwork: Because of the continuous communication between the developers, it helps to build a team culture with greater chemistry, trust, accountability, and ownership. A stronger team dynamic can lead to increased employee satisfaction.

Pair programming etiquette

While pair programming can be rewarding and beneficial, it can be a challenge to implement. Some people might be very uncomfortable working this closely with somebody else. And you might have employees who really do excel when working alone.

Here are a few behaviors or rules that can help you to be successful in your pair programming efforts.

• Determine where you will work: This might sound trivial, but the team needs to be comfortable while working. One developer might like to stand while the other likes to sit when writing code. And each programmer is more comfortable with their own computer’s desktop layout, colors, fonts, etc. You need to figure out a physical environment that is comfortable for both.
   
• Keep focused and engaged: As a navigator, you need to pay attention to what the driver is doing so you can offer suggestions, ask questions, and help to keep the project on the right path. And the driver needs to refrain from the temptation to check every email or IM notification that pops up on the screen.
   
• Program out loud: Keep talking to each other and share your thoughts. Explain what you are doing and why you are doing it. Be open to suggestions and comments from your teammate.
   
• Navigate, don’t dictate: As the navigator you are not in charge of the driver. Avoid the temptation of telling the driver what to do. Nobody likes a backseat driver. Give the driver a chance to ask questions or for help before telling them what to do.
   
• Switch programming pairs often: After a programming pair has worked together for a few days, move one of the team members to another team. This helps you to spread knowledge more quickly and offers the opportunity for team members to learn more from each other.
   
• Be clear and specific: If you are making a suggestion, be sure your partner understands what you are talking about. Be concise in your explanations. If you are talking about specific code, refer to line numbers and file names.
   
• Be patient and open to new ideas: You might not be paired with somebody as skilled as you. Be patient and let them work at their pace. If you don’t like the way your partner works, give their method a chance. You might learn something new. Be sensitive when pointing out errors or potential problems.

Remote pair programming

More people are choosing to work remotely these days, and companies have adopted a hybrid work environment. Fortunately, you can still practice pair programming without being in the same physical location. To do this you need a screen-sharing solution such as Zoom or Microsoft Teams.

It can also be helpful to have a shared visual workspace like the Lucid Visual Collaboration Platform to diagram complex code structure before diving into your editor, and for creating easy-to-understand documentation.

These applications let you not only see the other person’s computer, but control them as well. And they let you talk to each other as well so you can remain in constant verbal communication. All of this means that you can easily switch roles as needed and collaborate on quality code no matter where you are in the world.