The human side of remote pairing
I volunteered to collate some tips of best practice for remote pairing for my team, because it is hard, and we are always looking for ways to make this pretty draining activity easier on the team, so we can continue to deliver quality and also deliver ourselves sane minds at the end of each day. Lots of posts I read focussed on the technical side of pairing (tmux vs VS Code live share etc), but in my experience it’s the human side of making pairing work that’s harder to perfect. Here are a few points that I thought were really valuable. The italicized parts are from the articles cited, and the comments are mine.
🧶 Don’t do other stuff! (except crocheting)
Pair programming is about the synergy of collaboration, not about just sharing space and time. Don’t be tempted by unrelated tasks, even mechanical, when listening to the partner.
https://www.atlassian.com/blog/technology/remote-pair-programming-tools-process
It is so easy to check Slack, pick up your phone, respond to emails while pairing and lose the thread. Find a way to ensure you don’t do this. I crochet when not typing because it helps me focus on what my partner is doing. Either learn to crocket or find out what that activity is for you that has the same effect.
💬 Keep checking in intentionally on your partner
While remote pairing, inquire often and intentionally about how the other person is doing and whether they have questions, especially if there is a senior/junior dynamic, such as the onboarding of a new team member. Be sure to check their engagement level and encourage them to turn on their video if they haven’t.
https://jaxenter.com/pair-programming-working-from-home-171734.html
Turning on video isn’t for everyone but if it helps engagement, then go for it. Keep making sure your partner is on board, if they don’t understand what you’re doing, explain it to them. Externalize your thoughts because it will take your partner on your journey, and almost certainly help to clarify them for yourself.
🤝 Don’t forget to pair as equals
When a more senior engineer is driving, they need to be careful not to just start coding without getting their partner’s input, Wenholz said. If the senior engineer is acting as the navigator, they need to remember not to just tell the junior driver what to do.
Remember that it’s a partnership. More junior engineers will only learn so much from someone telling them exactly what to type. Let them fill in the blanks so they can sue and consolidate their own skills.
👨👩👧👧 Keep the team in sync with regular check-ins
“We just talk about what did we do yesterday, what are we working on today, how do the boards look, and who’s gonna pair up in the next session and what are they gonna work on?”.
A very brief meeting at the beginning or end of a day between multiple pairs working on the same project or feature can help to clear up misunderstandings, eliminate false assumptions, and help keep work moving forward. Your pair might have been struggling on something that a different pair of eyes will have a solution for very quickly.
🛠 Don’t immediately pick out errors
Apply the “5 seconds rule”: When the navigator sees the driver do something “wrong” and wants to comment, wait at least 5 seconds before you say something - the driver might already have it in mind, then you are needlessly interrupting their flow. Wait a bit for the driver to correct or write a sticky note to remember later.
https://martinfowler.com/articles/on-pair-programming.html
It can be annoying or unhelpful, or interrupting you point out a typo as soon as your pair has seen it. They may well have seen it, and are about to sort it out. Take a breath and give them a second before jumping to tell them they’ve done something wrong.
🚫 Carve out periods of uninterrupted coding time
One approach is to limit the time slots in which meetings happen, for example by defining core pairing hours without meetings, or by blocking out no-meeting-times with rules like “no meetings after noon”.
https://martinfowler.com/articles/on-pair-programming.html
(some) Meetings are necessary but batching them together allows for hours more coding flow time. The context switching of moving betwen different coding tasks is nothing compared to the overhead of going to a meeting and all members of a pair or mob having to get their head back into the problem they had to put aside to go back to the meeting.
🗓 Coordinate at the start of the day when your pairs are available
There will always be meetings. So how to deal with that as a pair? Check your calendars together at the beginning of your pairing session, make sure you have enough time to start pairing at all. If you have any meetings consider attending them as a pair. Rely on non-pairing team members, to keep interruptions away from the team in the core pairing hours.
https://martinfowler.com/articles/on-pair-programming.html
A useful strategy for our team has been looking at our calendars at the beginning of the day and saying “ok we’re all free 10-11, then I have to go off for an hour so X and Y can work together til lunch” etc. Knowing at the start of the day when group coding is planned helps team members work out where to fit in otther way and when they can get stuck into collabortion.
🧓 Don’t automatically acquiesce
If your pair has more experience on the topic: Don’t assume they know best. Maybe the need to explain why they are doing things the way they are will bring them new insights. Asking questions on the how and why can lead to fruitful discussions and better solutions.
https://martinfowler.com/articles/on-pair-programming.html
So many times I’ve gone along with a senior engineers strategy because I assume they have more expereicne than me, so whenever we see something differently I’ll be wrong and they’ll be right. It’s much better to throw this out of the window - aside from anything else, questioning coding decisions will weed out assumptions and lead to more thought going into choices.
🩹 Lead with vulnerability
Being vulnerable is easier and less risky for people on the team who have more authority, either naturally (e.g. because they are well-respected already), or institutionally (e.g. because they have a title like “Tech Lead”). So it’s important that those people start and role model this, making it the norm and therefore safer for others to be vulnerable as well.
https://martinfowler.com/articles/on-pair-programming.html
Make sure that if you’re in a position of power, you articulate when you don’t know something, or you’re find the day tiring, or that a piece of work is difficult. Being honest like this builds psychological safety, and helps build a team culture of honesty and unimpeded communication.
☕️ Coding - but make it social
One of the best things about pair programming is that it’s social. If its someone you don’t know, its a great opportunity to find out about them. If it’s one of your closer teammates, it’s a great time to catch up a little.
https://johndobie.com/blog/tips-for-remote-pair-programming
I always ask people stuff like what they’ve had for lunch, or what they’re doing in the evenings, or other fairly trivial questions. Especially in a remote world, where we’re often working with people we’ve never met, there are no group lunches or trips to the pub where we get to know our colleagues. Using lulls while tests are running, or Jenkins is doing his thing to have chit chat helps getting to know teammates, and this builds stronger bonds and trust.