Onboarding a new developer to our team can be a complicated process. They need to fill out HR paperwork, get a development environment, and find a comfy place to work (along with a caffeinated beverage). Then someone needs to fill their head with all of the institutional knowledge they need to do their job. There are lots of ways to do this but one of the ways I prefer is to code with another developer at the same time using pair programming.

In this article, we’ll discuss what pair programming is, how to do it, and the benefits and drawbacks of the process.

## What is Pair Programming?
Pair programming is a technique to develop software where two or more programmers work together on a shared codebase at the same time. Now, they don’t both actively write the code instead, one of them operates as the driver, who writes the code, and the other operates as an observer or navigator who reviews the code as it’s typed to look for errors and asks questions.

Pair programming is a very collaborative way to develop code and involves a lot of communication. While a pair of developers are working on a task, they’re not only writing code but also they also planning and discussing their work. This allows them to clarify ideas, discuss potential solutions, and ultimately come to a better solution.

Depending on your objectives for the pair programming session, there are several ways you can structure the session.

The first is that you can alternate who is the driver and who is the observer regularly. This is helpful if both developers are near the same level of knowledge and experience. Because they can contribute equally, they both get to spend time working and reviewing the code. I’ve seen suggestions that the total pair programming session last no more than an hour and they swap every ten minutes or so, and I’ve seen suggestions that they swap off every half hour with a long break after an hour. It’s up to the developers to determine how often they should swap off and for how long.

The second is that you can have one developer be the driver and one be the observer for the whole time. This is helpful if there is a knowledge gap between the two developers like when a new developer joins the team. This allows the driver to create meaningful code while the observer can focus on learning, taking notes, and asking questions. As the new developer becomes more knowledgeable, they can take on more and more driver responsibilities.

When starting a pair programming session, make sure you start with a well-defined task. Then agree on one tiny goal to tackle at a time. This can be defined by a goal commit message or unit test. Continue picking small goals until the task is completed. Then once the task is completed, determine if you should pick up another task or conclude the pair programming session.

Pair programming can either be done in person or remotely. Let’s discuss how that will work in each case.

In person

During in-person pair programming, the two programmers share a single development environment in close physical proximity. This can mean they can use a single computer and share a keyboard, monitor, and mouse or they could each have their own input devices. This method of pair programming has the pros that you don’t need to have software to “share” the code between two users. The downside to this method is that it requires a good deal of space. You need to have enough room so two developers can comfortably see a monitor at the same time and swap between them. I’ve done this in a conference room with the IDE projected on a screen so it was easier for everyone to read.

Remote

During remote pair programming, the two programmers share a single development environment with each developer in a different location. They then use one of the developer’s workstations and the developer shares the screen and/or code with other developer. This can be done using meeting applications like Zoom and Slack but is much easier to do using dedicated software for sharing code workspaces. PHPStorm and VS Code both have support to allow one developer to share their code and have the other developer edit it at the same time. The positive to this method is that each developer can work in an environment to their liking (maybe even outside) without worrying about being in the same physical space. The downside is you might have to deal with poor internet connectivity and manage the delay in communication due to the remote connection. It’s possible to set up a completely remote development environment for both developers but it’s not always possible for some applications/industries.

My best suggestion for remote pair programming is to make sure you’re in a quiet spot and have an excellent headset. Nothing will grind a pair programming session to a halt faster than having someone’s audio be unintelligible.

Benefits

There are numerous benefits to pair programming.

As someone who manages developers at different skill and knowledge levels, the biggest benefit is knowledge transfer. By pairing a developer that’s new to the team or who needs some help leveling up their skills with a more experienced developer, they can more easily aid in knowledge transfer. This can be helpful for all levels as well. I usually learn about some new tools and techniques from new developers as they join our team through pair programming.

Because two developers are thinking through the code as it’s developed, there’s a better chance that bugs will be found at this stage. We require all code to be reviewed by another developer before it’s merged into the “main” branch, but it’s generally a very high-level check to make sure it functions correctly. Because the observer is walking through each line of code as it’s written, they’ll have a better understanding of what the code is doing and help prevent some trickier bugs.

It will also reduce the chance that other structural issues are created as they’re developed. Because two developers are working through the solution to the task at the same time, they can both add their knowledge to the solution and create a better solution than if they had worked separately.

Drawbacks

Pair programming isn’t without its drawbacks.

The largest drawback is the fact that it increases the number of person-hours that are required to deliver a solution when compared to having a single developer work on the solution. However, this can easily be displaced by the knowledge transfer and the reduction in bugs because other factors like support and QA costs also need to be figured out in the return on investment.

Another drawback is that it can be very draining to have to communicate our thoughts to another developer before we act on them. This can be alleviated by taking frequent breaks and not allowing pair programming to consume our days.

Practical Tips

There is a limit to how much pairing developers can do. Some teams might want to do pair programming 8 hours a day, but it’s not sustainable primarily because it’s exhausting to operate in this mode for long periods.

It’s also important that when creating pairs that there’s rarely a junior-junior pairing. It can produce results that are better than the two juniors working independently, but without a more experienced developer in the pair, it will be hard to develop good habits.

Both programmers should commit to being actively engaged in the task. Otherwise, the benefit of working in a pair programming session will not be realized. When I pair put my phone face down on a different surface so I’m not even tempted to look at it.

Use pair programming as a chance to spread the knowledge of developers around your organization. If you notice a member of your team is working on the same topics all the time as them to help you with a different area of the software.

What You Need to Know

• Pair programming is a development technique
• Involves 2 developers working on shared tasks
• Can be done in-person or remotely