Remote Pairing – Do’s and Don’ts

Anwesha Chatterjee

Anwesha Chatterjee

A bit of a developer. A bit of a hippie.

It’s been over a year since I joined Cogent, and I’ve been reminiscing about all the projects I’ve had the good fortune of being part of. This got me thinking quite a bit about what makes a good pairing experience.

Whilst pairing has been a fairly consistent part of my recent years as a software developer, Cogent was where I first started remote pairing. The remote aspect of the experience amplifies certain challenges. Having been through a few different engagements, I’ve seen pairing done many different ways so in this post I’d like to share what I’ve learnt from my experience.

Here are four key points that cover common pairing challenges alongside suggestions on how to best address them – both from the point of view of a team lead, and a proactive member of the team.

1. Jumping into pairing when it’s not the best tool for the job.

It’s common for people (including me) to want to jump into a problem and “get their hands dirty” when, in reality, the best thing to do is take a minute to really think about the task at hand.

What context is needed for the task?

What are our goals?

Pairing isn’t always the best way to answer questions. Rather than an all or nothing approach, working solo and then regrouping once we’ve independently explored the context and potential high-level solutions, helps bridge gaps in communication. The key to doing this successfully is to have clear agreement about when to regroup, and a shared understanding of what specific questions need to be answered, or what context needs to be explored. 

I’ve found using tools like Excalidraw for the visual representation of my understanding of the relevant context to be of immense help. Being a very visual learner and communicator, the lack of whiteboarding is a big drawback of remote pairing. This tool helped smooth out a lot of my discomfort around trying to get my point of view through to my pair. 

2. A mismatch of power dynamics

Many subtle power dynamics can affect the quality of pairing. The most obvious of these is when there are two people with different levels of experience pairing on one card. It can often be tempting for the more senior person (who is also often the one with more context) to take over and drive. Additionally, when it’s the turn of the more junior to drive, too much direction from the senior person creates an environment where the junior developer does not feel psychologically safe. The junior developer may feel uncomfortable and scared to make mistakes when the truth is that it is through making mistakes that we learn the fastest.

While it may seem counterintuitive to go as fast as the slowest member in the pair, it is what ultimately creates the right environment to help junior folks flourish in a new project. The goal is to hand over bits and pieces of the driving until both members of the pair feel confident.

I’d also like to talk about the experimental or discovery phase when embarking on new areas of work – known as spikes.

Some teams may fall into a pattern of having one developer (often the one with most of the context) complete most of the larger spikes on their own. Pressure around delivery deadlines may be a reason behind this pattern. It’s important to acknowledge that the solo warrior culture can subconsciously foster an environment where there is siloed knowledge. This means team members who are new to the project may have a longer and more uncomfortable journey in getting up to speed with the project. In cases where there is absolutely no room to pair on these more complex tasks, it would be good to ensure that the understanding gained from the spike is shared with the team in some format. This can be done through a tech huddle – or a document outlining the goal of the spike and an analysis of the explored solutions.

Finally, it may not be everyone’s preference to pair all the time, even if they are more senior and have most of the context. If that is the case, frequent and clear communication regarding expectation setting is paramount to ensure a healthy and supportive environment in your team. In an industry where impostor syndrome is so widely present, a junior person is probably less likely to admit they are struggling if they are new to a project.

3. Not factoring in sufficient breaks

One of the most common complaints I hear about remote pairing is that it causes burnout. I have found this to be the case when my teammate and I are not intentional about taking breaks during pairing sessions. There seem to be fewer natural breaks to the flow of remote pairing sessions; it’s easy to keep working for multiple hours at a stretch, and then wonder at the end of the day why we’re both so incredibly fatigued. 

It can take a lot more energy to stay focused on pairing through screens than it does in real life. This may partly be attributed to the lack of the body language cues we normally would have when pairing in person. To make up for that we subconsciously exert a lot more energy into deciphering subtle responses from our coding partner. 

There are several tools such as Pomofocus that can help with setting up reminders to take a break using the Pomodoro technique. It can also be good to take intentional short tea/coffee breaks with our colleagues – during which we stay mindful that we keep the conversation off the topic of whatever problem we’re trying to solve. 

We occasionally split from our pair and work solo – perhaps while one person has a meeting to attend. This can help remove a bit of the “zoom fatigue” that comes with remote pairing.

While it can seem tempting to power through and complete work, rituals that help us pace ourselves and make sure we don’t burn out help to create a healthy environment conducive to a consistent flow of output. Besides, we all know that it’s often when we aren’t thinking about a complex problem that a solution often pops up.

Even when pairing remotely, it’s still vital to take breaks and make sure there’s enough downtime for creative thinking.

4. We focus too much on work

Remote working doesn’t give us as many natural opportunities for casual chats with our colleagues. We have less context about how our team is feeling outside of the frame of reference of work. This disconnection can be a barrier that makes collaboration much harder.

This is where team bonding rituals and scheduled intentional water cooler chats become really important. We connect better as humans when we can be vulnerable. Opening up to each other about our emotional state of mind can help with expectation setting, which in turn makes us work together more efficiently.

While it may seem contrived to mandate ‘downtime’ with colleagues, I have personally seen plenty of benefits for remote teams so I recommend scheduling in time and staying accountable for these rituals.

One-on-one time is also very important. While group social settings are great for light-hearted chit chat, one-on-ones- especially with team leads and managers – make sure that there’s space for deeper conversations. These dedicated sessions encourage a good flow of communication and have personally helped me open up about struggles that I wouldn’t have felt comfortable sharing in a large group setting.

I’ve personally had a lot more fun in a team environment where the leads make time for small fun rituals as well as space for personal discussion.

Finally, while some of the issues I’ve mentioned are cultural and have been around for a while, some can also be circumstantial. Yes, the remote nature of our work has amplified some of the existing challenges around pairing, but with intentional communication and action, we can bring about a shift in the culture and continuously learn how to work better as a remote team.

Liked this post? Share it on…

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn

Related posts

Tech
Erin Zimmer

CSS Layout: Normal Flow

It’s worth understanding normal CSS flow, what it’s good for, and why it makes it so hard to centre things vertically. In order to do that though, there are three main concepts that we need to understand – block elements, inline elements, and line boxes.

Read More
Tech
Paula Feleggakis

The importance of learning to read code

Felienne Hermans recently gave a marvellous talk which relieved one of my lingering insecurities almost immediately – she told me that it was OK to spend time reading code, and that it was in fact a necessary precursor to being able to write code effectively.

Read More
Tech
Navin Keswani

Data Engineering Principles

I’ve recently joined Cogent as a Lead Developer and before that, I worked on Data related systems as a Data Engineer and as an Architect. I’d like to bring some of the knowledge and experience from these domains to the Cogent community and so I thought that cross posting this article (that also appears on my personal blog), would be a good way to start.

Read More