We all know the benefits of pair programming and mob programming: this idea that two pairs of eyes can see better than a single pair, being able to both think in the details while keeping in mind the high-level overview and next steps of the task. This approach can provide more focus to the session and give feedback early (that otherwise could be delayed until some code review process). That's why some folks want to do it all the time, while others prefer to do it a percentage of their time and have it as a tool they can choose to use whenever they want. I personally enjoy pairing, although I think there are times when pairing is not going to add the extra value we're looking for.
Not in the mood
It is good to be aware of our feelings and not put them aside to force a pairing session that can be unproductive or uncomfortable. Many things can cause a pairing session to end up like that: being tired (we all had nights of bad sleep); frustrated or just with your mind on another important topic (maybe you are waiting for an important email or phone call, or you are dealing with issues outside of work).
To me, saying things like "I'm not in the mood for pairing today, could we make it tomorrow?" demonstrate high levels of emotional intelligence in a team. Individuals and interactions over processes and tools.
In a chaotic thinking process
Some people's minds have creative moments that are hard to pair with someone else's mind. I feel very identified with that trait. I could be very chaotic when coding a new solution or exploring a problem. It's even hard for me to explain what I'm doing.
In that case, a pairing session can be more productive after you sort out some of your ideas and you have a more solid plan.
Another option would be to invite people knowing that we're in this process that might be chaotic. If the other person is fine with this, we're good to go! Also, have in mind that other people can help you when you need some rubber duck to clarify some ideas by going through them.
Sometimes, there is no value added by having a second person working with you on a solution. I'm thinking of scenarios like:
- Clear steps towards the completion of the task: there is nothing to discover, from both the technical and business point of view.
- The work to do is repetitive: things like copy changes or settings in configuration files; there is no extra thinking behind the change. There is an exception for this: it might be worth pairing it if you want to teach other people to do it.
- There are no important architectural or design discussions involved: we're following a pattern, or we are making changes that we know won’t impact other things.
Scattered time slots
Person A - do you want to pair on #12345 today?
Person B - sure! I'll be available in one hour
Person A - oh! I'll be at a meeting by that time 😞 What about after lunch?
Person B - I have 30 minutes, then I meet with our PM to discuss the next project
Person A - …
Person B - ...
This is quite often, particularly for people with busy agendas. Pairing works better, in my experience, with blocks greater than 30 minutes, when we could reach a flow state and have a decent time to produce a deliverable.
To avoid this issue, if you know you have meetings across the day, try at least to block time slots (I recommend two hours) so you can be available to pair with your team. If you know there will be a lot of context switches in a session, maybe it's better to say no and reschedule. Pairing requires both people to be with their 100% attention.
¿What do you think about pairing? ¿Do you know other reasons for not to pair?