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

Quick-start to Pair Programming. 3 Strategies For You

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.

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

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.

  • 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.

  • 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
  • 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.

  • 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
  • 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.

  • Perfect for starting big and complex tasks
  • Can be used cross-team for explaining dependencies
  • Team building
  • 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.

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.

Paweł Pluta

Senior Software Engineer

Senior Software Engineer at Edge One Solutions, passionate about Unit Testing, Software Craftsmanship, new technology trends and Smart Homes.

Opublikowano: 22 September 2021