blog > Programming > Quick-start to Pair Programming. 3 Strategies For You.
Paweł Pluta
Senior Software Engineer
22 September 2021
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.
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.
Straight to the point, let’s look at the techniques!
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:
Cons:
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.
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.
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.
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.
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.
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.
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.
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.
Your email address will not be published. Required fields are marked *
Name
Email
Save my name, email, and website in this browser for the next time I comment.
tutorial message
Comment * CUSTOMIZED
15 December 2021
5min
Aleksandra Wiśniewska
IT is one of the most profitable sectors, employing hundreds of thousands of people in Poland, yet there is a constant shortage of... czytaj więcej
3 March 2022
13min
Marcin Grochulski
The IT sector is at high risk of burnout due to a high volume of tasks Mind Mapping is one of the ways to manage your working... czytaj więcej
10 November 2021
4min
Aleksandra Skibińska
JavaScript developer programs web applications Uses conditional statements, loops, or variables Learn more Learn... czytaj więcej
Contact
inquiry@edge1s.com
Headquarters:
Edge One Solutions Sp. z o.o.
14B Postępu St.
02-676 Warsaw