Passive Pair Programming
February 2014 (perspective of a postdoc)
Passive pair programming is like pair programming except that the helper works independently on their own computer but is willing to be interrupted at any time.
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 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:
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:
Like I mentioned before, think of this not as a meeting but rather as time that you would normally be at your desk working anyways, and I just hang out and watch cat videos next to you.
This works best if we just schedule a regular weekly time and stick to it; if we miss some weeks, that's okay, since it's not a planned meeting. It's just work time where you can feel free to ask me questions.