Further thoughts on pairing during software development! (Part 2)

While being a Lead/Senior Developer on several agile development teams, I’ve seen the ups and downs of pair programming. I’ve tried to introduce pairing into new teams with different levels of success - so I thought I’d write down some of the experiences I’ve had - and the potential was of working that can make pair programming less painful.

In August 2020 I wrote an article about Some thoughts on pairing during software development. Where I talked about :

• Pairing should not be forced. Processes, routines or schedules don’t work.
• Pairing works best when it is natural, encouraged but not mandatory

Now, a year and a half on (sorry I’m terrible at this blogging thing), and after changing jobs and a few teams in between - I thought I’d continue and write about some other points regarding pairing in Software Development.

To me, pairing while coding can be rather intensive, and can take real dedication and effort to keep on task. So here are some points on maintaining focus and optimising pair programming time!

Pairing works when both engineers are not multitasking

It sounds pretty straightforward. How can someone work on one piece of work, while also working on another? It’s hard to dedicate your full attention to one task if another is also taking your time and effort.

In reality, trying to dedicate your full attention to a task isn’t going to happen. You will often get distracted by a question from a colleague or an email notification taking your attention away. Let’s not forget the daily standups, tech meetings, and retrospectives - all diverting your full attention from the store/task you are working on.

Acknowledging that your concentration while pairing will not always be at its best, is the first step to pairing effectively. Knowing that both developers may be randomly interrupted by a Slack message or a phone call from someone is unavoidable. Knowing what to do when it happens is how to avoid it spoiling the velocity and focus on the task at hand.

You can’t stop interruptions

Just a side note before I begin - there is no way to stop interruptions or random events from taking your attention away from the task you are working on. Don’t try to stop interruptions - you’ll never succeed. A few years ago I worked for a company where I felt the majority of my day was being asked questions or interrupted by colleagues asking for help with their own tasks. I found that my own tasks were suffering and deadlines were starting to slip, so I attempted to cut out the interruptions (which may have involved hiding in meeting rooms, working in the kitchen, or trying to put processes in place). I spent far too much time trying to eliminate the interruptions than the time I was spending answering the questions/helping someone. Just take it as a compliment that your colleagues come to you when they need help!

Prioritise your pairing partner?

So, you happily pair programming away when someone walks up to your desk (if you’re physically back in the office) and ask if you have a ‘minute’ (why is it never a minute?). If you’re polite, you might be inclined to offer that help, which sadly means you are context switching and taking your attention away from the pair. This is where you need to prioritise your other pairing partner and put them first above other colleagues while you’re working on the same story/ticket. It’s not fair to your pairing partner or to the story/task as a whole if you suddenly drop your level of focus to context switch and work on another task.

I always try to say to the colleagues asking questions or causing the interruption if we could possibly arrange another time and ensure I keep my attention to the pairing task. Of course, be polite and say that you’re currently working on something with another developer and will get back to them as soon as possible.

Exceptions to this might be if a colleague is asking you a question about the current story/ticket you are pairing on - if that is the case, grab your original pairing partner are form a huddle (a session where more than two developers work on a task). You can always split back off after the question/problem has been resolved.

Ceremonies and meetings

If you work on an Agile team, you’ll be used to attending regular ‘meetings’ (sorry agile purists) such as Standups, Backlog Refinements, Planning, Retrospectives, etc. Hopefully, you and your pairing partner will have these similar ceremonies in your calendar - so can easily drop tools on your pairing story/task and attend them together. This is good practice to maintain attending these ceremonies, and resume pairing when you can.

Dealing with meetings that only one individual from the pair needs to attend is a little more challenging. Meetings like one-to-ones with Line Managers or Practice/Role meetings can distract the pair from the task at hand. I recommend you agree on what to do in these circumstances. I personally think it’s OK for the person that is not attending the meeting to continue working on the task, and then do a review of what has been done once the pairing resumes after the meeting.

One alternative is to ask yourself ‘Do I need to attend this meeting? Would it be more beneficial to continue pairing?’ - you can always consider rearranging the meeting for a better-suited time. This goes well with my first point - prioritise your pairing partner where possible.

Take regular breaks, coffee == code.

Schedule coffee and rest breaks throughout the day. Having time blocked out for a break from pairing helps to divide time into ‘We are pairing’ and ‘I’m going to respond to that important email’ sessions or just simply ‘I need a break, my brain needs a rest’.

Set a time limit on the break time - don’t say ‘Let’s have a break’ then not resume pairing until an hour later. Don’t leave the break time open-ended. On teams I’ve led or worked on, I’ve found if someone says ‘I need a coffee’ - we all agree to take a break, and resume in 10 minutes. It is then polite to make sure you are back and ready to resume at the set time. Don’t leave your pairing partner waiting around or continuing the work without you.

With that being said, don’t be scared to say you need a break! Pairing on a hard task can leave you feeling like your brain is fried. Regular five or ten-minute breathers can be very productive in solving that annoying problem you’ve been having with the Unit Test, NullPointerException, or .

Keep at it, rome wasn’t built in a day.

Good pairing won’t just happen overnight. It’ll take several weeks or months for developers to slip into the mode of ‘I’m going to take on this new story/task and find a pairing partner’ - without being persuaded or bribed (a scrum master once offered me biscuits in reward for pairing). As I said in my previous article, whatever you do - Don’t force it!

So if you’re planning to introduce pair programming, or are already on your journey, hopefully, there are some small takeaways from this article. Please leave a comment and let me know how pairing is going, or being done on your team - I always love to hear how other teams do it!

I plan to write about tooling/remote pairing in the next installment… Hopefully, this won’t take me a year and a half to write this time.