Humans are social animals, a fact we are reminded of daily as we hunker down in our socially distant cocoons due to the COVID-19 crisis, while we are forced to share zoom drinks and virtual birthdays with friends and family, desperate to stay connected.
We all sit somewhere on a spectrum of sociability - whether you’re an introvert perfectly happy in your own company, or an extroverted social butterfly constantly in communication with swathes of people by a myriad of media. Everyone needs interactions with other people, be it for energy, motivation, support, information, reassurance. So why would developing software be any different when humans are going about it?
For anyone who has ever developed a software application of any sort, I put this question to you: what do you spend most of your time doing? Is it typing reams of code like you see in Hollywood depictions of hackers or programming virtuosos? I expect that the answer is no. Most of my time is spent debugging things, reading code that either someone else wrote, or that I wrote more than 5 minutes ago and trying to understand what it is supposed to do and how that differs from what is actually happening. I also spend a lot of time reading about new technologies, frameworks, or language features and trying to work out if this would be a sensible tool to use to build whatever I’m working on. In my opinion these tasks can all be done better in pairs or groups. The extent to which this happens depends on the task: having two people huddled around the same screen reading the documentation for a javascript library is not the best use of anyone’s time. Sometimes judiciously choosing to split up to deep dive into something - like reading docs or investigating an approach - and then getting together to discuss findings, is more fruitful than simply conducting research and making decisions alone.
Let’s say you want to build an app that sends you an alert when a tweet mentions a drug that you’re interested in. You can break the problem down into sections that you will need to do, for example, poll all tweets -> get a list of individual words from these -> compare words to the user input term of interest. While every action in this list is necessary, the order, method and way in which everything fits together are all complex decisions that need consideration. Working alone, these considerations will happen internally, then you make a decision based on a number of influences many of which are subconscious and not related to logic or reason. When working in pairs, reasoning over these decisions involves an external conversation which combines the knowledge, skill, attention, background and subconscious bias of two individuals. These decisions will need to be based on a shared understanding which 9 times out of 10 will be more comprehensive than the understanding achieved by internal solo reasoning.
A typical day of pair style development will involve the identification of an important task at standup, two people stating that they are interested in this, and that they are sufficiently civil to work together. They then discuss the problem that needs to be solved, gather information where necessary, and identify a set of tasks. Setting about these tasks, the pair needs to agree on a driver (person operating keyboard and mouse) and a navigator (person performing other tasks like investigating locations of data, organising and documenting ideas, thinking of the potential issues of any decision). Particular individuals should not take the same roles repeatedly, this is an example of a pairing antipattern, driving and navigating are tasks that are draining in different ways, changing roles can prevent fatigue.
While pairing has many clear benefits, it’s not always easy, and there are a number of things that are simply unavoidable parts of the practice: pairing will appear to slow you down and you will not go through tasks as quickly as you would individually. In actuality, however, the time taken to reason and make decisions as a pair will mean that knowledge is distributed better between the team and that it’s much more likely that the right problem has been solved in the right way. If you consider the time that would have been spent explaining your work to a teammate after working alone, and then coming back to edit your work post feedback, working in a pair can certainly save time.
While pairing can be draining, as externalising everything is exhausting, I tend to be more satisfied that we produced the best work that we could have, I’m sure that the oxytocin that is released in our bodies as a result of bonding helps with this satisfaction. No pair is the same, you need to learn how to work with any different individual, some people are happy to huddle around the same screen for many tasks, some want to split up regularly, some like driving all the time, some are happy to navigate. It differs from person to person, it takes effort to create the flexibility for everyone to do their best work, but it’s a worthwhile endeavor. There are some antipatterns that are worth mentioning, e.g. switching drivers (mentioned above), or navigators constantly pointing out every typo and small mistake can make the driver feel under pressure and end up creating more problems.
Our team has started pairing remotely recently, screen-sharing tools like Tuple, google hangouts, and slack have proven effective. We have found that we can be effective at solving problems together and having fruitful discussions. Ultimately working in this kind of collaborative way makes a team feel like it’s working toward the same goal. We share commitments and responsibilities, and lean on our teammates for help and support. This is essential when creating a team that is as effective as it can be.
Back to blog post and videos
