Pair Programming

Naturally, every team needs to find their own rhythm in developing pairing workflows that suits their needs. These are a few practices, in no particular order, that I have found valuable:

Set an agenda

This doesn’t need to be a formal document by any means - even a simple checklist should suffice. The main purpose of this is to help you & your pairing partner align on what needs to be accomplished in the given timeframe and/or if there’s a stetch goal. Hopefully this conversation surfaces concerns that you need to watch out for along the way (e.g. will you be adding new dependencies, are there any security concerns, do you need help from design stakeholders etc).

Switch drivers regularly

This can be a planned timed interval (every 30mins, every couple hours) or it could just come up organically. The important thing is to be mindful of shifting gears so that each person can get a chance to flex their muscles and learn something along the way.

Seek to improve collaborative tooling; especially if remote

In my experience, when working remotely, the pair programming experience can be even more effective as compared to in person as long as you are equipped with the right tools! These are some of my favourite go to’s that work well when paired with an existing audio call

• Visual Studio Live Share Extension
• Atom Teletype

• Screenhero’s remote screen sharing in Slack was #1 for me but, sadly, it went away. These are a few reasonable alternatives

  • Tuple for remote screen control
  • Use Together for multiple cursor remote screen control

Share the ownership

Try to use “we” rather than “you” as a way to show solidarity in the pairing effort (e.g. “We should think about the problem a bit more before trying to come up with solutions.”). Little stuff like this can help prevent the person that is driving from feeling singled out and it shows that there is shared ownership around the success of the ticket/code/project.

In my most successfuly experiences, the decision-making process is also shared so that each contributer understands the weight & necessity of what needs to be done and how.

Share the glory!

After pairing with someone, try to attribute credit (where applicable) to them when sharing status updates with stakeholders. It may sound trivial and obvious but it goes a long way as a show of support and serves as a trust + confidence boost in your pairing partner.

Pay attention to physical + verbal cues

Be attentive to physical cues; if someone is faltering at the keyboard a lot or pausing a lot with verbal pauses then it could be a sign they are out of their comfort zone. They may be

1. Shy
2. Unsure about what to do next
3. May not know what the right syntax/details are to ask the right question even
4. Just need a break

Help them feel at ease by suggesting a break or saying something like

“If it works, I can help us get started with this”

or guide their hand indirectly (which will give them more confidence). For the latter case, you could say something like

“A best practice would be to start planning out the case class/XYZ/whatever - we can write mock code for it first to start feeling comfortable with the process.”

Basically try to empathize with their position in an effort to move forward together.

Patience, patience, patience

Let’s be honest. Sometimes pairing can be a real struggle - especially if you’re trying to solve a painful bug or working through a tough work dynamic. Be patient with one another and take a quick break if you need a breather to reset. For example, you can say

you need a cup of coffee

you want a moment alone to think through the problem/code/question at hand

you want to research the topic a bit more

and then come back to the code hopefully with a more relaxed attitude.

Written by Saima Jafri who's based in Boston & tries to build useful things.
About Me
Follow me on Twitter!