Context Pairing
Pair Programming for the Remote Era
A common stereotype is that developers are lone wolves by nature; indeed any depiction you see of them in the media reinforces this: a single hooded figure bent over a computer streaming lines of code. In the working world, while that stereotype is overblown, (though we do like to wear hoodies, who doesn’t?) it is not completely hollow. Developers do tend to work solo. Do we work on and in teams? Absolutely. Do we write code together? Perhaps, not so much.
Pair Programming
Pair programming is an idea that gets tossed around a lot in our industry. It’s a concept that is potentially controversial as well. Conventional wisdom says that when you pair, you are doing with two developers what you could be doing with one. It’s the opposite of a 2-for-1 deal. Of course, there are benefits to pair programming that offset this cost. For example, a senior developer pairing with a junior, accelerating their learning and thus their ability to successfully contribute to the codebase, or two developers pairing on a particularly sticky issue to reduce the amount of time that one developer would spend debugging.
Pairing in this way follows the currently accepted pattern: working on the same piece of code at the same time. I believe there is another way to pair, one that reaps even more benefits than the examples above.
Let’s call this new method context pairing.
Context pairing is as simple as this: work synchronously, instead of asynchronously.
Two Heads Are Better Than One
We know that code that is looked at by more than just the developer who wrote it will be less buggy and more successful in production; it’s the reason code reviews are built into the fabric of the development process, but what if that process could happen more organically, and more often?
When pairing with another developer, there is no set rule that you must be working on the same problem at the same time. Using modern tooling, often built right into your IDE, (like VSCode’s Live Share) it is easy to work on the same code, in the same branch, with a coworker nowhere near you in physical location.
But why would you do this? How is this different from a traditional development process where two devs are working on the same project asynchronously, pushing up changes as they are completed? Version control systems like Git allow us to do this easily without over-writing each other’s work. Why would synchronous work be any better than this time-honored process?
I believe the benefits are many, and I know because I have been using this synchronous co-working strategy successfully with my fellow front-end developer, and co-worker at Rocket Communications, Kiley Mitti.
The Evolution
Kiley and I work together so often that there’s a joke on our team that we are the same developer. Sometimes a co-worker will be describing something to me as though they are continuing a conversation we began earlier, only to realize that they had actually been speaking with Kiley. She has told me that the same thing happens to her.
Co-worker confusion aside, Kiley and I accidentally developed a super power in the way that we pair program.
When I started at Rocket Communications I was hired in the same cohort as Kiley. We onboarded together and were both placed onto the same project, Astro UXDS. As we got up to speed on the tech stack, we often found ourselves bouncing questions back and forth via Slack. When it came time for our first project, we asked our managers if we could pair. We were learning Stencil at the same time, and we both saw how working together could accelerate our understanding. The request was granted and we set about coding.
Yowch!
On this first project we worked on the same parts of the code, essentially at the same time. Using VSCode’s Live Share feature and a simple huddle on Slack we could both be in the same branch at the same time and easily navigate around our workspace. However, there were pain points to overcome. When I took my turn ‘driving’ the code, I would often end up with a bit of stage fright. This was a new job for me, and I didn’t want to embarrass myself by typing out poor code, or taking too long to come up with a solution.
Ultimately, it turned out we were both having the same fears, and as we communicated them, it got easier and easier to swap turns and type out ideas. A suggestion or a tweak from the other person was often all it took to get a sticky bit of code working. This, I believe, is a core tenet of successful pair programming: if you’re using two brains, they should both feel empowered to contribute.
Up to Speed
For this first project our pair programming followed the traditional definition: two devs, one feature. Still, we immediately saw the benefit in how quickly we were ramping into the tech stack, and we were eager to pair on more projects. Management agreed, as we had cut the timeline for the slated feature nearly in half.
As we worked on more projects together, pairing got easier and started to feel more natural, and as we expanded our understanding of the codebase, our pairing sessions started to evolve. We started to be in the same file together less and less, and unless we were working through an issue together there was a feeling of, ‘oh, you’ve got this, I don’t need to be in here.’ Since our projects all came with lists of tasks to complete, we usually split the task list and worked independently.
Now you might ask, at this point, why pair? What’s the point of being in a pairing session if you aren’t working on the same thing? Here is my answer: we were still working on the same project, and that context made all the difference.
Rubber Duck 2.0
Developers will be familiar with the concept of ‘rubber duck-ing’, using either an inanimate object, a person, or a pet, and having that thing/person/pet sit there while you explain your code. This usually results in you talking yourself into a solution. While this concept works well, it turns out a person is better than a rubber duck, but not just any person, a person who knows the code and the context.
How many times have you been in a situation and thought, ‘well, I’m stuck. I would love to have a co-worker take a look but…’ and then fill in the blank: ‘but, I’m the only one working on this project, so anyone I pull in will need to get up to speed on what I’m doing,’ or ‘but, my co-workers are surely busy with their own work.’
This is where context pairing really shines.
If you’re already in a pairing session with someone who is working on the same project as you, it eliminates these issues. They are already familiar with the code, so they usually have good suggestions to add. If simply talking through the issue doesn’t work, they can jump in and help. All of this can be done with minimal ramp-up time, and since this is usually so quick, they can jump back into their own work afterward without losing their place or their flow.
VSCode’s Live Share has a lot of cool features. One thing it offers is the ability to follow a pairing partner as they move around the codebase. This allows the helper to write their own code on the fly if they have an idea. This ‘pop-in’ feature allowed Kiley and I to be heads-down on our own work, but quickly pivot and jump into the other person’s file if they needed help on something, or wanted an opinion. This made the process of debugging super fast. Instead of fruitlessly Googling something and dumping time into a bug, two heads can tackle the issue and work together to quickly architect a solution.
Another benefit of context pairing is having a second person readily available to bounce ideas off of. Having an immediate answer to the question ‘hey, is this a good idea?’ is huge. For example, if your partner can foresee an issue with the solution that you missed, it could save you hours spent going down a bad path.
This new method of pair programming continues to pay dividends. We’ve carved weeks off of delivery times, which makes a huge difference when you have to make a tight deadline.
A Few Caveats
This type of work is not a one-size-fits-all solution, and there are some barriers to doing it effectively.
Interpersonal barriers might be the biggest hurdle to overcome. If you are not used to working in this way with your co-workers it can be a big change, especially if you tend to thrive in solo work. Let’s be real here, working this closely with another person can be awkward. Writing code can be messy and doing it in front of another person can sometimes feel like airing out your dirty laundry, but I promise you, if you can get over this hurdle, the benefits are worth it. Context pairing is a skill, and it gets easier and smoother the more you do it.
From a technical standpoint, your commits are going to look a little weird. I am not here to debate the merits of any specific commit style, but if you are used to sending up more bite-size, atomic commits, this will feel a bit dirty. With this method (and using VSCode’s Live Share specifically) two people working in the same code are technically only working on one machine, so the commits will come from one person, but will handle the work of two. This can make for a messy commit history if you’re both working on different things. You’ll have to decide with your partner how best to handle this.
In Sum
This style of working is not for everyone, and it is not a silver bullet productivity increaser for every project. For any project that Kiley and I do pair on, there are plenty that we don’t. Even if we are working on the same project, sometimes it just doesn’t make sense to pair that day.
For me, developing this new style of pair programming with Kiley has also helped mitigate one of the gaps that comes with remote work: camaraderie with your coworkers. It’s easy to feel disconnected working in a home-office, but working in this way has helped me feel like I have an in-office coworker, and has brought back that feeling of being able to stroll over to their desk for help with an issue, or just to ask them what they had for dinner the night before.
I’m not saying we should upend asynchronous work (I’m not trying to put Git out of business). What I am saying is that you should give context pairing a try; I think you’ll be pleasantly surprised by how much you can learn.
