Today’s topic of conversation on The Rabbit Hole Podcast is pair programming! We decided to dig it up again since we last spoke about it because we have better mics and a bigger budget now, and Mike forgot what it is so we’re going to remind him. After beginning with some quick definitions, we then get into the different ways to set up a pair programming scenario (see the spooning video in the show notes).
Next up we talk about the typical roles which two coders would occupy as a pair – that of driver and navigator, and what the best practices for each would be. You’ll also hear about all of the many advantages of engaging in pair programming, from saving a lot of time to doing high fives each time you pass a test together. If you can’t high five we recommend the ‘watch the elbow’ technique. You can pair on learning that too. This week’s discussion served as an introduction so make sure to tune in and also catch us next week as we get deeper into our conversation about pair programming!
Key Points From This Episode:
Transcript for Episode 140. Pair Programming Redux
[INTRODUCTION]
[00:00:01] MN: Hello and welcome to the Rabbit Hole, the definitive developers podcast in fantabulous Chelsea, Manhattan. I’m your host, Michael Nunez. Our cohost today –
[00:00:09] DA: Dave Anderson.
[00:00:10] MN: And our producer –
[00:00:11] WJ: William Jeffries.
[00:00:12] MN: Today, we’re talking about pair program, and it’s going to be a series, because we’re going to have a lot to talk about.
[00:00:18] WJ: We got a lot of thoughts.
[00:00:20] MN: We got a lot of thoughts on pairing. It’s been a while since we’ve had this conversation about pairing and we figured, “Hey, let’s bring it up again after a couple of years.”
[00:00:28] WJ: Got to do a reboot.
[00:00:30] MN: Of talking about other content. You got to bring it back, baby. Let’s go.
[00:00:35] DA: We got a bigger budget.
[00:00:37] MN: Microphone sound a little better. Everything is good.
[00:00:40] DA: More explosions.
[00:00:43] MN: Okay. We’re talking about pair programming. I’m going to pretend from now on that I have no idea what this is. What is pair programming?
[00:00:52] WJ: That is a tough one. It’s kind of harder to find. I think that – I would say when you’re pairing on something, you have two minds working on one problem.
[00:01:06] MN: Okay. I think that’s a pretty good way to put it.
[00:01:08] WJ: Yeah, I think there’s like – There are a lot of edge cases where people are like, “Oh, but is it pairing if you do X? What if we slip a ticket, frontend, backend? That’s not really pairing.”
[00:01:18] MN: What if we slip sandwich for lunch? Is that pairing? No. I want my other half of the sandwich too. Thank you very much. What if we order a soup a sandwich? Half a soup and half a sandwich and then you eat the soup and I eat the sandwich?
[00:01:32] WJ: I mean, if somebody did think about how to pair the soup and the sandwich.
[00:01:37] MN: That person is crazy. I want a whole soup or a whole sandwich.
[00:01:43] DA: But taking to mind and putting them to work on one problem.
[00:01:48] WJ: Yeah. I think normally you would see the more – The classical pair programming exercise would be two developers who are both working on the same machine together on the same problem. Maybe you have two monitors, two keyboards, two mice, that would really be ideal.
[00:02:04] MN: That’s be the dope setup. Yeah.
[00:02:04] WJ: Yeah. It’s ideal. Into one laptop and everybody is – Both people are working on the same code at the same time. There’s one cursor.
[00:02:15] MN: That’s more of like an ergonomics and comfort thing. You can also pair with one person on the keyboard and monitor and another person hunched over their side, like kind of just leaning into that person.
[00:02:27] DA: Those are the greatest pairing stations when you’re like breathing down someone’s neck.
[00:02:34] WJ: Yeah. Also, you can use tuple. Tuple being a fantastic successor to Screenhero, which was very tragically murdered by Slack.
[00:02:44] DA: But for ergonomics sake, we use two of the same tools.
[00:02:50] WJ: Yeah. I mean, I’ve seen people like pass the laptop back and forth, which is just such pain. I mean, I guess that works. It is still pairing. It’s just a pain.
[00:03:00] DA: Right, and can be harder to follow the thread if you don’t have a second monitor or what have you.
[00:03:07] MN: But it’s still possible, right? If you have one widescreen monitor, one keyboard, one mouse, one machine, it is still very possible to pair.
[00:03:16] WJ: Right. Yeah. As long as you’re both working on the same problem at the same time. I think other edge cases come up like – If you have a problem and you ask somebody to come over and look at it real quick and they look at it for 30 seconds and then they make a suggestion and then they leave. Is that pairing?
[00:03:33] MN: No. I don’t think so.
[00:03:35] DA: You’ve never heard of pairing before.
[00:03:36] MN: I never heard of pairing before, but that just sounds like I ask Bobby for help, he came by and then say, “Change that,” and then left.
[00:03:44] WJ: Yeah, exactly. But then you get into the gray area where it’s like, “Okay. Well, what if I stay for an hour?” What if they stay for a day, like all day? All right. It begins to blur a little.
[00:03:58] MN: Right. I mean, is pairing to someone, they’re sitting next to you as you do all the work?
[00:04:03] DA: I mean, I think pairing implies like a shared ownership of the result, like where there’s going to be some give and take between the two people. Ideally, the end result will be something that neither developer would have written on their own. The thing that comes out of it will hopefully be better than what those two developers would do, or the result of the shared context that both developers have.
[00:04:31] MN: I see. By having two minds on a particular problem, it will help them come up with a much better solution than one individual working on a set problem.
[00:04:41] WJ: Right. The bottleneck isn’t that you can’t type fast enough. When you’re solving these engineering challenges, it’s never that like, “Oh! If only I could type faster, then all of these would be done so much more quickly.” The problem is you have to think through and understand the problem and then you come up with solutions. Having two people who are constantly getting each other unstuck can mean that you go even faster. You go more than twice as fast as one person could go by themselves.
[00:05:14] MN: Right. That’s more like how do you pair. Are there different roles that people take, and what are the names of said roles?
[00:05:24] DA: Pop quiz.
[00:05:27] MN: Because I don’t know. I have no idea what pairing is.
[00:05:30] WJ: Yeah. You’re really catching on quick here. You just intuited that there are roles, and that’s wonderful.
[00:05:35] MN: I mean, I don’t know. I can’t imagine a scenario where both me and the other person are typing as we get the work done twice as fast.
[00:05:44] DA: Yeah, it’s true. You can just take your role as the left half of the keyboard. Mine is the right half of the keyboard.
[00:05:51] MN: There’s a meme somewhere on the internet or some TV show does that. That’s how me and my pair – I mean, I don’t know about pairing, but I think I see people do that all the time.
[00:06:01] DA: It wasn’t a dream.
[00:06:03] WJ: Have you guys seen the pairs cloning video?
[00:06:06] MN: No.
[00:06:06] WJ: Oh man! We’ll have to include a link in the show notes, because it’s hysterical.
[00:06:10] DA: I’m going to click that link, for sure.
[00:06:15] MN: There are roles.
[00:06:15] WJ: There are roles. I mean, typically, you do driver-navigator and one person is driving. They are person with their hands on the keys. Then the other person is navigating and they are trying to keep the big picture in mind and make helpful suggestions, keep track of things that need to be investigated later. Sort of like an external hard drive for the driver who’s acting more like RAM.
[00:06:46] DA: Right. Just like navigating someone on a car. It’s a skill. There are ways to do it poorly. Telling someone to turn right at the turn, that’s not going to help, because you won’t have enough reaction time to do it, or it’ll be jarring, or like telling someone like how to move every minute detail of their car, “Hey! You should get in the left lane and activate your blinker and go at this speed,” whatever. They would just be like backseat driving at that point. You have to trust that the base mechanical function of like writing the code and getting the thing done is going to be completed by the driver.
[00:07:28] MN: Okay. I’m definitely a horrible navigator, because I tell people to make the turns way too late. I’ll be really bad at navigating at pairing.
[00:07:39] WJ: Actually, sometimes it’s better to let the person make the mistake and then point out the mistake after they’ve had a chance to see if like – After you wait and see if they’re going to correct it on their own.
[00:07:48] MN: Then you’d be like you missed the turn and you’re like, “Now, you’ll remember next time.”
[00:07:56] WJ: Yeah. The metaphor breaks down a little bit.
[00:07:59] DA: What William is saying is like when someone is writing a method, let them finish before you go after every single thing that they’re typing.
[00:08:11] WJ: Right. If they make a typo, they’re probably used to making a typo, finishing a thought, going back and fixing it, because that’s their normal workflow when they’re working solo. To interrupt that flow and be like, “Fix it now!” is really disruptive.
[00:08:27] MN: Yeah. It’s like you spell return wrong. Go back and fix it. You’re like, “Well, I was going to get to that. I can see the squiggly line kind of thing.
Do you guys know of any other tools that – I mean, the driver has a keyboard and mouse. That person is occupied. The navigator is just hanging out. Is that what’s happening? Just watching the driver punch keys looking at him at the side of his face.
[00:08:52] DA: Ideally, they have some snacks.
[00:08:56] MN: Okay. So the navigator is a snack lord.
[00:08:58] DA: Yeah. Well, that can help too, because you can give them a chicken sandwich or something, get them Wendy’s chicken sandwich. Pass it over the driver.
[00:09:11] MN: Yeah. Let them take a bite.
[00:09:14] DA: Keep their eyes on the road.
[00:09:15] MN: Exactly. That’s important.
[00:09:16] DA: No. Yeah. William mentioned, the overarching goal of like what is trying to be accomplished, like find sometimes is helpful as a navigator to like write down on a card when something comes up that needs to get done and then decide together what that thing is that we’re doing right now.
Maybe something comes up and we’re like, “Oh! We should think about this, but let’s try to focus straight ahead and get to the end of this particular task.”
I know for personally, when I work solo, I think one of the things that really helps for me with pair programming is just that extra focus on getting to the smallest goal as supposed to like kind of picking up little tiny pieces of things as you go and like kind of not saying true to the best practices or the form.
[00:10:20] MN: All right. Cool. We know what are some of the things we can do to pair, al right, and the roles down packed. But I’m going to ask the next question, why? William mentioned before, it’s two people thinking about one problem. How is it different when a person, a single developer works on something and then another person looks at it at a pull request and a pair review. Those two individuals could be working on two separate things and never view each other’s work when the PR is up. Do you guys have any thoughts on that as to why we need to have two people on one problem , where we can have two people on two problems?
[00:11:07] DA: Sometimes you can end up in a situation where the code gets to code review and there’s some flaw and it needs to be reworked, or there’s some suggestion that the other developer has like related to style or structure or implementation and you’re just going to go back to this drawing board. If those support pairing, then you wouldn’t have to do that. You wouldn’t have to do rework. You wouldn’t have that waste.
[00:11:36] MN: Right. It’s like immediate feedback, because that person is sitting right next to you. You can talk to that person to talk about the grand scheme of things of this feature rather than waiting to the very end in a pull request where they could have had a completely different suggestion that would cause you to reduce some of that work.
[00:11:56] DA: Right. Yeah, exactly the idea of feedback is like really crucial to the practice of pair programming. You have to be like very vocal and communicate those concepts and have a give and take and exchange, because otherwise you are just sitting next to each other and not collaborating. That’s like really one of the core things with extreme programming, which is a big champion of pair programming.
[00:12:25] MN: So it’s like fast feedback that you get from an individual who’s sitting right next to you versus waiting till the very end of the poll request. There’s more people kind of know what this feature is going to do, because it’s not just one person who worked on it. It’s now two people.
[00:12:41] DA: Oh, yeah. Totally. There are lots of plus factor.
[00:12:46] MN: And people learn. I guess when you are pairing with someone else, you may learn a thing or two rather than working by yourself and getting this feature done. I imagine that’s another reason.
[00:12:55] DA: Yeah, you may know one way of doing a thing or one workflow by collaborating closely with someone where you’re actually like really intimately sharing your editor and everything on all keyboard and going through the whole process of programming, then you can pick up little, small tidbits that help you work better along the way.
[00:13:21] MN: Do you find that you collaborate better because you paired with someone on the team or pair with people off and on the team versus times where you did not pair?
[00:13:31] WJ: I think that pairing regularly builds social bonds, and that improves collaboration overall. It’s like if most of the people on your team are just people who work nearby, you don’t really get to know them. You don’t really get to trust them the way you do when you are actually actively collaborating for extended periods of time on things that you have to ship together.
When you have that really tight working relationship, I think the social bonds gets stronger. Then just in general, when you’re working together, things are easier and you’re more likely to grab a coworker and say, “Hey, can you help me out with this thing? Let’s go over to the whiteboard.” Because you trust them and you know where their expertise lies and you’ve seen them help you with things before. So you know what that’s like.
[00:14:23] DA: Yeah. I guess like every developer kind of brings to a situation a different background. Even if you are a new developer, the things that you learned along the way to becoming a new developer are different than the things that someone who’s a senior developer or has been doing it for a longer time or been at this company for a longer time knows. There’s good opportunity for cross-pollination both ways where the person who’s more experienced in the codebase can give some context about how it’s structured or what style is preferred. Even a person who’s like new to the code may have different experience. They may have more backend experience and advice someone who’s like not as experienced in backend like, “Oh, hey! In general, you might want to consider this alternative.”
[00:15:17] MN: Right, or like I think what I find in my life now is that other people have more time. So they can do research on like cool things that we can do to solve a particular problem. You wouldn’t know that if you weren’t pairing with an individual, because you have your own set of tools that you would have implemented into set codebase, but Bobby may have seen like a cool new thing, some new hotness that we can introduce to help with this problem that we’re doing.
[00:15:48] DA: Oh, totally! Yeah. Hooks came out and I was like exasperated. I was like, “I don’t want to learn this. This is crap.” But then like – Then someone on my team was like, “This is so cool. I want to learn this and figure how to use it.” Then they did and they shared that knowledge me through pairing. I’m like, “Okay. I get it.
[00:16:09] MN: I could see why.
[00:16:12] DA: Yeah.
[00:16:12] WJ: Yeah. I think people are just hardwired to learn by observing someone who already possesses that skill. Going back to the days of Guild.
[00:16:24] DA: Right, or caveman. Simon says.
[00:16:29] WJ: Apprenticeships, although I don’t know. That makes it feel a little bit more hierarchical than it actually is.
[00:16:35] DA: Right, but it is like learned by doing.
[00:16:37] WJ: Yeah.
[00:16:38] MN: Do you find work more fun?
[00:16:40] WJ: Oh, yeah. Absolutely. I mean, you get to be buds. You start high-fiving every time your test passed. It’s a good time.
[00:16:47] DA: Just so many high-fives.
[00:16:48] WJ: I mean, it can also be really stressful if you’re not getting along with your pair.
[00:16:51] DA: Or if you’ve got high-fives.
[00:16:54] WJ: I just keep missing.
[00:16:55] DA: Just look at the elbow.
[00:16:56] MN: I don’t understand that trick. That doesn’t work. I don’t get it. Someone’s going to have to tell me what this whole look at the elbow thing is. When you do, I’m still not going to get it.
[00:17:06] DA: I’m still not going to get it. Just letting you know.
[00:17:06] WJ: We’ll do a little bit of like learning by doing.
[00:17:09] MN: We’ll pair on it?
[00:17:09] WJ: We’ll pair on it.
[00:17:10] MN: Oh my God! We’re going to pair, guys. I’m sure that there are many individuals who may identify as introvert. Do you feel like introverts would have a good experience with pairing or not?
[00:17:26] WJ: I think so. I think most introverts enjoy one-on-one interactions a lot more than group interactions. So like to me pairing falls into a pretty introvert friendly activity. I mean, I think that anybody who’s going to be exhausted if you pair all day, like 8 hours a day straight. Your voice literally gets tired.
[00:17:48] MN: You talk for 8 hours, which is not often something you may do.
[00:17:52] WJ: That’s tiring for anybody.
[00:17:53] MN: Right. Unless that’s a job where you talk for 8 hours, but even then, that might be tiring.
[00:17:58] DA: I imagine this is just – It’s fun times for someone who’s an extrovert, because they got to talk to someone and interact with people at the workplace, and that’s part of their job.
[00:18:11] MN: Yeah. Pairing, all right. I could see a lot of people want to pair in stuff, because I’ve never done it before. No, not at all. Not at all. We'll have to go back to the tape on that. I imagine that like when you are working and pairing with another individual, it definitely keeps the both of you in check to ensure that you both are focused.
[00:18:35] WJ: This is my favorite part of pairing, is that you’re constantly focused. There’s really no room for distraction, because the other person is going to notice, “Oh! He’s checking email.” We’re on the same machine. I can see –
[00:18:51] MN: Yeah. I see that tab was open.
[00:18:52] WJ: Right, and it forces you to take breaks, and then you start planning the breaks because you want to coordinate. It’s like, “Okay, both of us do have to check email. That’s a real thing. So we’re going to do a pomodoro break or whatever, where we take 5 minutes, we’ll go both to the bathroom, check email, whatever you need to do, and we’ll meet back here. That sort of break regulation just makes you much more productive. It’s like when you take a break, you never have to worry about getting out of control, because you’ve got somebody there holding you accountable. It’s going to meet up with you at a specific time.
You also end up more focused, because you are taking regular breaks. A lot of people, they just get stuck and they feel like they can’t take a break or they shouldn’t take a break or they just forget to take a break, and then you burn out, and then you’re fried and it’s only 3:00 in the afternoon.
[00:19:37] DA: Then what do you do? You get another cup of coffee and then you’re going to drink that coffee and then be super jittery by 8PM, and then you won’t be able to sleep and then you’ll have a horrible morning the next day. I’m not talking from experience, I promise.
[00:19:50] WJ: You’ll be even less productive and less able to focus and it’s a vicious cycle.
[00:19:53] DA: I promise, I’m not talking from experience.
[00:19:56] MN: We did mention that this was talk, meaning that we’ll have more conversation on pair programming. I think the next steps that we would talk about, because I imagine now I’m a pro since I just heard this episode and had this conversation with you guys. Challenges that may arise, including the one of being tired and drinking coffee and then wrecking the night and the morning after.
[00:20:18] WJ: It’s a good foreshadowing.
[00:20:21] DA: Yeah, you may need some expert strategies.
[00:20:24] MN: Yeah, and we got them here at the Rabbit Hole. Follow us now on Twitter @RadioFreeRabbit so we can keep the conversation going. Like what you hear? Give us a 5-star review and help developers just like you find their way into the Rabbit Hole, and never miss an episode. Subscribe now however you listen to your favorite podcast.
On behalf of our producer extraordinaire, William Jeffries and my amazing cohost, Dave Anderson, and me, your host, Michael Nunez. Thanks for listening to the Rabbit Hole.
[END]
Links and Resources:
