Quick-start to Pair Programming. 3 Strategies For You.

I’ve been practising Pair Programming for over two years, every day. Through this time together with the team, we had ups and downs. We faced some problems, that the Pair Programming theory does not mention. After some time, we clarified three strategies for doing Pair Programming, that we were using.

Some theory

As of formal definition, Pair Programming utilises a single computer for the work of two developers. That means two people sitting by one keyboard and monitor, changing the person who is typing. If we use this definition, I would need to say I never did Pair Programming. We hated to work by one desk, as we loved our personal space. Instead of that, we used screen sharing.

While working in a pair, the person who is currently typing (do not say “working”, as someone will think the other person is doing nothing) is called the Driver. The person next to is called the Navigator. Depending on the strategy, their role will be a little bit different. The common part for each of the approaches is that both of them must be fully focused on the work. Looking back, that was the most challenging part of Pair Programming.

How to start

• Do not change the whole team approach. Suggest the change, but it will be alright to find a single ally to start with
• Select your setup — single desk, desk by desk, videoconference with screen sharing or IDE-integrated screen sharing
• Agree on the used strategy
• Set up when you will have some slack time. It is good to have a break and do other stuff.
• During the work, talk. A lot. Say loud every idea that you have in mind, even if it will sound stupid. It might create other thoughts

Straight to the point, let’s look at the techniques!

Strong technique and Traditional technique

Often you can find texts that are referring to those techniques, but I’m not a big fan of them. As I do not use it, it will not be counted here as a Pair Programming strategy to check for you. Strong technique indicates that Navigator is the one who tells exactly what to code to the Driver. Navigator is fully absorbed by the work, while the Driver in extremes might be reduced to code monkey. The traditional technique gives the Driver more flexibility and the ability to express their thoughts. Still, it might easily produce a situation, when one side is less engaged, as there is no clear information when to change.

Pros:

• The simplest one; requires only the second person

Cons:

• Engages one side more than the other
• Disturbs the communication, especially strong technique (The Driver to change the development direction must switch the role with the Navigator)
• Misused often while mentoring new developers — in such case people tend to call “Pair Programming” a situation when one person works while the new developer is just sitting and watching

TDD Strategy

Strategy based on and strongly forcing Test-Driven Development. Simply saying, the Driver writes the test that fails, and then the Driver switches.

The next Driver implements the simplest passing code and does some refactoring. The last step is to write the next failing test, and switch again. The Navigator in the meantime is someone, who focuses more on the general view: checks if business logic is satisfied, give hints during development or play the role of a rubber duck.

While using this Pair Programming strategy, you end up with well-tested code. In the beginning, when you are inexperienced with Test-Driven Development, there might be a huge disproportion between time used for writing the test, and its implementation. You need to force yourself to test units; integration tests are usually added at the end and check only the communication of your application with the outer world. Test structure will fall under the test pyramid, so it is not the best solution if you are aiming for a diamond or trophy.

Pros:

• Clearly defined when to change the Driver
• Changes between Driver and Navigator are often, limiting the possibility of losing attention
• Produces well-tested code
• Gives nice, step-by-step history in the repository

Cons:

• if you have none-to-little experience in TDD, this might be overwhelming
• Almost no slack time
• Actions/pipelines on repository must accept that the tests on a branch will fail

Pomodoro Strategy

It is the merge of the Traditional Pair Programming Technique and Pomodoro Technique. Define the time frames for the coding sessions and breaks. We preferred to have coding sessions around 20–25 minutes, which is usually enough for “loading the context” into your mind and writing some code. After that, have 5 minutes break. Repeat this sequence 2 to 4 times, then have a longer break, around 10–20 minutes. Switch the Driver every break you take.

The Driver needs to write tests, implement the code and refactor it. There is also a huge need of understanding others code. It will be very often that the Driver needs to pick up unfinished code from the previous session. As soon as the session ends, make a commit and hand over the code.

Remember, that while the Driver is coding, the Navigator has a lot of work too. Navigator needs to follow the code, check the documentation in the meantime or google for some solution if needed. You must provide the support, so the Driver can work as effectively as possible. Navigator is also responsible for keeping the eye on the time, and say when to take the break. Be a little bit flexible on the time frames of the coding session — if the Driver is currently “in a zone” or needs to finish the thought — let for it. If you see that Driver struggles with something, suggest switch earlier if you are unable to explain the solution.

While practising this Pair Programming strategy, we had a strict policy, that we are using breaks to walk away from the computers. That gave us a refreshing moment and we were much more focused during coding sessions.

Pros:

• Might be better if you are unfamiliar with TDD
• Gives time to the Navigator to seek a better solution
• Forces people in pairs to talk out loud, in other cases picking unfinished code is difficult
• Clearly defines breaks and allows for slack

Cons:

• Requires people with a similar level of experience, in another case less experienced person might not follow the Driver
• Actions/pipelines on repository must accept that the code on a branch will not even compile

Mob Strategy

Not a Pair Programming strategy, but something that can help spread the knowledge. In Mob Programming, you need to engage more than two developers. Back in the times when we were working in the office, it was a great time to sit in one conference room together and share the screen with all the people. The Driver in this case is presenting the work on a big screen, while everyone else should brainstorm possible solutions for the problem.

Multiple participants can discover more topics in parallel, while on the big screen there is always a current solution that was selected by the team. Sometimes pairs are forming in the mob and checking some idea, giving you a hackathon-like experience.

This strategy is also great for team building — use it to have a common coffee break for all participants or have lunch together. I know that probably you are still working from home, but that’s still OK! Use mini online games for catching a break and prevent brainfarts. We used Haxball and Among Us as few minutes break.

The main disadvantage of this strategy is the struggle to keep everyone focused. There are a lot more people engaged than in Pair Programming. In large gatherings, it is very common for individuals to lose focus. The simplest way to deal with that is to ask such a person to check a single, easy and well-defined topic. Keep an eye on changing the Driver from time to time.

Pros:

• Boosts knowledge sharing dramatically
• Perfect for starting big and complex tasks
• Can be used cross-team for explaining dependencies
• Team building

Cons:

• Consumes time of a lot of people
• Individuals often lose focus
• Discussions might be too intense — someone (Driver preferably, or you can pick Navigator for that) should keep an eye on too long discussions

OK, which one should I pick?

First of all, find a person that is willing to give it a try. Remember that you cannot force anyone to do it. A developer who is forced to do Pair Programming is miserable and will not be engaged enough to work effectively. It is enough to have just one person to try with, and others will probably join when they will see the result. Also, do not try to work the whole 9 AM-5 PM in a pair for the first time, so start from some simple task.

I would say, if you are using Test-Driven Development, start with that one. If it is something new or unknown, go for Pomodoro, but try to write also some tests. I’m not a fan of Traditional technique, but if using Pomodoro seems to be an overhead, start with it. Just remember to switch the Driver and Navigator often. The last thing — use Mob Strategy when you have a complex task. Suggest it to the team, even if you are not the one who is responsible for delivering that task — in the end, the whole team should feel responsible for the solution you provide.

Common problems

Different working hours

It is common that team members are not working exactly the same hours. I like to start the work at 7 AM, while I was paired with a colleague who liked to start around 10 and we managed to do it. We did Pair Programming during the common 5 hours and consumed the remaining time for other activities. There is always something other to do: code review, respond to emails, support other teams, maintain infrastructure or attend a meeting — all those activities are time-consuming, and you can do it while waiting for your pair to show up. You can also work on code during that time and hand over it later.

The person who I’m paired with have different approaches/ways of working

For me, it is the biggest problem. It can grow especially when two people are dogmatic and do not want to compromise. On the other hand, Pair Programming is the proper way of understanding other approaches. It requires the dialogue from you, using proper argumentation that is not emotional nor habit-based and listening to the other side. If you are unable to take substantive discussion, maybe it is something that you should work on — not the other side? In the worst case, you can suggest changing pairs.

My manager does not allow us to work in pairs

The root question is “why the manager decides on that how you are working”? Micromanagement is a productiveness killer, and the person who is not responsible for maintaining the code and application should not have the final word on used libraries or techniques — unless it is not opposed to the company rules like using exotic language instead of the common ones. If you still need arguments, give the manager one of the most popular papers on Pair Programming — just reading the first pages should be enough. For the cost of approximately 15% increased development time, you gain fewer bugs, easier maintenance and higher developers satisfaction.

I work remotely and I cannot sit next to another developer

You don’t have to sit by one desk with another developer to do Pair Programming. Back in the days when I was working from the office, we always used videoconference (Teams, Slack, Zoom) — even if we were sitting 2 meters apart. The Driver shares the screen and talks to the Navigator about the solution. It is good to have two screens because one should always display shared code. You can also use solutions integrated within IDE, e.g. IDEA Code With Me.