In recent months, I’ve been working with a company that prefers using the “Pair Programming” methodology, which I had never used regularly. It happened to all of us to discuss a problem with a colleague or look together at a piece of code searching for possible improvements, but making it a working methodology is surely different.

First, let’s explain what this methodology consists of, borrowing Wikipedia’s definition: “Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently. While reviewing, the observer also considers the “strategic” direction of the work, coming up with ideas for improvements and likely future problems to address. This is intended to free the driver to focus all of their attention on the “tactical” aspects of completing the current task, using the observer as a safety net and guide.” (https://en.wikipedia.org/wiki/Pair_programming)

This is only a definition of Pair Programming, but the variety of styles to realize it is manifold. Let’s see some examples.

Ping Pong Pairing

This style suits you when you use TDD as a development method. We will then have the following steps:

1. Ping: Developer A writes a red test (failed)
2. Pong: Developer B writes the implementation to make it green (passed).
3. Developer B then starts the next “Ping”, the next failing test.
4. Each “Pong” can also be followed by refactoring the code together, before you move on to the next failing test. This way you follow the “Red – Green – Refactor” approach: Write a failing test (red), make it pass with the minimum necessary means (green), and then refactor.

Strong Style Pairing

This style is mainly used when a new member needs to be added to a team or a project. The basic idea is that the viewer’s project is implemented by the person who writes the code. In this style, the Observer is usually the person much more experienced on the task to work on, while the Driver is a novice who, during the implementation phase, will probably not completely understand what he will write. After implementation, some time must be dedicated to any Driver’s questions about what has been implemented. This style is particularly loved by those managers who prefer the “learning by doing” over passive “learning by watching”

For a correct pair programming session, choosing the right style to use is not enough: there are other aspects to keep in mind, so as not to make the experience frustrating.

Time management

We are not machines, working eight consecutive hours with another person who observes us or just watching is not easy: it is better to use short spans of time during which focusing on specific aspects of the implementation, which will lead to the closure of the assigned task. A recommended technique is the one called “Pomodoro”, which is divided into five phases:

1. Decide which task to work on
2. Set a timer on 25 minutes
3. Do some work without interruptions
4. Pause work when the timer rings (5-10 minutes)
5. After 3 or 4 of these “pomodoros”, take a longer break (15–30 minutes). Avoid using these short breaks for other work.

Pair rotation

The pair rotation consists of changing one of the pair’s two components after they have been working together for some time on a task. This method should favor sharing knowledge within the team and avoid the focus of knowledge on individuals. It is also advantageous because of a logistical reason: one of the two components could be absent due to illness, or holidays. The rotation has advantages and disadvantages, and it is up to anyone to understand the best way to do it.

Planning of the day

Working in pairs requires that the two people organize themselves to have the same periods to finish the development. Agreeing on schedules to avoid impediments such as meetings, personal matters, etc. increases the productivity of the pair and avoids the unpleasant situation in which one of the two must wait for the availability of the other.

Like all working methods, this one has its advantages and disadvantages too. I would like to explain what I found useful in it and what, instead, did not convince me.

Advantages

Sharing of knowledge: working closely with another person certainly has the advantage of learning something new. Observing a different way of thinking, approaching a problem, and solving it certainly helps our professional growth.

Fast onboarding of new team members: usually, when you join a new team, there is always the first adaptation period to learn the working methodology, i.e., carrying out simple tasks to get to know the various projects. On the other hand, being able to work closely with a person who already has experience in everything related to the work that will be faced, still allows a “soft” but certainly faster and more effective onboarding, whether you are a Driver or an Observer. The alternation of these two things allows, indeed, in one case to observe the various “secrets” useful for speeding up the process in which one becomes productive; in the other, it can speed up the identification of weak points on which to work to increase one’s productivity.

Better Code: Four eyes are better than two. Mathematics is not an opinion; two people looking at the same piece of code are certainly less likely to be wrong. You discuss the architectural choices, any libraries to use, and which patterns to choose. Comparison is always a good thing and produces better things.

Disadvantages

Towing effect: one of the worst things that can happen during a pair is that the Observer is not very involved. It can happen if the pair works remotely: the physical distance can cause the Observer to go about its business, leaving the Driver alone to solve the problem, and diminishing the usefulness of this working methodology, producing waste of economic and human resources.

Wrong Pair: some people particularly like to work alone, perhaps listening to music, while others may not be at ease while they are observed writing code. Whatever is the reason, in my opinion, it is not convenient to force a pair. Maybe it might be useful to rotate the team’s pairs until you find the one that works. This is another controversial aspect: somebody thinks that rotating pairs at regular intervals only brings benefits, perhaps for some of the reasons I explained above (such as sharing knowledge). In my experience, it is not always right: it is good to change partners now and then maybe every two or three iterations, in order to enrich your experience, but if you have found a good workmate that increases your productivity and does not turn out massive working day, it is good to continue to work together.

Remote pair: one of the advantages of this methodology is certainly being able to interact with another person by being in close contact. For me, the best method is one in which you use only one terminal, and the pair sitting at the same desk works and discusses the task they are dealing with, often switching the roles of Driver and Observer. Working remotely with another person who you have never met personally, can make this methodology sometimes heavy. Of course, this is not the rule, all these speeches are subjective, and some people prefer to work only remotely by far. But, in my opinion, the social interaction part is crucial to make this processing technique work well.

Conclusions

As mentioned before, what I expressed is my opinion. I can say that, like everything, the use of this methodology certainly increases one’s wealth of experience. In my experience, it happened to be paired with a very skilled colleague on TDD (Test Driven Development): observing his way of working and receiving corrections on my work much helped me to learn how to use correctly and efficiently this development methodology.

The level of experience of the two actors involved is also very important in pair programming: working with another Senior can certainly be fun and allows you to grow but working with a developer with a Junior profile helps the team to grow, transferring knowledge to a person with less experience than you.

I hope I have alimented your curiosity on the subject and maybe the desire to try pair programming in your production cycles.

See you in the next article!