Article summary
For all the good and bad that has come with the LLM domination of software development recently, one aspect I can definitely appreciate is that everything feels on the table when it comes to figuring out how to best approach our jobs. Granted, that’s also the part that terrifies me. It’s definitely my and many others’ first big industry sea change. However, I’m at least fortunate enough to work with and for people who trust each other. This has allowed me to continue holding on to one of my favorite practices from our robot-less past: pair programming.
Pairing isn’t redundant yet.
Of course, LLMs haven’t made pairing redundant. But we’d all be kidding ourselves if we didn’t acknowledge that the ease of using the robot has made human collaboration (on implementation, at least) feel a bit less relevant. That’s rooted in some flawed logic, of course. Pairing proponents like myself will always tell you that the benefits of two devs on one task can outweigh those from two devs on two tasks. However, it’s hard to deny that it’s a lot easier to work “solo” when you can be productive bouncing ideas off of and delegating work to an LLM.
In spite of that, I still have found that pairing has the same value as it did pre-LLMs. For example, I know myself and others have struggled with the sudden lack of friction in some implementation work. Models are always getting faster and smarter. As we trust their output more, it’s become easier to rubber-stamp that output in favor of continuing to produce more. But with a pair, it’s more natural to be critical of the output together through conversation, but also of how you interact with the LLM itself. The shared stake in understanding what the tools are doing for us reinforces that understanding, and along the way we help each other improve how we use those tools.
Pairing as code review.
As it did without robots, pairing still acts as a preliminary code review too. Perhaps the interest is more in the architectural decisions now than syntactic details. But, given just how much code can be written in such a short amount of time and how much of our jobs is now the review of said volume of code, seeing it with a colleague as soon as it’s written can give you and your team much more confidence in what you’re contributing to your project.
Naturally, there’s also a lot of downtime when working with LLMs. You’re firing off a prompt, waiting for it to “think”, letting it iterate and collect context, maybe answering a question here and there. Maybe you’re even working on something else entirely while backgrounding the robot’s work. What can be interesting about combining that with pairing is that now both of the partners in the pair share the downtime.
The driver is no longer just hammering out boilerplate component code while the passenger resists the urge to check their phone. That downtime can now have you both mentally engaged in the next steps of your work. And when the driver is actually occupied? Their pair can consider not just the implementation itself, but also the tooling. What can we improve? Can you write a rule or skill that accomplishes something you’re repeating? If the tool is doing the work, use that time to work on improving the tool.
It’s the human touch.
Most importantly to me, though, is that pairing is the preservation of human collaboration in my job. Sure, that happens at the project level when gathering requirements, making priorities, and planning on what to do. But as someone who is most engaged in my work when I get to do it with somebody else, I value the opportunity to pair. Beyond the benefits to project outcomes it can have, it’s also just my preferred way of learning. I’ve always learned best from working with others, so I especially cherish the opportunity to do so when it’s never been easier to work alone.
So my recommendation is to not forget about pairing. It may be different now, but it’s still justifiable and even valuable as a strategy for getting work done in this day and age. There are still some challenges I haven’t solved just yet, though. How can the actual prompting be more collaborative? Can audio tools be used to make the entire collaboration more conversational? If any readers are also pairing, I’d love to hear about your strategies and experiences in how you’ve made it successful.