Ruby Video
MountainWest RubyConf 2012
Does Pair Programming Have to Suck?
Angela Harms
2 talks
#pair-programming
#collaboration
#team-dynamics
#agile
#developer-experience
#software-engineering
#productivity
Summarized using AI

Does Pair Programming Have to Suck?

by Angela Harms

In her talk, "Does Pair Programming Have to Suck?" delivered at the MountainWest RubyConf 2012, Angela Harms explores the complexities of pair programming within software development teams. She contrasts the experiences of teams that embrace pairing as a collaborative practice with those that struggle with it, often resulting in ineffective or disengaged pairings.

Key Points Discussed:

  • Benefits of Pair Programming:

    • Pair programming is often believed to enhance productivity by improving speed, quality, and knowledge sharing. It helps onboard new developers and fosters collaboration, leading to expressive code and reduced errors.
    • Personal anecdotes emphasize that successful pair programming can result in simpler solutions and prevent oversight of mistakes due to fresh eyes.

  • Challenges and Reasons for Poor Pairing:

    • Harms discusses common scenarios where pair programming fails, noting that distractions, lack of experience, and improper setups (like inadequate monitors) can hinder the process.
    • The perception of pairing as reduced effectiveness, particularly in challenging circumstances or when programmers struggle with self-doubt, can also lead to poor experiences.

  • The Dynamic of Pairing:

    • Working with junior developers can be valuable despite their initial lack of experience. Such pairings can reveal flaws in one’s own understanding and coding practices through engaged discussion.
    • Conversely, pairing with a more experienced partner can lead to knowledge gaps if one doesn’t take the initiative to engage and contribute effectively.

  • Collaboration as Key to Success:

    • Collaboration shouldn’t just be about code; it should also focus on creating an environment where team members feel safe to express their thoughts and opinions.
    • Emphasizing open communication during pairing fosters creativity, improves standardization of coding practices, and results in better overall code quality.

  • Remote Pairing and Continuous Learning:

    • Harms advocates for practices like code retreats to refine pairing skills, especially in remote settings, highlighting that participants benefit from intensive collaborative experiences.

Conclusion and Takeaways:

  • To make pair programming effective, teams need to prioritize focused collaboration over performance pressure.
  • Encouraging a culture of communication and openness can significantly improve pairing experiences, making them less soul-sucking and more productive.
  • Each team member should actively participate in the pairing process to avoid knowledge debt and to foster a sense of shared responsibility in the coding process.
00:00:14.599 The topic of this talk is: "Does Pair Programming Have to Suck?" But as I mentioned earlier, Brady, that’s his Twitter handle, in case anybody doesn’t know, and it’s slow red, but that’s his fault.
00:00:22.400 So the plan was, I usually think about things in terms of left brain, right brain, but it works. On one side, we have the part of us that wants to have everything figured out, all perfect, lined up, and categorized into six steps to successful pairing. I think that’s what I’m supposed to write, so I write it, and then it comes out dead and boring. And then Brady gets up, and he’s all about Ruby being love.
00:00:44.960 Okay, so this is going to be a crossover between the talk I gave at Ruby Midwest and the things that David made me say out loud. We'll just see what happens. So now, we’ll explore why pair programming has to suck and how to let go of having it all worked out.
00:01:15.439 This is like following the advice: "Memorize your talk and don’t change it, no matter what, because then you won’t know what to say." Well, that’s what I did, I changed it, and now I don’t know what to say. So, let’s see what happens.
00:01:18.119 I’m Angela Harms, and I work at Dog in Cleveland. Sometimes I work on a boat, sometimes when the boat's being rehabbed, I work in an office. I work on a mobile team of about seven people. We have an awesome time pairing, we fight, and that’s my official intro. My real intro is that I’m obsessed with collaboration, love, compassion, and figuring out what can change in the world if we actually pursue that.
00:01:40.119 If we let down our guard, that’s what I’m really about, and that’s my hidden agenda, just so you know, because I’m not big on secrets. Why do we pair program? Have you all read the advice that says pair programming produces better results? Faster?
00:02:07.440 Ron Jeffries says the same thing: In pairs, progress is faster. We can work longer without losing headway, and quality is higher. Everybody says this, right? There are studies you can look up; I’m not going to read them to you. I will quickly go over why pairing is a good idea.
00:02:39.160 How many of you pair at work now? And how many pair close to 100% of the time or on all committed code? Now 50%? Not at all? Okay. One other question: How many of you would pair if you could or would prefer to? A second question: How many of you would like to avoid pairing if you could?
00:03:01.080 Thank you. So, quickly, before we go further, let’s discuss how pairing helps us. It helps to bring up new developers since they can find out what our codebase is like—what we’re trying to accomplish, what our tools are, and how they work. It’s crucial to do this.
00:03:24.280 It also cuts out waste. Maybe it’s just me, but how much of your energy goes into trying to prove you’re not an idiot or trying to look smart enough during your first week on the job? Pairing cuts that out; you don’t have to do that. You can just actually work with somebody.
00:03:51.440 Pairing helps us share knowledge, even with people who have less experience. We all know what’s going on, and we don’t have the desperate fear that someone might leave the project, leaving a knowledge gap. Pairing makes our code more expressive because names you choose by yourself can be unintelligible.
00:04:15.760 When you think you’ve picked the perfect name that expresses what it does, your pair might say, ‘What the hell is that?’ Then you realize, oh, maybe we should talk about it. By yourself, your code may not be as expressive.
00:04:39.840 Pairing reduces errors. I once spent 25 minutes trying to troubleshoot a problem, only to find that my logic was reversed. It can help avoid those stupid mistakes, things we might overlook when we're too tired or not thinking of edge cases.
00:05:00.400 Additionally, paired programming creates simpler solutions. Many believe collaboration means two ideas clash until one wins, but that’s competition. Collaboration involves ideas coming together to improve one another, resulting in something new that you wouldn’t have come up with on your own.
00:05:23.440 Also, it keeps us off social media, which is a significant benefit. These are all reasons that pairing is a good idea. So, why don’t we pair?
00:05:34.319 This all started when I had a conversation with a super-duper Rockstar Agile developer coach who was next to a junior developer. He was on his laptop, she was coding away, and he said, ‘Yeah, we're pairing.’ I was like, ‘What?’ He said, ‘We’re doing what I like to call side-by-side pairing.’ I loved that because it means he gets to work on his laptop while checking emails.
00:05:53.279 Funny enough, I asked people why they don’t pair, and a lot of senior developers told me that people don't pair because they don’t have proper setups—they lack two monitors or a big monitor.
00:06:06.000 I wanted to know about good and bad pairing experiences. In good experiences, it seemed to make no difference if you had a junior or senior, or even a lousy laptop or great setup. Good experiences centered on being focused on the code, and bad experiences resulted from someone who didn’t focus on the code.
00:06:21.520 Tim Ainger, a friend and Agile coach, wrote a deck of cards stating the same thing: ‘Here’s how to make pairing work: focus on the code, not on your performance nor that of your partner.’ But focusing on the code is hard.
00:06:42.680 It's challenging when we feel stressed by the presence of another person, feel introverted, or think we aren’t good enough. Tiger, who works at Bendy Code in Madison, said it makes programmers work harder than they ever have in their lives.
00:07:01.760 Now, I want to go through some reasons why pairing can suck. When you’re paired with a newbie, they may be less experienced with the codebase, the toolset, or even collaboration. However, they can still be useful. For example, they might catch typos that you overlook.
00:07:19.400 When pairing with a newbie, you can find out how dumb your naming conventions are or realize you're heading down a wrong path, but only if the newbie is willing to engage and discuss.
00:07:42.000 You should question everything: ‘Why are you doing that?’ My favorite experience involves a brilliant teammate capable of complex coding. However, I always ask him, ‘Is that the simplest way to get it working?’ It leads to valuable discussions.
00:08:00.440 In order to get that level of collaboration, you must be willing to engage and discuss openly. It's easy to think, ‘Oh, this person is a newbie; I’ll do all the hard work.’ However, modeling collaboration is crucial.
00:08:25.360 You have to teach them what it looks like to change your mind and pivot when necessary. When pairing, you realize that it's important to recognize when your idea was wrong, appreciate the new idea suggested, and celebrate that collaboration.
00:08:52.440 But what happens when you’re the rock star paired with a newbie? You might feel intimidated, and this doesn't happen to any of you, right? Well, it does happen to me. The superstar can fill in knowledge gaps, help you solve problems, and guide you along. Still, they can also zone out or avoid engaging.
00:09:22.319 What you need to do while pairing with a superstar is take initiative. You must lead the collaboration, showing them how to work together and effectively model learning new things. Asking for the keyboard repeatedly is vital—it means you're engaged, paying attention, and willing to contribute.
00:09:50.520 It’s challenging not to retreat into the background if you feel you’re not contributing much. However, remember that taking time to learn will ultimately benefit your team. The downside is not taking the keyboard back from the senior person makes you rack up knowledge debt.
00:10:06.440 That’s a situation to avoid. What if you need to go fast? Does pairing get in your way? Yes, sometimes pairing can slow you down because it involves explaining your thought process.
00:10:19.560 But it can also be incredibly beneficial. I experienced a situation where my team felt pressed for time, and I started thinking about whether I should work without pairing. But I realized my absence could hinder others if they didn’t have my insights.
00:10:37.840 So while pairing might slow us down, it can also lead to better quality code, as long as you maintain focus on the code rather than the pairing itself.
00:11:00.080 Focusing on collaboration shouldn’t distract from coding—it's quite the opposite. If both team members focus on the coding, you’re enhancing productivity.
00:11:23.520 But if one person is distracted by the pairing, it interferes with focus. Practical strategies aid in effective pairing. Swapping off roles organically contributes to a seamless process.
00:11:50.960 In a well-composed environment, you might intuitively trade off whenever someone has a new idea. This collaboration is facilitated by discussing changes together rather than one person taking control.
00:12:17.200 In pairing, you’ll always face some challenges, especially when implementing coding standards. Some might disagree, resulting in inefficiencies. However, pairing also helps generate code standards, allowing teams to create them collaboratively.
00:12:38.720 You don’t need to impose these upfront; they evolve naturally through the pairing process. The aim is to find common ground and choose the best path forward.
00:13:01.840 Once you have consensus, if you find yourselves in disagreement, it’s okay to model the alternate path initially, so you can learn from it together later. Giving up a need for control can greatly enhance the pairing experience.
00:13:22.640 So long as the team trusts one another, better code will emerge organically. You don’t need to get it perfect right away; the coding process can adapt over time.
00:13:46.000 Assuming Test-Driven Development (TDD), collaboration creates lively and energetic sessions. It offers the capability of generating vibrant ideas and solutions that are beyond what one person might achieve alone.
00:14:15.680 Remember, your role is to sell the pairing process to your team. You must foster an environment where everyone feels safe to collaborate, rather than imposing standards.
00:14:37.400 You need to encourage it and demonstrate that collaboration can lead to greatness. Regardless of your skill level or experience, you are the one who provides the knowledge that collaboration works.
00:15:03.680 You have to take initiative in handing over the keyboard and asking to take it back. Pair programming will not take off unless those who understand the value are willing to share their insights with others.
00:15:27.440 That ends my prepared content. Do you have any questions? How long did it take me to be sold on pair programming?
00:15:53.680 Well, I can tell you that it only took five minutes for me to realize how much I hated it. When it sucks, it really sucks. But I've been a fan of collaboration for a long time.
00:16:20.560 I first came across pair programming in Kent Beck’s book 'XP Explained,' and it made perfect sense to me. I had a lot of sucky experiences but felt it should work, and when it did, I was thrilled, which is why I'm enthusiastic about improving it.
00:16:46.000 Then someone asked if pair programming could be implemented from the bottom up, with the team deciding to engage in it. In my experience at theme dog, we don’t get from the top down—it’s all about individuals and their preferences.
00:17:12.080 If you’re allowed to code without restriction, it’s great; however, if someone is preventing you from writing tests or pairing, that’s challenging. It can be challenging to bring it up.
00:17:34.040 One query was about remote pairing. I suggest reaching out to Evan, as he has specific insights on successful implementations. A good reference point is remoteprogram.com.
00:18:05.440 As for my thoughts on remote pairing, I highly recommend participating in a code retreat. It's a day-long experience full of pairing sessions, providing excellent practice for new participants. Code retreats are beneficial for experiencing pairing in various capacities.
00:18:35.440 Does anyone else have questions? If not, thank you!
Edit
Explore all talks recorded at MountainWest RubyConf 2012
+11