By nature, the stereotype of a software developer is of an introvert, who likes to work alone. We know in theory that pairing and collaboration are powerful techniques, but in practice many developers can be hesitant or even resist, and I think this is often because they simply aren’t sure how to get the most from it. Like anything that is unfamiliar, practice is a good way to improve. Personally I’ve found that most of the big gains in my career have come from pairing, and I think that’s because I’ve gone into it with an open mind and a desire to learn from others; this is how I learnt to do things like do TDD properly, the subtleties of SOLID, it’s also one of the best ways to onboard a new starter – both in terms of getting them up to speed with a new project and giving them a “buddy” in the team, and some of the most elegant and fun to implement solutions I’ve seen have come from pairing.
One of the challenges of pairing is that it places a heavy demand on soft skills, that can often go undeveloped. Pairing is all about constant communication, and about empathy and being open to ideas. While working in a pair, both partners need to respect the other, and explain their thoughts. To people who think in particularly abstract ways, and perhaps aren’t fully aware of how they think because it happens automatically, the act of talking about their process can be uncomfortable at first but very enlightening. A metaphor I like is that of “driver/navigator”; one of the pair takes responsibility for “driving”, that is they actually control the keyboard and the fine detail, while the other “navigates” by helping the driver when it’s actually helpful and by keeping an eye on the bigger picture. To all-action types, who enjoy working alone, the navigator role can be less appealing, but it gives an opportunity to step back from the trivia of syntax and mechanical operations, and think about things like elegant solutions, how pieces fit together, and a route from start to finish. The navigator must resist the temptation to get too involved and especially to not tell the driver exactly what to do – imagine driving with someone who tells you “change up a gear… change down a gear” – don’t be that person! However, a really useful thing for a navigator to do is to act as a spotter for more subtle typos or similar errors, and to point these out respectfully. It’s both pairers’ responsibility to make sure that the partner is always as comfortable as possible and show empathy.
Something that always amazes me when I pair is how everyone I work with has their own individual styles, and their own individual toolbox of productivity tricks. Maybe someone is using a cool IDE extension, or has an unusual but effective debugging technique. Ask about it! If you take the best of each of your team’s habits and combine them with your own, it can be really powerful. It’s also a low-hanging fruit as a shared interest, as the odds are the people you work with will face similar challenges, and may have found nice ways to solve them. Equally sometimes you’ll pair with someone who is much less familiar with the tooling and has a weaker arsenal of tricks. Whatever you do, be respectful and don’t do things that would put them off; and try to let them take the driver role as much as possible. In the navigator role you’ll be able to see opportunities to gently introduce them to new tricks that they may choose to adopt for themselves. I remember the first time I paired with someone who was using a continuous test runner, and being stunned by how productive it let them – and me – become.
A simple thing that makes a big difference to how effective a pair can be is their environment. Obviously, having 2 people at a single desk means needing to make room for each other. Make sure the desk is a pleasant place to be – not a cluttered mess, with leftover food or cold coffees everywhere! Make a point of making sure the other person can see your screen, and comfortably see what’s going on. I personally have my fonts enlarged all the time, out of my own preference; I like to size my fonts so that about 30 lines fit on screen at any time, so that methods that are too long are even more obvious when I have to scroll to read them and it annoys me(!), and I’m often using my laptop to present or do demos to teams. If you’re into quirky hardware, make sure there is a more comfortable option available, for example I use a trackball mouse, which often scares people, so we make sure there is a conventional mouse available. Sometimes I go so far as to plug in a second set of keyboard/mouse, so that we can switch roles more seamlessly and hence more often. For prolonged pairing sessions, I’ve known people to book a meeting room or use some other separate space, which can be a welcome change. Don’t forget that it’s not just about the pair, and that the constant communication that helps the pair might be a real nuisance for those around them!
In a cross-functional team, where the team members can have very different backgrounds and skills, pairing can be even more effective. In these environments, I try to encourage anyone who is curious about what someone else does to ask to pair on a suitable piece of work. The goal here isn’t necessarily to seek mastery of a new area – although that can happen, and it’s great when it does – but to gain an understanding. It can also be really interesting to see the interface between different specialisms from the other side. One example I remember really vividly is pairing (as a server-side specialist) with a client-side developer. He had had frustrations in trying to work with some of the team before, because he often had a non-functional API to develop against until relatively late in the story’s life cycle, because people would take longer to implement the supporting functionality. Together we explored techniques that both parties could apply to help each other – some of the things we came up with were that we designed the API and interface collaboratively, and before either party started implementing; we would then pair to stand up a stubbed API as quickly as possible that he could tweak to trigger the behaviors he was interested in, and then we could work in parallel, catching up every couple of hours to check in and see whether we need any changes to the API. We formed a very strong partnership off the back of this cross-discipline pairing, and arranged to work together more often – knocking features out of the park!
Another particularly potent cross-discipline pair can be a testing specialist or quality analyst pairing with a developer; the QA is usually great at thinking of corner cases and encouraging a disciplined and thorough approach, while the developer will normally have a deeper understanding of how the system really works and can show the QA what is going on under the hood – which feeds back into the QA’s curious mindset and inspires whole new ways of thinking about ways to test the robustness and quality of the system. It’s also a great way to break down the outdated and dysfunctional “lob it over the wall” mentality that still plagues some teams as a leftover from waterfall development/testing phases, and get everyone pulling in the same direction instead of blame games and the other silliness that can come from an adversarial relationship between testers and developers when neither understands the other’s specialism.
If your team don’t already leverage the benefits of pairing, why not give it a try, the results might be surprising! Remember that it is a skill in its own right, that might not come easily to everyone, but that can be very powerful in the right context. Practice pairing with different people, to get the widest exposure to different ways of thinking, but if a pair have a particularly strong synergy then why not make the most of that.