Pair programming means two developers are working closely together, sharing the screen. There are different kinds of pair-programming tools, such as Live Share for Visual Studio Code, but Slack/Teams screen sharing works also just fine. So, it is easy to do remotely, with no need to physically sit side by side.

During this remote time, we have noticed that pair programming works nicely without sharing a physical desk. Just sharing the screen with a remote connection works very smoothly. Some might even say that pair programming works better remotely than by sitting side by side at the same desk.

One of the most established ways in pair programming is to use the driver-navigator method, where the driver works on the operative side, and the navigator looks at the broader whole. In practice, the driver writes the code, whereas the navigator constantly reviews the code and is aware of the big picture direction of the task at hand.

In the driver-navigator method, the pairs can (and must) switch roles. You may change the roles at regular intervals after the task is completed or when the other gets some idea.

It is also an excellent learning method for a junior developer to learn from a more experienced developer. But the point is not that the junior sits and watches the developer code because, as we all know, you learn coding only by doing.

Our Project Manager Ossi stated that two pros with pair programming are continuous learning and knowledge sharing. It forces people out of their comfort zones when they are following different projects or technologies. It is also a good way to onboard new team members to the project.

Our developer Pauliina stated that there are many positive things:

“Pair programming is a good way to learn and teach about the issue, technology in use or just working practices. When facing a complicated/tricky problem, two persons usually can solve the thing faster and better. 

When the developer is stuck with something, “a fresh pair of eyes” can help a lot, and sometimes the solution can even be something very simple. Saying things out loud is usually better than just thinking them alone and increased the focus. 

Pair programming is efficient because there is necessarily no need for a code review after, and most likely, there are fewer errors and better quality.”

A study about the costs and benefits of pair programming 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 chemistry and communication between two developers must be working before starting this kind of co-operation. Also, trust cannot be underestimated in the Driver-Navigator method. The driver must trust the navigator’s guidance and vice versa.

“We are emphasizing this quite much; pair programming is not for everybody. It is not fruitful if it is forced upon people.” Ossi states.

Even the most fanatic pair programmers must admit that pair programming doesn’t always serve the purpose. Sometimes it is just better to do the task all by yourself, rather than the two developers’ waste resources. Pauliina adds: “For example, this is the case when the tasks are relatively simple and do not require that much innovative work.”

The pair also must be equally committed to the work. If the other is silent and passive, the co-operation will not fly even with the best pair programming tools. So, a clear vision of what is needed from both parties is crucial. The project manager needs to communicate the objectives so the backlog can be built in the right order.

When it works, pair programming can be very rewarding and instructive. It is a co-operation between two experts, so the two must find their common flow. There are as many ways to do pair programming as there are pairs. 

Writer:
Jon Tarkiainen, COO of Anders