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

Summarized using AI

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

Joe Moore • April 22, 2014 • Chicago, IL

In this video, Joe Moore shares his extensive experience with pair programming, having practiced it for nearly 13.5 years, including remote pair programming for the last four years. He addresses common questions and misconceptions surrounding pair programming, making the case for its benefits amidst its challenges.

Key Points Discussed:
- Definition of Pair Programming: Joe defines pair programming as a technique where two programmers collaboratively solve the same problem on one machine. This can also be applied in a remote setting using collaboration tools.
- Benefits of Pair Programming:

- Continuous code review.
- Cross-training among team members of varying levels.
- Reduction of bugs due to shared oversight.
- Enhanced problem-solving through collaboration, often referred to as 'two heads are better than one.'

- Challenges in Pair Programming:

- It can be exhausting.
- There may be personality conflicts among partners.
- The technique might be hard to implement due to reluctance from team members or management.
- Time Efficiency: Joe discusses concerns about velocity, noting that while tasks may initially take longer with pair programming, the long-term benefits include fewer bugs and better code quality. He advises teams to investigate specific issues that may be slowing down their process.
- Handling Breaks: Joe emphasizes that breaks should be taken whenever necessary, stressing the need for individuals to listen to their own physical and mental cues.

- Experimenting with Pairing Strategies: Joe mentions different pairing configurations, like senior-junior and junior-junior, and emphasizes the need for diversity in pairing styles and roles to enhance learning and collective knowledge.

- Tools & Technology: Joe addresses the potential of tool conflicts in pairing, sharing that teams must find common ground while staying flexible.
- Including Other Roles: He advocates for integrating QA testers and design personnel into the pair programming process, as it fosters collaboration and improves overall product quality.
- Techniques for Effective Pairing: He suggests using structures like ping pong pairing, where the roles of driver and navigator rotate, promoting balanced involvement from both programmers.

Conclusions and Takeaways:

Joe concludes that the key to successful pair programming lies in fostering trust, patience, and good communication skills between team members. Though pair programming can come with challenges, the long-term gains often outweigh the initial drawbacks, making it a valuable practice in software development.

I Have Pair Programmed for 27,000 Hours: Ask Me Anything!
Joe Moore • April 22, 2014 • Chicago, IL

By Joe Moore

I've pair programmed almost every work day for 13 1/2 years. You've got questions. I've got answers.

Presentations I give, regardless of topic, grind to a halt once I mention pairing. Do we pair all day? Who owns the code? How do I convince my boss to let us pair? When do you take bathroom breaks? What about remote pairing? Pairing is a scam!

I'll answer all questions, from the poignant to the silly, and want you to share your own pair programming experiences. Ask me anything!

Joe began writing software in the late '90s, soon joining eXtreme Programming pioneer Evant in 2000. He joined Pivotal Labs in 2005 as a founding member of their Rails consulting practice. Joe remote pairs full time for Pivotal and blogs at http://remotepairprogramming.com. His Ward Number is 1.

Help us caption & translate this video!

http://amara.org/v/FG03/

RailsConf 2014

00:00:16.760 My name is Joe Moore and I've pair programmed for almost thirteen and a half years, almost every single working day.
00:00:23.199 For the last four years, I've been pair programming remotely, using remote pair programming full-time.
00:00:30.759 During those thirteen years, I've worked for Pivotal Labs, which is an agile software development consultancy, and I work remotely from Atlanta.
00:00:38.399 For those of you who didn't hear this, I would love feedback at bitly.com/programmingAMA. It's totally anonymous.
00:00:44.640 For the people who just walked in, there's a microphone here and a microphone over there.
00:00:50.559 If you have questions, it would be great if you could make your way to one of them and start queuing up while I talk about some other stuff.
00:00:56.520 Otherwise, I'm going to grab these mics and run around, doing a bit of a Mori, maybe.
00:01:01.920 So again, thank you to everybody for coming here. Who is at least somewhat familiar with pair programming?
00:01:09.080 I'm going to estimate that it's about 80 to 90%. That's great!
00:01:15.960 For those of you who don't know, pair programming is a software development technique where two programmers work on the same code at the same time, solving the same problem on the same computer.
00:01:27.640 You can also apply the word remote to that, using some remote collaboration software, like video chat, audio chat, screen sharing, and so on.
00:01:40.079 So what are the benefits of pair programming? I could have slides and slides and slides, but I'll just give you a few. Benefits include having a continuous code review, cross-training junior developers and those who are more experienced, and reducing the number of bugs because you have two pairs of eyes on the same work. Having differing opinions can raise what I call the team's highest common denominator, leading to great outcomes.
00:02:03.960 Generally, as most of us know, two heads are better than one when solving hard problems.
00:02:16.080 What are the challenges of pair programming? It can be very exhausting, and personality conflicts can arise when individuals don't get along. It is definitely one of the most challenging software development practices to implement, both from a social point of view and from the perspective of selling it to management.
00:02:40.440 It's not just double the money and twice the time; it also requires dedication to be effective.
00:02:55.599 I want to address one of the top-three questions right now: when do you decide to take breaks? The answer is simple—take a break whenever you need to.
00:03:11.960 It's important to remember that you're working together as people. If you've been going for an hour or more, it's definitely time to take a break—stretch your legs, play some ping pong, or use the facilities—whatever helps you recharge.
00:03:30.879 Pair programming is an intense discipline, and managing your energy levels is super important.
00:03:42.640 With that said, feel free to ask me anything. Who's got a question over here?
00:04:06.720 There's a question about how one team finds pairing tends to slow things down by maybe 50 to 100%, and they even use it for hard tasks but skimp on it otherwise.
00:04:21.199 I think empirical evidence has shown that in controlled environments, pair programming can slow down accomplishment of tasks by about 15% on average, which is not as drastic as 50 to 100%. There are other payoffs to consider, such as improved code quality, and focusing on the ultimate goal could reveal the long-term benefits of pairing.
00:04:56.199 Identifying the root causes of slowdowns is crucial, since it might not be just pairing that's causing it.
00:05:02.639 I also appreciate the point about balancing the workload when working with junior developers, especially to avoid the inefficiencies caused by having the pairing imbalanced.
00:05:24.000 At our company, we tend to evaluate tasks on a scale and pair for those that need it most. Once we've identified value in more complex tasks, it might be easier to incorporate pair programming in those areas.
00:05:41.480 Managing stakeholder expectations is also important, and being open to retrospectives can reveal both challenges and opportunities for improvement.
00:06:00.840 Pair programming dynamics can be complex, and understanding the spectrum from junior to senior developers can guide better pairing practices. It’s about building empathy and transferring knowledge during the pairing sessions.
00:06:15.680 Different tools should not dictate pairing arrangements; instead, general adaptability and communication should guide the way. If you have differing preferences for editors like Vim or Sublime, strive for common ground to facilitate smoother collaboration.
00:06:32.760 Integrating people across disciplines, including QA engineers, can enhance collaboration and lead to better overall product quality.
00:06:52.560 Remember, effective pair programming always revolves around building trust, being patient with each other, and valuing open dialogue.
00:07:02.960 Managing experiences while supporting junior developers is critical. Encourage growth rather than feeling like you have to take over every time.
00:07:10.760 Tools can also enhance pair programming experiences. Using timers, or pairing with a specific structure like ping pong pairing helps maintain engagement and ensure balanced participation.
00:07:23.760 Getting feedback from peers also assists in developing better pair programming habits.
00:07:33.360 With good communication, team dynamics can thrive as developers become more comfortable sharing the keyboard while testing each other's skills.
00:07:46.080 Overall, it’s about finding balance between guiding others and allowing them to explore solutions on their own.
00:08:01.950 Thank you all for your questions and enthusiasm. Remember to keep practicing pair programming!
Explore all talks recorded at RailsConf 2014
+129