Paired Programming: Good or Goblin?

I'm going to talk about one of the most surprising things I learned in software dev bootcamp: how I really like pair programming.

Quick summary: pair programming is when you work together with a partner on code. The format I was taught went like this: one person codes for an hour, and the other person looks on at the screen to spot any errors. Or maybe to look up something while the person coding can continue to work uninterrupted. Like a backseat driver. When the hour is up, you switch. 

I personally love how remote work is now commonplace in this vaccine-managed stage of Covid, and what’s neat is that you can still do pair programming remotely. It’s tough sometimes how a lot of things you can do in an in-person workplace are not available anymore, like informally or spontaneously gathering in a common area or a water cooler, or somebody’s desk, but not paired programming. With screen sharing, it’s no issue. I actually like Discord the best for pair programming — I think it’s actually the best video call app out there, it’s not just for gamers or streamers or fan communities — because you can both share your screen and still have a camera view of the other person’s webcam. But that extra UI feature isn’t necessary. The basic screen share on Zoom or Google Meet or what have you is fine. 

I honestly first thought I would hate pair programming when I first learned about it. Nobody likes group projects, and the concept sounded like the worst aspects of group work but even more condensed since you were forced to be shackled to a partner and had no escape! I prefer to work alone on coding stuff, that’s what I liked about making the switch to software development and what I was finding was working for me really well in my boot camp. I thought I would hate being stuck to a clock. 

But to my surprise, when I tried pair programming in that evening’s class session, I was totally surprised. I… didn’t hate it? My classmate and I actually got a lot of work done?

 Here’s why I like pair programming:

1. It is very ADHD-friendly.

I’ll probably write about this more in a future post, but I do have ADHD and that means I’m constantly thinking and evaluating everything I read and see and hear about productivity because, well, my brain just works differently and most productivity advice is written for the neurotypical brain. Which I don’t have. Pair programming combines the benefits of body doubling and working to time limits, both on their own popular and effective ADHD productivity strategies. 

Body doubling is simply having someone physically sit next to you when you work and they can do whatever they want, they’re not working together with you necessarily. When someone’s sitting next to me, something about my mindset changes. Somehow, the feeling that I am not alone in the room helps me not get distracted as much. Or it helps me get back to what I was doing if I do inevitably get distracted. It could be the dopamine of companionship. It could be the conditioned social response that tells me to behave in public. Like, I’m sure everyone has behaviors that they don’t do around other people and only do themselves. Whatever it is, it works. In pair programming, knowing that there’s someone working on the same thing as me there adds just a light touch of pressure that keeps me focused. Like a weighted blanket but for focus. Also, having a partner there to Google something — maybe a syntax question — means fewer opportunities to get distracted or stuck. Having a partner to catch typos or suggest changes prevents some of those frustrating moments when your code won’t compile and you can’t find where the error is. You can spot errors earlier. 

Working to regular, periodic time limits is more common knowledge now thanks to the rise in popularity of the Pomodoro method. I’ve personally had mixed success with the Pomodoro technique. One reason is that alarms going off is not strong enough stimulus to stop and change over. If I get focused on something, I become extremely stubborn and somehow very good at ignoring any and all alarms. I often can’t resist continuing to work past the 25 minute mark and I don’t want to go back to work after the 5 minute break ends. An hour on and an hour off gives and affords more margin for my brain to disengage and switch tasks. All the stubbornness and uncooperativeness my brain has around sticking to a timer by itself, it’s like it suddenly vanishes when partnering with somebody. Combine this with body doubling and you have something very powerful.  

2. The hour-on, hour-off format lets you work for longer and get more done.

I tend to work in bursts. Most of my work in a day gets done in a 3-4 hour window when my brain gets rolling and I’m fully in the zone. But something about working for an hour and then looking on for an hour helps me stay charged and focused for much longer than I can on my own. For whatever reason, the hour periods where I’m playing backseat driver uses much less energy — or at least perhaps not the same energy source as when I’m coding. By the time my backseat driver hour is up, I’m ready to go.  

One of the biggest pitfalls for me in coding is how negative emotions drain your energy, like anger or frustration. Getting stuck is hard, but it’s the spinning your wheels in frustration that’s the real productivity killer. It takes a lot of energy to feel mad, because anger is a response to your will being thwarted, after all. And I believe in feeling your feelings and not stuffing them down or denying them, because that will mean they’ll then just come back later and things will be even worse for you.