I Have Pair Programmed for 27,000 Hours: Ask Me Anything!

by Joe moore

In a talk titled "I Have Pair Programmed for 27,000 Hours: Ask Me Anything!" at LA RubyConf 2014, Joe Moore explores the concept and practice of pair programming, inviting the audience to ask questions about this software development technique. Pair programming involves two programmers or a programmer and a designer working together on the same computer to solve problems jointly. Moore shares his extensive experience and provides answers to common inquiries surrounding the practice, addressing both its benefits and challenges.

Key Points Discussed:

- Definition of Pair Programming:

- It involves two people working together on a single computer, often using tools like Skype and screen-sharing for remote collaborations.

- Overcoming Nervousness:

- Moore acknowledges that nervousness can be a constant feeling at the start of a pairing session but emphasizes that rapport helps ease this sensation over time.

- Benefits and Flexibility:

- He argues that pair programming is effective for most tasks, including writing emails and tackling complex programming challenges.

- Communication:

- Effective communication (verbal and nonverbal) is crucial; silence can hinder remote pair programming.

- Disagreements in Pairing:

- When disagreements arise, they can often be resolved through negotiation or by consulting a third party. It's important to maintain a compromise to achieve the best solution.

- Role Switching:

- The roles of 'driver' and 'navigator' in pair programming should switch frequently to maintain balance and energy. Nonverbal signals help in this transition.

- Individual Preferences:

- While some developers prefer working alone at times, pairing enhances accountability and quality. Moore reflects that solo work can sometimes yield poorer results.

- Learning Opportunities:

- Pair programming promotes knowledge sharing and cross-training, benefiting both junior and senior developers.

- Remote Pairing vs. In-person Pairing:

- Remote pairing can sometimes lead to a more focused experience compared to work in a noisy office environment.

- Taking Breaks:

- Moore emphasizes the importance of breaks to prevent burnout, advocating for a balanced approach to pair programming.

Conclusion:

Overall, Joe Moore's session sheds light on the value of pair programming, highlighting its collaborative nature, potential for deep learning, and practical considerations for effective implementation. As attendees engage with these insights, they leave with an appreciation of how this technique can enhance their development processes and teamwork dynamics.

00:00:00.089 I know that in talks where there's a lot of audience participation, it can be kind of awkward. You know, when somebody asks if anyone has a question or to raise their hand, everyone kind of mills around. Well, guess what? This entire talk is only that! So if nobody asks any questions, it's going to be really awkward for everyone.

00:00:34.320 Let's do this! I'm going to give you a second. I've pair-programmed for 27,000 hours, which is about every working day for roughly 13 years, and I really want you to ask me anything because people find this topic fascinating. So I'm going to give you a moment, just a couple of seconds, to think of one question that you might want to ask.

00:01:02.160 That question you thought of is probably one of the top three or five questions. So throw that one out and think of another question you might want to ask. How do you get good at it? How do you overcome being nervous? Yes, that's an awesome question! How do you get over being nervous when you're pair programming with somebody? Having a lot of time doing it really makes a big difference. That first time is always the most nerve-wracking.

00:01:37.950 Even now, after 13 years, the first time I pair with someone, I get nervous. I admit that when we organize our projects into what we call 'stories'—you can call them cards or whatever—whenever I start a feature with someone, and even if I've worked with them for a long time, I still feel nervous at the start because I'm always thinking this could be the time I completely fall apart and don’t know what I'm doing, and the person I'm working with will think I'm an idiot. It happens for a few moments every time.

00:02:28.570 So I think the answer for me is I never stop getting nervous. But it becomes just part of it. You get over it really quickly, especially when you have a good rapport with your partner. Ah, there's a question in the back; remember, there are no stupid questions!

00:02:42.850 Yes, what is pair programming? So maybe I'll force you to answer another question. Raise your hands if you've ever pair programmed. Wow, that's almost everybody! I would say that was about 80 to 90 percent. For the 10% who are left, pair programming is a software development technique where two programmers—although it can also be a programmer and a designer—work on the same computer, solving the same software problem at the same time. This can even be done remotely through screen sharing and other technologies.

00:03:34.450 Sometimes that's literally two people sitting side by side at one computer with two keyboards, trying to decide how to write a specific line of code or the best direction to take for a project. You're constantly working together to come up with the best solution to whatever problem you're addressing. That's kind of the canonical description of what pair programming is, and there are a lot of benefits as well.

00:04:04.150 So, what is pair programming good for and what is pair programming not good for? I believe that there are almost no problems that are bad for pair programming. We even pair-write emails, especially when we are sending emails to politically sensitive managers or in complex organizations. We write those together to capture the situation clearly.

00:04:30.530 Now, a question I've heard is, can you pair program on, let's say, artsy things or algorithms—things traditionally considered too introspective or solitary? I think you can pair program on those as well. I really believe there's hardly anything you can't pair program on. Can you pair program without talking to each other? I actually know somebody who tweeted recently about how remote pair programming is so hard, and when I asked what kind of problems she was having, she mentioned that it’s hard to know what's going on when you can't talk to each other.

00:05:20.630 I can honestly say I've never successfully pair programmed in silence—but sometimes you have individuals who won’t talk, which presents a different problem. However, having literally no means of communication just wouldn’t work well. I appreciate the philosophy behind letting your code speak for itself, but I might have a hard time justifying billing my clients for that experiment.

00:06:04.730 As for tools, I could give a whole talk about that, but in general, you need some kind of voice communication, like Skype or Google Hangouts, as well as screen-sharing technology to collaborate effectively. However, I believe if people say 'I remote pair program with Skype or Google Hangouts,' they’re not really pair programming, because you can't truly program together in that way.

00:06:51.460 What happens when you disagree on how to proceed during pair programming? It happens all the time, and I consider pair programming to be a continuous compromise and negotiation. But usually, you end up with the highest common denominator of ideas—not the lowest. When you don’t agree, you might spend a few minutes discussing the options. If both of you are very passionate about two different approaches, it helps to bring in a third respected person to mediate the situation.

00:07:58.100 If that’s not possible, say you're two people in an open-source project and there’s no one else to consult, sometimes you just have to choose one direction and see if it works out. The person who 'won' should be gracious and willing to try the other idea later if things don’t pan out as expected.

00:08:32.870 Nonverbal communication methods are especially crucial in remote pair programming, where you often can’t see each other’s hands. A common question asked is how do you decide who will be the 'driver' typing versus the 'navigator' who guides? This isn’t about positioning hands on the keyboard like in a duet but more about a natural exchange based on comfort levels, energy, and typing flow between partners.

00:09:37.370 In a good pairing situation, you usually trade off control fairly often. I find it’s those nonverbal cues—the little pauses, leaning back, rubbing your face—that signal when to switch roles. When one person is focused and typing intently, it can be disruptive for the other person to just jump in and take over. There are discussions about techniques like ping-pong pairing, where one person writes a test, and then the other implements it, which helps enforce this balance.

00:10:34.610 A common invitation for a partner to take over is a gesture like 'I’m not typing right now,' which can facilitate a smoother transition. The question was, do remote pairs find that remote pairing can be even better than in-person pairing? That’s an excellent question! I have actually heard people say they sometimes enjoy remote pairing more because it allows for more focus.

00:11:40.210 When you’re in a busy office, there’s a lot of distractions, and someone might throw a Nerf ball while another person has a birthday party going on nearby. Remote pairing tends to focus you more intensely on the task at hand, especially when you’re wearing noise-canceling headphones and looking at the other person's face on a screen. Some have said that this heightened focus can actually be beneficial compared to being in a traditional office setting.

00:12:58.300 Now, if you're pairing with someone much more senior than you, do both parties benefit? I would say absolutely! One of the core benefits of pair programming is the cross-training and knowledge transfer effect. Even if you’re a junior developer pairing with someone with decades of experience, there are always opportunities for learning. I keep a little notebook where I jot down things I learn every day from my pair, regardless of their level of experience.

00:14:50.580 I find that I learn something new from each pairing experience. Conversely, when a senior developer explains complex things to a newbie, it forces them to question their assumptions and refine their understanding. This leads to those moments where the teacher learns just as much from the student.

00:15:58.720 Regarding individuals who have only paired side by side and then try remote pairing, the general takeaway has been that it’s almost exactly like in-person pairing. While they may rate it a little lower, they often find it is much better than they expected. They may feel intimidated at first by the technology, but that novelty fades quite quickly into a normal pairing experience once they jump into coding together.

00:17:06.040 Do I ever want to just work by myself? Yes, absolutely! I have paired throughout my entire career, but I do sometimes miss working independently. Some days, especially when you are in between client engagements, working alone might be more suitable. I’ve also been asked if when someone is sick do you take the day off? No, we’re not that dogmatic about it.

00:18:06.000 Of course, we do encourage people to go home if they’re unwell. Those solo days can be fun, but I also find myself producing some of my worst code on those days. It’s pretty easy to lose focus without a pair to help ensure quality. It's somewhat like having bachelor time when your spouse is away—fun for a moment, but ultimately it's better to get back to a more disciplined state.

00:19:25.890 So, what if you have a pairing situation where people are almost of the same mind and experience level? That’s extremely rare because we are all opinionated people, and we have vastly different experiences. Even if two people are similar in age and experience, they almost always come with different points of view shaped by their diverse backgrounds.

00:20:12.480 What's the editor or key mappings do you use? The answer is yes, those differences do exist even in teams that are expected to be using the same tools or methodologies. This can be a challenge in a pairing context where differing individual setups can lead to friction, especially in environments like open-source projects.

00:21:21.690 Ultimately, learning from each other while navigating through differences found in tools, configurations, and processes can strengthen the team. When two individuals work with different editors, it often serves as an opportunity for mutual learning. It’s about finding a common ground within the tools we utilize.

00:22:32.910 How do you decide how much driving one person does versus another? Well, I’d say it’s about whatever works best for the pair within reasonable limits. For instance, except in extreme scenarios, I wouldn’t recommend one person driving all day without switching roles. It could create an imbalance, and frequent switching every few minutes tends to be an ideal flow to maintain energy throughout the process.

00:23:43.840 Part of maintaining this balance comes down to being aware of each other’s energy levels. Individuals may not sync perfectly, but a good pairing scenario means taking advantage of those peaks and valleys together. It’s important to communicate nonverbally when one is focused and ready to switch.

00:25:05.650 The question becomes, when should you not pair? Honestly, it’s not about determining a single task not to pair on, but ensuring that you take breaks and avoid burnout. Intense interactions are valuable, but they can also be draining. Sometimes, it’s perfectly fine to take a break from pairing altogether to recharge.

00:26:14.790 That's all the time I have for questions today. Thank you all for participating in this discussion about pair programming!