What types of pair programming are there?

Driver and Navigator

In this variant of pair programming, the two developers take on the roles of driver and navigator.
As the name suggests, the driver is the person at the wheel, in our case at the keyboard. They focus primarily on achieving the small, immediate goal and initially ignore larger problems. A driver should continuously communicate what they are doing and why they are doing it while working, to create maximum transparency and keep the navigator actively involved.
While the driver types, the navigator is in the observer position. They continuously check the code, make suggestions for improvement, and share their thoughts on it. The navigator’s task is to keep the big picture in mind and work towards it. They keep an eye on larger problems and errors, take notes on possible obstacles, and consider the next steps.
The idea behind this role division is to obtain two different perspectives on the code. The driver’s way of thinking should be more tactical, thinking mainly about the details of the existing lines of code. The navigator can and should think more strategically in their observing role. They have the big picture in mind and must guide the pair programming accordingly.

Ping Pong

This technique is mainly used in the agile development method Test-Driven Development (TDD for short). Unlike the “Driver and Navigator” variant, both developers have an active role in programming here. To check the code for specific behavior, the developers alternately write and implement tests:

• “Ping”: Developer A writes a failing test
• “Pong”: Developer B writes the implementation so that it passes the test
• Developer B then starts the next “Ping”, i.e., the next failing test

Each “Pong” can also be followed by a joint refactoring of the code before the two continue with the next test. In this way, the developers follow the “Red – Green – Refactor” approach: They write a failing test (red), make it pass with minimal necessary means (green), and then optimize it accordingly. This back and forth between testing and coding, as well as between the two developers, promotes test-oriented software development and increases code quality.

Strong-Style Pairing

This type of pair programming primarily serves to exchange knowledge and experience. The navigator is usually the person who has a lot of experience with the setup or the underlying task. In this constellation, the driver can be less experienced or even a beginner (with the language, tool, codebase, etc.). The experienced developer passes on their expertise and guides the beginner through the joint project.
An important aspect is that the driver trusts the navigator, but always asks for clarification when things are unclear as to why a task should be solved in a particular way. This allows the navigator to thoroughly explain the intention behind their solution approach and possibly give the driver a better approach for similar problems.

What technology do we use for pair programming?

With collaboration software like Microsoft Teams, it’s easy nowadays to apply agile methods such as pair programming. Developers can work from anywhere in the world. All it takes is a call and screen sharing from the driver to get started. Even if the navigator needs to intervene to visually demonstrate their solution or simply to switch roles, a request for mouse and keyboard control is just a few clicks away via Microsoft Teams.

Analog vs. Digital

Everyone grabs another coffee, one rolls their chair to the other, who makes some room for them. Screen, keyboard, and mouse are collegially shared. This is how pair programming used to look.
The new situation moved us to home office. Now digital pair programming was born: Everyone gets a coffee and one shares their screen. Everyone keeps their own keyboard and mouse.
So the differences aren’t that big. The essential part, collaborative programming, still works just as well. Through access sharing, the observer can also program. If a third person’s knowledge is needed, they are quickly invited to the meeting.
Advantages of the digital version are working on your own, familiar hardware, better view of the screen, and everyone sits comfortably at their place. The location constraint is also eliminated. On the other hand, analog exchange is more personal and technical communication problems are avoided.
Both forms of pair programming have their merits, and digital collaboration works better than perhaps expected.

Code Quality and Learning Effect

Professional software development requires the four-eyes principle. Programmer A develops a new feature, Programmer B checks it again in the code review. Any errors or unfavorable code are subsequently corrected, and only then does the release and merging into the actual project take place.
Pair programming links both processes and enables better code quality during development. Subsequent correction is also eliminated.
With the seemingly endless possibilities of today’s technologies and innovations, it’s part of a developer’s daily routine to continuously learn. Pair programming allows both sharing knowledge and learning new programming languages and conventions. Unlike code review, feedback is not only on the finished product, but you have the tutor at the table while coding. Tutor and student, student and tutor, everyone learns from everyone.

Possible Disadvantages of Pair Programming

Higher Costs

When two people work on a single task, it can seem like a waste of valuable resources. Indeed, it’s true that pair programming can’t complete a project in half the time.

Nevertheless, the larger overhead caused by pair programming is typically offset by the higher-quality code and a more efficient, effective end result. The costs are higher upfront but can amortize over the entire project duration as less time needs to be spent maintaining the code base.

Sustainability

Pair programming is usually not sustainable enough to be practiced all the time. Using this approach for smaller problems is often not worth it, and some developers are more solitary, needing peace while programming. Therefore, one should select specific tasks where the use of pair programming seems sensible.

The Advantages of Pair Programming

Improvement of Collaboration and Communication

In general, each developer has their own approach to solving a problem. In pair programming, you have to communicate with your partner and coordinate how to appropriately tackle the problem at hand. This interaction usually opens up more alternatives, as an individual tends to follow the first solution that comes to mind. During the intensive collaboration in pair programming, the best solution is evaluated, and potential problems can be considered or even clarified in advance.

Continuous Code Review

In fact, pair programming is a kind of continuous code review and problem identification that occurs almost by the minute. Some errors such as syntax errors or semantic errors, as well as thoughtless solutions and clean code rules, can be addressed and resolved more effectively during this process than in a situation where a single developer wants to face these challenges without any support.

Improvement of Problem-Solving Skills

When a developer explains a problem to their pair programming partner, they will generally ask some questions about the problem and likely question the rationale. By precisely describing and justifying one’s own solution approach, not only does the partner gain a deeper understanding of the problem and its solution, but so does oneself. As a result, it often happens that during the explanation, problems and possible solutions are unconsciously uncovered.

Conclusion

While Pair Programming cannot be used permanently for all problems in software development and requires more resources than usual, it usually pays off over the course of a project. If you find a meaningful use case, the advantages of pair programming clearly outweigh the disadvantages, as the continuous mutual code review improves code quality. Furthermore, the constant exchange encourages the emergence of new, alternative solutions and approaches, and also promotes collaboration, communication, and experience sharing between the two developers. Since the transition from analog to digital also works well for Pair Programming, thanks to technologies like Microsoft Teams, our recommendation is: just give it a try