This is an excerpt from the Makers guidance for students. It has been slightly adjusted for a public audience.
Why pair?
Pairing is a very powerful practice for software engineers. There are two reasons:
Firstly, two people almost always know more than one and can solve problems more effectively than one, provided they know how to use each other’s minds effectively.
Secondly, if you work solo and you are good at it, you will quickly become the expert on what you have done. People will come to you to ask questions, slowing both of you down. Pairing ensures at least two people know everything.
I have seen very capable engineers burn out due to the last one — be warned!
Why use a structure?
Pair programming is an unusual activity for a lot of people. Many of us don’t often spend a long time working with one other person on the same task, particularly when that task is complex.
It is also a social activity, so all of our pre-loaded social frictions come with it. Without some structure, you’re essentially letting whatever social dynamics exist between you run the programming session. This probably isn’t a good idea. It can get frustrating.
Having some structure ensures that you have both agreed how you would like to work together. If one of you then finds it isn’t working for them, you’ve already given yourselves the tools to fix it. If you are worried that the other person isn’t having a good time, you will know that they have the opportunity to discuss it and change it.
Don’t think so? Then just keep doing what you’re doing! If it works, great. If it doesn’t, this text will be waiting for you if you need it.
Let’s get started.
How do I pair?
These steps are a short guide on how to pair.
Step 1: Get to know each other
If you’ve not worked together recently, ask each other in turn:
- How do you feel about pairing?
- What have your experiences in the past been like?
If you have worked together recently then move on to the next step.
Step 2: Decide what to do
Decide on your task or objective.
If your goal is to produce some software, discuss what the task is and what is realistic to get done in this session.
If your goal is to learn, discuss what your respective learning objectives are and what tasks you will use to achieve those objectives. Your learning objectives can be vague or precise, but your task should be clearly defined.
Be aware of any gaps in technical confidence. If one of you is still learning the basics of Javascript and the other one wants to learn a sophisticated framework — one of you might get overwhelmed while the other feels bored. Not much fun!
Step 3: Agree your approach
Here is a suggested approach for pairing:
Driver-navigator pairing involves you both working on the same thing but with two separate roles.
The Navigator provides instructions to the Driver. They are responsible for managing the process of programming, the goal, the plan, and what is in or out of scope at this moment. They generally shouldn’t be typing or looking anything up.
The Driver takes instruction and writes code. They are responsible for asking any questions they need to understand what they need to do, and looking anything up that the pair needs to know. They should propose things to do where they have an idea, but the navigator makes the decision. They generally shouldn’t take action without the navigator’s instruction.
They are both responsible for delivering quality work, for understanding what they are doing, communicating their thoughts, sharing their knowledge, generating potential solutions, and being considerate of each other.
This approach is designed to build shared understanding and joint attention with full engagement of both partners on the same task.
As you gain experience pairing, you can be more flexible on the principles above, so long as you are still building shared understanding and joint attention.
You can adapt it to what you each prefer, based on open conversation about how you would like to work. However, you should almost always still prioritise shared understanding and joint attention with full engagement of both partners on the same task.
Step 4: Agree your rhythm
It is vital to take breaks and swap roles regularly. Pairing is demanding and if you don’t take breaks you are likely to overdo it!
Here is a suggested cycle:
- Pick someone to drive or navigate at the start.
- The navigator will set a timer for 25 minutes.
- Pair-program until the timer goes off.
- Take a 5 minute break.
- Swap driver-navigator roles and return to step 2.
If you have previously worked well together and are in the zone, it’s OK to up your phase time from 25m to perhaps 45m. Watch out for fatigue and frustration.
Some of these cycles might not involve much or any programming. Sometimes you’ll just be talking things through. That’s OK!
Step 5: Pair!
Feel free to take longer breaks, especially if one of you gets confused or stressed.
Step 6: Reflect
At the end of the day, ask each other:
- On a scale of 1-10, how much did you understand what we did today?
- On a scale of 1-10, how engaged did you feel in our work today?
You can then have a short discussion about why. It doesn’t need to be perfect every time, everyone has bad pairing sessions.
A professional example
If you’re studying at Makers there is an example here of two engineers pairing on a real-world task. But it’s not public, sorry! The takeaways are:
- The engineers spend some time setting up the session and getting to know how each other works.
- Neither of them are perfect pairs. There are moments of confusion and misalignment.
- They put a lot of time into communication, building shared understanding of the system and joint attention on the task.
Cover photo by John Schnobrich on Unsplash
If you liked this, perhaps you will like other things I make. Like my newsletter K.log, or my tweets at @neoeno, or my website — you're on it right now!