Passive Pair Programming

Pair programming occurs when two programmers sit at the same computer and work together to craft a piece of code. This practice has well-documented benefits such as higher code quality, greater hands-on learning, and improved team morale.

However, in an academic research lab, students are often working on their own independent projects, so traditional pair programming doesn't make much sense. Also, one student noted that due to disparities in experience levels, younger students might feel intimidated to work on the same computer alongside a senior colleague. They're afraid that it might feel too intense.

To address these issues, I've recently begun trying a variation that I call passive pair programming (PPP). In PPP, both parties are working on their own laptops but seated side by side at the same table. Here is the PPP protocol (PPPP):

• The driver is the person who is working on the main project that's the focus of the PPP session. The helper sits alongside the driver on their own laptop and does mundane errands or just chills by watching online cat videos.

• The driver mostly works alone. Even if the driver never asks the helper for anything, they already reap the benefits of PPP since somebody is sitting next to them and able to look at their screen, so they won't want to slack off as much.

• However, the driver is allowed to interrupt the helper at any time. The helper must drop whatever they're doing and immediately help. During one of my PPP sessions, the driver had never programmed in Python before, so he occasionally asked me for the names of Python standard library functions that might do certain tasks. And I could fire off those answers quickly and then go straight back to taming my inbox.

• Also, unless the driver explicitly requests help, the helper must remain passive and cannot jump in to offer any help. Instead, they just work on their own laptop as usual. This rule prevents the driver from feeling intimidated that the helper is scrutinizing their every move and waiting to pounce.

The main benefits of PPP are that both the driver and helper stay on task, and that the driver can get help at any time. Also, it's much easier to do than traditional PP since the helper can work on their own tasks and not just stare passively at the driver's screen the whole time. Finally, even though the helper can be interrupted at any time, they can also be productive at knocking off mundane tasks such as administrative emails. Again, the fact that they are sitting alongside a colleague makes them less prone to slacking off. Of course, the helper is welcome to slack off since their project isn't the focus of the PPP session.

PPP also has some drawbacks compared to traditional PP:

• It doesn't provide the code quality benefits of two pairs of eyeballs simultaneously looking at the same piece of code.

• The learning isn't nearly as immersive since both parties are on different computers.

Tentative conclusion: PPP is good for motivating the driver to stay on task, and also allows the helper to do some easy work in the background. However, it probably doesn't lead to higher-quality software. It's good for providing mentoring and motivation, but not necessarily for fostering collaborative work amongst peers.

If PPP works well, then I might replace some of my 30-minute one-on-one weekly student meetings with slightly longer PPP sessions (e.g., 60 or 90 minutes). In this way, PPP resembles a mini version of research hackathons.

Update on 2014-02-14: So far, PPP is working really well. 90 minutes of PPP feels far more productive than a 30-minute chit-chat meeting. Not only is it better for the student, but I also feel like my own time is better spent. And I have more fun watching students do research rather than just talking about doing research. A lot of serendipitous informal learning happens when we are deep in the weeds of implementation rather than just chatting at the whiteboard. I can see PPP becoming a sustainable alternative to research hackathons. (Of course, standard meetings are still necessary for discussing high-level strategy.)

I just sent the following email to all of my student collaborators to schedule weekly two-hour PPP sessions: