Pairing - Not Just for Writing Code!
Pairing is a powerful collaboration tool, and it's not just for writing code. It's a powerful asset in any stage of the software development lifecycle.
When talking to folks on my team I noticed that I would use the term pairing a lot, and recently learned that while I meant that as "collaborate more, including on writing code if needed". And what was heard was "sit in the same room in Google Meet, one person working, the other one staring at you or zoning out".
What is Pairing?
Obviously this isn't what I meant. But realizing this exposed a gap. Pairing isn't just, or even primarily, for use with writing code. It's collaboration. Pairing is when two individuals work together on a given software development task, at any point in the software development lifecycle. This explicitly includes tasks outside of coding. You can and ought to pair specify, spec review, debug, and code review.
Pairing isn't just for use with writing code. It's collaboration. It's two individuals working together on a given software development task, at any point in the software development lifecycle. This explicitly includes tasks outside of coding.
In fact, pair spiking, while difficult, can be the most useful kind of pairing. Being able to explore a problem space jointly taking time to tell your pair that you're going to go checkout some docs to get a better handle on the problem, while they comb through forums or blog posts for ideas on how to handle a problem allows you to cover more ground, and avoid toe stepping or redundancy. Doing this in the same space, physical or virtual, allows you to actively communicate relevant learning as you go. You'll also likely be able to quickly share points that allow you both to jointly course correct more quickly than you would as individuals.
Why Pair
Because often breaking into totally individualized tasks while the most efficient use of resources for the organization isn’t the most effective use of resources for the organization, or individuals on the team, especially prior to really deeply understanding the problem space, and solution that will be implemented.
Typing isn’t usually the bottleneck to driving value as a software engineer. If you believe it’s the bottleneck for you I’d recommend taking one of the many, many online typing courses. That’s an easy fix.
Thought, quality of code, and quality of solutions are more often found to be the bottlenecks in software engineering. Pairing allows for built in increased quality, knowledge transfer, and training while actively delivering value, all of which move the organization forward.
As well, pairing is the only way you're going to be able to grow your own talent in your organization, which is probably the best way forward for the majority of technology organizations at the moment, given the difficulties in hiring.
Tips for Successful Pairing
Keep communicating - Especially as the driver, when coding. This is especially critical in mobbing as the navigators may be tackling other problems and documentation exploration concurrently, and you want to avoid duplication of effort. Without talking while coding as the driver you aren’t going to allow the navigator to keep up with where you are, to be able to guide, or allow you to keep in the zone.
Take breaks - Done properly pairing/mobbing can be mentally and emotionally exhausting, especially if you’re not used to it. Start with enforced 25 minute sessions with 5 minute sessions stepping away from working collectively on the task at hand.
Set a timer - Doing the above without a timer is difficult. Luckily you can set a timer on your phone, browser, or probably an in editor extension.
Ask to swap - If you find yourself drifting away, wanting to check your email or messenger, ask your partner to swap into the driver's seat. It allows you to re-engage, or assess if this is an activity that you ought to be pairing on, or if it's sufficiently well defined.
I'd love to hear about what stops you from collaborating more? Send me an email - brittonbroderick@gmail.com.