Pair programming is an agile software development technique in which two programmers work together at one workstation. If you’ve ever worked in part of a pair programming duo, you’ll know that it can easily be equated to the intimacy of spooning or child-rearing. Pair programming can be an intensive, illuminating, and challenging partnership that at some point in your career, you’re going to experience. This is why we’ve decided to dedicate today’s show to talk all about it…
In this episode, we debate exactly what constitutes pair programming, the different ways in which it can be done, establishing personal space boundaries, and the two archetypal roles that pairs usually take on. Pair programming has many benefits. Mainly that it boosts efficiency, improves social bonds within a team, and makes programmers expert high fiver’s. Here, we also share our own personal experiences with pairing and how it fosters learning through doing and harnesses a supernatural ability to focus. If you’re looking for some tips for driving or navigating your next pair programming experience, this is the episode for you!
Key Points From This Episode:
Transcript for Episode 141. Pair Programming Advanced
[INTRODUCTION]
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast in fantabulous Chelsea, Manhattan. I’m your host, Michael Nunez. Our co-host today.
[0:00:09.8] DA: Dave Anderson.
[0:00:10.8] MN: Our producer.
[0:00:12.0] WJ: William Jeffries.
[0:00:12.0] MN: Today, we’re talking about Pair programming and it’s going to be a series because we’re going to have a lot to talk about.
[0:00:19.0] WJ: Got a lot of thoughts.
[0:00:19.9] 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.
[0:00:28.3] WJ: Got to do a reboot.
[0:00:29.2] MN: Of talking about all the content, you got to bring it back baby, let’s go.
[0:00:35.8] DA: We got a bigger budget.
[0:00:36.2] MN: We got a bigger – microphone’s sound a little better. You know, everything is good.
[0:00:40.8] DA: More explosions.
[0:00:43.4] 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?
[0:00:52.5] WJ: That is a tough one. It’s kind of hard to define. I think that like, I would say, when you’re pairing on something, you have two minds working on one problem.
[0:01:04.8] MN: Okay.
[0:01:06.1] DA: That’s a pretty good way of putting it.
[0:01:08.5] WJ: Yeah, I think there’s like, there are a lot of edge cases where people are like, “But is it pairing if you do X? What if we split a ticket frontend, backend, that’s not really pairing?”
[0:01:17.2] DA: What if we split a sandwich for lunch? Is that pairing?
[0:01:20.9] MN: No, I want my other half of the sandwich too, thank you very much.
[0:01:25.3] DA: What if you order a soup and a sandwich. Half a soup and half a sandwich and then you eat the soup and I eat the sandwich?
[0:01:31.7] WJ: Well I mean, somebody did think about how to pair the soup and the sandwich, you know?
[0:01:36.5] MN: And that person is crazy, I want a whole soup or a whole sandwich. But taking two minds and putting them to work on one problem.
[0:01:47.9] WJ: Yeah, I think normally, like the classical pair programming exercise would be two developers who are both working on the same machine together on the same problem. You might – maybe you have two monitors, two keyboards, two mice, that would really be ideal.
[0:02:02.9] MN: That would be the dev setup, yeah.
[0:02:04.0] WJ: Yeah, it’s ideal. Into one laptop and everybody’s – both people are working on the same code at the same time. There’s like one curser.
[0:02:14.6] DA: But that’s more of like an ergonomics and comfort thing. You can also pair like with one person on the keyboard and monitor and then the other person like hunched over their side like just kind of leaning into their personal space.
[0:02:26.1] MN: Yeah. Those are the greatest pairing stations… When you're like breathing down someone’s neck.
[0:02:34.8] WJ: You could use Two Probe. Two Probe being a fantastic successor to Screen Hero which was very tragically murdered by Slack.
[0:02:43.3] MN: But for ergonomics’ sake, we used two of the same tools.
[0:02:49.5] WJ: Yeah, I’ve seen people like pass the laptop back and forth which is just such pain.
[0:02:54.3] MN: Yeah.
[0:02:55.2] WJ: I mean, I guess that works, it is still pairing, it’s just a pain.
[0:02:59.8] DA: Right, it can be like harder to follow the thread if you don’t have like the second monitor or what have you.
[0:03:06.1] MN: But it’s still possible, right? If you have one wide-screen monitor, one keyboard, one mouse, one machine, it is still very possible to pair.
[0:03:14.8] WJ: Right, yeah. As long as you're both working on the same problem at the same time.
[0:03:18.1] MN: Right.
[0:03:18.8] WJ: I think other edge cases like 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?
[0:03:31.4] MN: No, I don’t think so.
[0:03:33.3] WJ: I agree.
[0:03:34.1] DA: You’ve never heard of pairing before.
[0:03:34.1] MN: I’ve never heard of that pairing before but that just sounds like I ask Bobby for help. He came by and says, “Yo, change that,” and then left.
[0:03:41.1] WJ: Yeah, exactly. But then you get into the grey area where it’s like okay, well what if they stay for an hour? Okay, what if they stay for like a day? Like all day.
[0:03:50.4] MN: Okay.
[0:03:50.9] WJ: All right, there it sort of begins to blur a little.
[0:03:54.5] MN: Right, I mean, is pairing just someone there sitting next to you? As you do all the work?
[0:04:00.6] DA: I mean, I think pairing implies like a shared ownership of the result where there’s going to be some give and take between the two people like ideally, the end result will be something that neither developer would have written on their own. Like the thing that comes out of it will hopefully be better than what those two developers would do, or the results of the shared context that both developers have.
[0:04:25.0] MN: I see. By having two minds on a particular problem, will help them come up with a much better solution than one individual working on a set problem.
[0:04:34.7] WJ: Right, it’s like, the bottleneck isn’t that you can’t type fast enough, right? When you’re solving these engineering challenges, it’s never that like, “If only I could type faster, then all of this would be done so much more quickly.” The problem is you have to think through and understand the problem and then come up with solutions. So, 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.
[0:05:05.9] MN: Right. That’s more like, how do you pair, are there different roles that people take? What are the names of set roles?
[0:05:15.8] DA: It’s a pop quiz.
[0:05:18.5] MN: It’s because I don’t’ know, I have no idea what pairing is.
[0:05:22.1] WJ: You're really catching on quick here, you just intuited that there are roles and that’s wonderful.
[0:05:26.7] MN: I mean, I don’t’ know, I can’t imagine a scenario where both me and the other person are typing really, as we get the work done twice as fast.
[0:05:35.9] DA: Yeah, that’s true, you can’t just like take like your role as left half of the keyboard and mine is the right half of the keyboard.
[0:05:41.9] MN: There’s a meme somewhere on the Internet where some TV show does that. That’s how me and my pair – I don’t’ know about pairing but II think I see people do that all the time.
[0:05:51.2] DA: It was in a dream.
[0:05:52.4] MN: Yeah.
[0:05:53.6] WJ: Have you guys seen the pair spooning video?
[0:05:57.1] MN: No.
[0:05:57.4] WJ: Oh man. It’s hilarious.
[0:05:59.5] DA: What?
[0:06:00.1] WJ: Yeah, we’ll have to include a link in the show notes because it’s hysterical.
[0:06:03.6] DA: I’m going to click that link for sure, right?
[0:06:08.1] MN: There are roles.
[0:06:08.8] WJ: There are roles. I mean, typically, you do driver navigator and one person is driving, they’re the person with their hands on the keys, and 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, act sort of like an external hard drive for the driver who is acting more like RAM.
[0:06:37.2] DA: Right, just like navigating someone in a car, it’s a skill, there are ways to do it poorly, like you know, telling someone to turn like right at the turn, that’s not going to help because like, you won’t have enough reaction time to do it, or it’d be jarring, or 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 the speed,” and whatever. That would just be like backseat driving at that point. Keep the trust that like, the base mechanical function of writing the code and getting the thing done is going to be completed by the driver.
[0:07:17.7] MN: Okay. I am definitely a horrible navigator because I tell people to make the turns way too late. I’m pretty sure I’ll be really bad at navigating that pairing.
[0:07:29.6] 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, like a typo.
[0:07:38.8] MN: We wait for them to like –
[0:07:40.2] DA: You missed the turn and you're like, “Now you’ll remember next time.”
[0:07:47.0] WJ: The metaphor breaks down a little bit, yeah.
[0:07:49.5] MN: I imagine you’re – what William is saying is like when you know, someone is writing a method, let them finish before you go after every single thing that they’re typing.
[0:08:00.6] WJ: Right, if they make a type, they’re probably used to making a typo, finishing a thought, going back and fixing it because that’s their workflow when they’re working solo. To interrupt that flow and be like, “Fix it now,” is really disruptive.
[0:08:17.5] DA: “You spelled “Return” wrong, go back and fix it,” and you're like, “Well, I was going to get to that, I can see the squiggly line,” kind of thing.
[0:08:24.5] MN: Do you guys know of any other tools that, I mean, like 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 them at the side of his face or –
[0:08:42.7] DA: Ideally they have some snacks.
[0:08:44.3] MN: Okay. The navigator is the snack lord.
[0:08:48.3] DA: Yeah, well you know, that can help too because you know, you can give them a chicken sandwich or something, get them a Wendy’s chicken sandwich, pass it over to the driver.
[0:09:01.0] MN: Yeah, let ‘em take a bite.
[0:09:03.0] DA: Keep their eyes on the road.
[0:09:04.4] MN: Exactly, that’s important.
[0:09:07.1] DA: Yeah, like William mentioned, there’s like the over-arching goal of what is trying to be accomplished, you know, if you find it’s sometimes helpful as a navigator to like, you know, 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, “We should think about this but let’s try to focus, you know, straight ahead and get to the end of this particular task.” I know for me, personally like, 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, not saying true to the best practice and the form.
[0:10:06.4] MN: All right, cool. We know what some of the things are that we can do to pair, all right, and we got the roles down packed. But I’m going to ask the next question, why? William mentioned before, you know, it’s two people thinking about one problem. How is it any different when a person, a single developer works on something and then another person, you know, looks at it at a poll request and a peer review. Those two individuals could be working on two separate things and then review each other’s work when the PR is up.
You guys have any thoughts on that, as to why we need to have two people on one problem when we can have two people in two problems?
[0:10:48.3] DA: Sometimes, you can end up in a situation where the code gets to coder 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 implementation and you’ve just got to go back to the drawing board.
If those people are pairing then you wouldn’t have to do that, you wouldn’t have to do rework, you wouldn’t have that waste.
[0:11:16.5] MN: Right, it’s like immediate feedback because that person is sitting right next to you and you can talk to that person to talk over – the grand scheme of things, of this feature, rather than waiting to the very end in the poll request where they could have had a completely different suggestion that would cause you to redo some of that work.
[0:11:36.8] DA: Right, yeah, exactly, the idea of feedback is like really crucial to the practice of pair programming, you have to be very vocal and communicate those concepts and have a give and take in exchange. Because otherwise, you are just sitting next to each other and not collaborating.
That’s really one of the core things with the extreme programming, which was a big champion of pair programming.
[0:12:04.9] MN: It’s like fast feedback that you get from an individual who is sitting right next to you versus waiting to the very end of the poll request. There’s more people that 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.
[0:12:20.6] DA: Yeah, totally, there’s lots of bust factor.
[0:12:24.1] MN: People learn, I guess when you are pairing with someone else, you might learn a thing or two rather than working by yourself and getting this feature done. I imagine that’s another reason.
[0:12:33.5] DA: Yeah, you may know one way of doing a thing or, you know, one workflow, by collaborating close to with someone where you’re actually like, really intimately sharing your editor and everything on the whole keyboard and going through the whole process of programming then you can pick up like little small tidbits that help you work better along the way.
[0:12:58.2] MN: Do you find that you collaborate more with your team members because you paired?
[0:13:01.9] WJ: I think that pairing regularly builds social bonds and that improves collaboration overall. 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 get stronger and then just in general when you’re working together, things are easier and you’re more likely to grab a coworker and say like, “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. You know what that’s like.
[0:13:52.6] DA: Yeah, I guess every developer kind of brings to the situation a different background, even if you are a new developer, the things that you learned along the way to becoming a new developer, different than the things that someone who is a senior developer, or has been doing it for a longer time, or been at this company for longer time knows. There’s good opportunity for cross-pollination both ways, where the person who is more experienced in the code-base can get some context about how it’s structured or what style is preferred.
Even the person who is like new to the code may have different experience, they may have more backend experience and advise someone who is not as experienced in backend like, “Hey, you might want to consider this alternative.”
[0:14:44.2] MN: Right, or I think what I find like in my life now is that other people have more time, so they can do like research and like cool things that we could 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 code base but Bobby may have seen like a cool new thing, some new hotness that we can introduce to help with this problem that we are doing.
[0:15:14.5] DA: Oh totally, like Hooks came out and I was like exasperated, I was like, “I don’t want to learn this crap,” but then someone on my team was like, “This is so cool. I want to learn this and figure out how to use it,” and then you know they did, and they shared that knowledge with me through pairing and I’m like, “Okay I get it.”
[0:15:36.2] MN: I could see why.
[0:15:37.0] DA: Yeah.
[0:15:37.7] WJ: Yeah. I think people are just hardwired to learn by observing someone who already possesses that skill, like going back to the days of guilds.
[0:15:49.1] DA: Or cave man. Simon says.
[0:15:55.4] WJ: Apprenticeships, although I don’t know that makes it feel a little bit more hierarchical than it actually is.
[0:16:00.9] DA: Right, but it is learning by doing.
[0:16:03.5] WJ: Yeah.
[0:16:04.3] MN: Do you find work more fun?
[0:16:06.2] WJ: Oh yeah absolutely. I mean you get to be buds, you start high fiving every time your test passed, it is a good time.
[0:16:12.1] DA: So many high fives.
[0:16:13.0] WJ: I mean it can also be really stressful, like if you are not getting along with your pair.
[0:16:16.5] DA: Or if you’re bad at high five’s.
[0:16:19.1] WJ: I just keep missing.
[0:16:20.2] DA: Just look at the elbow.
[0:16:21.8] MN: I don’t understand that trick, that doesn’t work. I don’t get it. So much is going to happen. Tell me what this whole look at the elbow thing is and when you do – I am still not going to get it, just letting you know.
[0:16:32.0] WJ: We’ll do a little bit of learning by doing there.
[0:16:34.2] MN: We’ll pair on it?
[0:16:35.1] WJ: Yeah, we’ll pair on it.
[0:16:35.9] MN: Oh my god, we are going to pair guys. I am 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?
[0:16:52.1] WJ: I think so. I think most introverts enjoy one on one interactions a lot more than group interactions and so to me, pairing falls into a pretty introvert-friendly activity. I mean I think that anybody is going to be exhausted if you pair all day, like eight hours a day straight, your voice literally gets tired.
[0:17:12.4] MN: You talk for eight hours, which is not often something you may do.
[0:17:16.3] WJ: That is tiring for anybody.
[0:17:18.1] MN: Right, unless that is your job where you talk for eight hours, but even then that might be tiring. Yeah and I imagine this is just, you know, it is fun times for someone who is an extrovert because they get to talk to someone and interact with people at the workplace and that is part of their job. Yeah, pairing, all right, I can see why a lot of people would want to pair and stuff because I’ve never done it before. No, not at all.
[0:17:44.5] DA: Well, I think I’m going back to the tape on that.
[0:17:46.7] MN: I imagine that like when you are working and pairing with another individual like it definitely keeps the both of you in check to ensure that you both are focused.
[0:17:57.9] WJ: This is my favorite part of the pairing is that you are constantly focused. There is really no room for distraction because the other person is going to notice like, “Oh he is checking email. We are on the same machine. I could see you.”
[0:18:12.4] MN: Yeah, I see that tab is open.
[0:18:14.0] WJ: Right and it forces you to take breaks and then you start planning the breaks because you want to coordinate and it is like, “Okay, both of us do have to check email, that is a real thing,” right? So, we are going to do a Pomodoro break or whatever. We are going to take five minutes, we’ll both go to the bathroom, check email, whatever you need to do and then we’ll meet back here and that is sort of break regulation, just makes you much more productive.
It is like when you take a break, you never have to worry about getting out of control because you got somebody there holding you accountable. Who is going to meet up with you at a specific time and you also end up more focused because you are taking regular breaks, and 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 are fried and it is only 3:00 in the afternoon.
[0:19:00.7] MN: And 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 8 PM and then you won’t be able to sleep and then you will have a horrible morning the next day. I am not talking from experience. I promise.
[0:19:13.8] WJ: You’ll be less productive and less able to focus and it’s a vicious cycle.
[0:19:16.6] MN: I promise I am not talking from experience. We did mention that this was a talk, meaning that we will have more conversations on pair programming. I think the next steps that we would talk about, because I imagine now, I am a pro since I just had this episode, this conversation with you guys, is challenges that may arise. Including the one of being tired and drinking coffee and then wrecking the night and the morning after.
[0:19:41.4] WJ: That is a good foreshadowing.
[0:19:43.0] MN: Oh yeah.
[0:19:43.4] DA: Yeah, you may need some expert strategies.
[0:19:46.7] MN: Oh yeah and we got them here at The Rabbit Hole.
[END OF EPISODE]
[0:19:50.3] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five-star review and help developers 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 co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
[END]
Links and Resources:
