Skip to main content

https://gds.blog.gov.uk/2018/02/06/how-to-pair-program-effectively-in-6-steps/

How to pair program effectively in 6 steps

Posted by: , Posted on: - Categories: People and skills, Technology

GDS staff pair programming, looking at a screen together

GDS has used pair programming since its inception. It plays an important role in building our services. I recently gave a talk titled ‘How to be a good pair’ and the warm reception of the talk inspired me to share my observations in a blog post. This guide will be useful to people who have experience with pair programming or mob programming and to people totally new to it.

The benefits of pair programming

Before I go through my tips for successful pair programming, it’s useful to understand why this way of working is important. In the Digital Marketplace team, we use pair programming to write higher-quality code, but also to share knowledge and help with team building.

Communicating with and understanding the needs of your pair partner is just as important as the code you work on. These sentiments are echoed in a blog post by Taros Aires, a senior consultant developer at ThoughtWorks.

Below I take a look at 6 steps to keep in mind for more pleasant and effective pair programming sessions.

1. Prepare

To prepare for the session, take the following steps:

  • set aside time to do it – the amount of time you set aside will vary depending on your schedules (for example, the number of meetings you both attend), but I find that anything shorter than 2 hours feels constricted. Some of my favourite sessions have taken half a day, or even a (nearly) whole day (but please remember to take breaks!)
  • check in with your partner – ask them how they feel; are they still in the headspace to go ahead with the session? Maybe they need to go slower today or could use some emotional support? It is very helpful to know these things before you start
  • make a plan – before you start coding, talk about what you want to achieve during the session. Writing down objectives on post-it notes is a good way to plan your session
  • get comfortable – choose a space comfortable for both of you, preferably not too loud. Check if both of you can comfortably read the screen contents and that the code is up to date and working on both machines (if you use two computers)

2. Work closely together

When you’re pair programming, the usual set-up is for one of you to be the driver and the other to be the navigator.

The driver writes code, the navigator looks out for mistakes, ensures you’re both on track and calls a halt if necessary to rethink where you are, where you want to get to and how to get there.

It’s important to work together as a unit to make sure you get the best out of the session.

As the driver, it’s your job to talk your partner through each step when you code and make sure that your partner remains engaged. If you’re unsure, ask them to paraphrase what is happening to ensure they do understand.

As a navigator, make sure you stay engaged and actively participate in the session. Keep up the discussion with your pair partner and make sure that you are both:

  • following the plan
  • writing the code test-first as per Test Driven Development (TDD) principles, if relevant
  • cross-referencing with the story ticket when necessary

Your ways of working may change depending on who your partner is and that's ok.

3. Learn and facilitate learning

Things to pay attention to if you’re more experienced than your pair

If you’re pairing with a programmer who is junior to you or knows less about the particular problem you're working on, be mindful that this is an opportunity for you to help them develop their skills.

Let your pair navigate you towards the solution and encourage them to ask questions. Be patient. If you work too quickly, your junior partner may miss out on learning opportunities. If you feel that your pair partner needs some encouragement, you can provide it by asking open questions like: ‘What shall we do next?’ or ‘How would you solve this?’

Remember that you can also learn something. Junior programmers often come with fresh ideas as they are not set in specific ways of thinking.

Things to pay attention to if you’re less experienced than your pair

If you are pairing with a more experienced programmer, ask questions whenever you don’t understand something. Pair programming is a great way to learn on the job and get to grips with concepts that are new or difficult.

Be patient with yourself. You are here to work, but you’re also here to learn. Pay attention to how your pair partner approaches the problem, note the new tricks and elegant patterns/solutions to problems to remember them better.

Whatever your seniority is, remember that some of our needs remain the same regardless of our relative experience, as per the slide below, taken from a presentation by a software developer, Irina Tsyganok:

a slide showing that our needs remain the same regardless of your relative experience

4. Establish a rhythm

Change driver/navigator seats a lot, preferably every 15-30 minutes to maintain optimum levels of energy and concentration. Committing changes frequently will help you maintain this rhythm and also ensure that you stay on track: writing a commit message helps you to verbalise what you just did and to reflect if this was a step in the right direction. If you want, you can always squash the excessive commits later on.

Test Driven Development (TDD) and pairing work well together. If one person solves the problem described by a failing test and writes the following test, and then there is a role change, you can maintain a pleasant rhythm.

Celebrate each small success (this can be as small as finishing one small task), whether with a high five, a tea break (resting your eyes and stretching is important!), whatever works for you. You just made something work, yay!

Again, don’t forget to take breaks. Take one whenever you need it: after a completed task is fine, but if you feel worked up or stressed, do not wait until task completion.

At the end of the session, go through your commits together and discuss what has been done and what should be done next. This may involve using the story ticket as a reference point.

You may find it useful to jot down a few notes about the session. This makes handovers easier and may be useful when you’re summarising last day’s work during a stand-up.

5. Communicate effectively

Let your pair know if you feel you don’t understand something or you feel disengaged, pressured or pushed prematurely into a solution.

Use gentle language. You might want to talk it through at the beginning, so it feels less like a criticism and more like feedback you're both prepared to receive.

This can be awkward but it’s definitely worth doing. You could, for example, say:

If, at any time, you feel left out or lost, or you need me to do anything differently, please let me know. I value your experience, and if you don’t mind, I will do the same.

This is also important in mob programming, where you drive for a smaller part of overall time than in pair programming.

When pointing out a typo or a mistake, wait until your partner finishes writing a line. No one likes to be interrupted.

At the same time, remember that effective communication is also about observing and listening to your pair partner. Read your pair’s body language to see if they're comfortable. This becomes easier once you’ve worked with somebody for a while. If you think your pair is uncomfortable, propose a walk to the water cooler together, and ask if they need a break or would rather do something differently.

Make space for them to converse, to share with you, to give you feedback. And remember you are both humans, and thrive when presented with empathy and kindness. So be empathetic, be kind.

6. Embrace challenges

We may know all about pair programming, and it can still get out of hand. Human relationships are complex, code is sometimes complicated and there are times when it doesn’t lend itself to pairing quite as smoothly as we wish it would. And that’s fine. Things don’t need to be perfect all the time. Actually, it is often when they're not that we learn the most.

Treat those trying moments as an opportunity to do a small retro. What went wrong? What went right? Are there any actions you can take to avoid it in the future?

Summary

I hope these handy tips and tools will enhance your pair programming experience. If the amount of information seems like a lot to take in, you may want to choose one point you find most helpful and concentrate on it during your next pair programming session.

Let us know how it goes in the comments below. Most importantly, enjoy yourself and the exciting adventure of creativity and problem solving you embark on with your pair partner.

Follow GDS on Twitter.

Sharing and comments

Share this page