There are a lot of ways pair programming can go wrong. Thankfully, it’s possible to pair well simply by avoiding pairing poorly and, by steering clear of some of the common mistakes that we outline in this episode, you’ll automatically up your chances of success! Today, on The Rabbit Hole, Michael Nunez, Sophie Creutz, and Dave Anderson talk pair programming antipatterns, from multiple disruptions to over-philosophizing, from keyboard hogging to decision fatigue. For some simple tips on how to make pair programming a great tool for knowledge sharing and team building rather than a chore, tune in today!
Key Points From This Episode:
Transcript for Episode 246. Pair Programming Antipatterns
[INTRODUCTION]
[00:00:00] MN: Hello, and welcome to The Rabbit Hole, the definitive developers’ podcast, living large New York. Rabbit roll call.
[00:00:07] SC: Sophie Creutz.
[00:00:09] DA: Dave Anderson.
[00:00:10] MN: And Michael Nunez. Today, we'll be talking about pair programming antipatterns.
[00:00:16] DA: There are a lot of ways pair programming can go wrong. Thankfully, I think a lot of the things that we talked about in our past episodes are no longer appropriate. You don't got to worry about BO. Remote programming, BO is not a problem. Don't have to spray someone down with Axe body spray.
[00:00:35] MN: Right, or even the physical space. I think, you read books or you talk about – remember touching someone else's elbow with yours? That doesn't happen anymore.
[00:00:45] DA: Right, yeah. Negotiating the constraints of the space. Having two seats next to each other and cramming in there, getting the keyboard, the ideal dongle setup. Don't need to think about it!
[00:01:02] SC: The space with good ambient lighting, not those fluorescents.
[00:01:06] DA: Right. Yeah, in an ideal world, the door, but yeah, now, we don't really have to worry about it too much. There's still sentiment out there. That, hey, like pair code programming is not great. It's not effective.
[00:01:27] SC: Yeah. We have an excerpt from someone who wrote a little manifesto against pair programming. I do think he's a bit of an outlier, this author, but some other folks do have this perception as well.
[00:01:41] DA: Yeah. I think there's a lot of the things that he talks about in this tweet that we can link to it here. I would say, a lot of the sentiment is hire drivers, not passengers. I think a lot of the things that they're calling out is ineffective pair programming or antipatterns of pair programming.
[00:02:03] SC: Right, or it's just bad logic. For instance, he claims that since you have two programmers doing work on the same keyboard, at the same time, the output of pair programming must be greater than two times the output of a single programmer to make sense.
[00:02:17] MN: Right, because that's not true. I mean, sometimes, I believe that sometimes the output may be less, and other times, it may be more, right? The idea of – the thing that comes to mind, for pair programming often has to do with the code review. If you worked in this, I've worked at a solo shop where you do a code, you put up a PR and two people have to review it. You need two approvals for this piece of work that you did. Rather than pulling people asynchronously to stop their work to look at yours, you already have one person next to you doing that as it is.
When you have someone, the first reviewer is usually the person is going to be most critical, because the second review is going to be like, “Well, the first press already did it, so that's fine. It looks great to me.” Then, move on. Having a pair reduces a lot of that, in my opinion.
[00:03:11] DA: Yeah, yeah. Also the long term trade-offs of reducing silos, evening out the knowledge among the team, and not having a bus factor. If you've hired everyone that has superpowers, and there are no knowledge gaps, then maybe that's not a problem for you right now. You so have to compensate for that. There are trade-offs that you have to make to make that knowledge available. Pair programming is one tool that you can use to reduce the bus factor or to speed up code reviews. Everything is a trade-off, but there are a lot of ways that you can go wrong with pair programming or antipatterns.
[00:03:56] SC: Yeah. Yeah. Okay. How about a for instance, passive pairing? Let's talk about that a little bit.
[00:04:04] DA: Passive pairing. I think that's one of the crux of what they were talking about here, where they don't want a passenger. They want a driver.
[00:04:16] SC: Yeah.
[00:04:17] DA: That's the idea that maybe pair programming is being on a bus where I'm sitting at the back of the bus and the person at the front is at the keyboard driving and I'm just reading a newspaper, or something, listening to music.
[00:04:32] SC: Right, but you’re on the bus together.
[00:04:36] DA: But I'm not. Yeah, I'm not making eye contact with anybody, like definitely, not.
[00:04:40] MN: Right. Telling the driver, imagine in New York City. You tell the driver what to do on the bus, like no, it’s not good. They're not going to have it. That's just how you operate on a bus; you get on and you shut up.
[00:04:55] DA: Right.
[00:04:57] SC: I feel you.
[00:04:59] DA: Right.
[00:05:00] MN: But pair programming is not like the experience of a public bus, right? It's different than that. To me, it's more – I have to explain this to someone like the words driver and navigator are vague. I mean, are weird, but remember, 40 years ago, there was no GPS to tell you where you needed to navigate. You needed to talk to a person, looking at a piece of paper –
[00:05:28] SC: To ask directions.
[00:05:29] MN: Yeah. To ask directions to go. It's like, try to do that by yourself. Sure, you can. I'm sure there were many accidents that were caused by individuals looking at a big piece of map or a road trip, but that was the purpose of the navigator. It’s like, “Oh, keep an eye on what I need to do, where I got to go, so I can focus on the road.”
[00:05:46] DA: The cartoon staple, the person driving with the map stretched across the wheel, and they're like, “Oh, no.” Then they end up in a lake or something.
[00:05:55] MN: Yeah.
[00:05:56] DA: Oh, man. Thank you for reminding me that. I feel I've just taken for granted that GPS has always existed. It was never hard. But yeah, I was thinking about that. It's like, okay, you're trying to get to a place in a car, but you don't know exactly where it is, you kind of know where it is. So, that is fundamentally the same thing as like being yes, you don't have GPS. Maybe your map is not right. You have a plan, but your map is from the 80s. They've changed the neighborhood completely. The landmarks are not the same or whatever. You haven't –
[00:06:35] SC: There’s construction. You got to take an alternate route. Then, from there, you need a whole other plan.
[00:06:40] DA: Yeah. There’s construction or maybe you drove to this area, you wrote code in this area, a year ago. They've since built an entire new system. All the landmarks that you had, are no longer there. Now, it's skyscrapers instead of farms. You're like, “Oh.”
[00:06:59] SC: Better believe it. Yeah.
[00:07:00] MN: I'll have you know, Dave, the reason why I called back to not having GPS is because I had to go to a phone repair store without my phone working. The only way I was able to do that was to print out the things. It'll be great if I had a pair. “All right, Bobby, you got to make a left on the street and then you can make a right.” I'm just looking down and going crazy.
[00:07:22] DA: Nothing better than MapQuest.
[00:07:25] MN: Yeah. Nothing. That's what it felt like. I'd time traveled to get my phone fixed. We could all agree that pairing is not just being on a bus. You’re actively speaking with the person who's driving the keyboard about certain patterns and design and features that are going on. That's a person who may not speak too much, but then you have the other side of the spectrum, someone who speaks too much or is distracted often by speaking about other things. That's definitely another antipattern that would need to be addressed, right? It's just like Bobby's distracted, on their phone, or trying to see what's happening in the office, getting pulled into meetings while y'all are pairing. I imagine that can cause some kind of –
[00:08:13] SC: Definitely interrupts the flow. Yeah, for sure. Yeah.
[00:08:16] DA: Yeah. You’re talking about distractions, external things happening on one person's side that pulls them away?
[00:08:25] MN: Right, there were once a time where we went into an office and it was easily distractible that way, but being at home, I imagine can be distracting too, right? I got a door here, but my three-year-old can get in.
[00:08:42] DA: He's coming through the wall, like the Kool-Aid man.
[00:08:44] MN: Yeah. Like the Kool-Aid man. Some distractions I got to handle, but that's the thing you focus. I can control certain distractions, so I can make sure I don't have my phone in front of me with Twitter open and stuff like that.
[00:08:57] DA: Yeah. Sometimes I feel distractions can almost – any pattern can almost be more painful than passive pairing, because at least when it's passive pairing, there's a resignment or it's like, okay, I'm just doing this by myself, but when you're trying to engage with the other person or you're expecting some feedback or whatever, and you're just left hanging then –
[00:09:20] SC: Or if you don't even know why, right? Like you just you're talking but you hear no response.
[00:09:25] DA: Right. Yeah.
[00:09:26] SC: It could be, because they're distracted, but you don't know why, because you don't have that feedback, right? Especially if it's just audio, the way that you're pairing.
[00:09:33] DA: Yeah. Although if Gio comes crashing through the wall, that's a distraction for everybody.
[00:09:39] SC: Then then you'll know. Yeah.
[00:09:40] MN: Yeah. I mean, I just have him, it becomes a fishbowl and we, the three of us pair if I'm pairing with someone. Gio’s going to learn how to program I need them to start collecting a paycheck very soon. That's the – through osmosis of pairing he's going to learn how to program –
[00:09:54] DA: Right, yeah.
[00:09:56] MN: It’s just that I have to keep repairing that wall, because he keeps destroying.
[00:10:01] SC: I'm curious, in terms of distractions. Do you think something like having Slack open and just seeing your Slack messages or responding to them while pairing? Is that something we should try to avoid that kind of distraction?
[00:10:15] MN: I think it's a start for sure. I would say, what I remember in the past was that the navigator was often interoperable so that the pair can, the driver can continue doing something and the navigator could essentially shoe someone away or get someone's request and then keep it for later. I think Slack is just way – I don't know, you're more inclined to get rid of that notification icon that's red. Then go and read the message. It may not be anything relevant to the thing that you're working on, which is [inaudible 00:10:48].
[00:10:49] DA: Yeah.
[00:10:49] MN: I'm like up at the air.
[00:10:51] DA: I think that's interesting. Yeah, like using the distraction or the navigator as a shield for distraction, tactically push it away. I do wonder, at least for me, I always find myself just getting sucked into it. It's tough, but I could see the argument where you could be pretty disciplined about it, and do that to keep things moving forward. I do think the main focus needs to be on the work.
I think another thing that can be a distraction too, is like, okay we're trying to look ahead or do research, sometimes I might do a quick Google to find an article, but I'm going to try to bring the attention back to the joint work if possible, at least to share the article with them, so we can both read it and then come back together, or read it together, if it's something that's possible.
[00:11:50] SC: Yeah. There's another form of distraction, too, which is when do you ever experience you're pairing with someone and you just start philosophizing, right? You just start talking about the nature of the universe, 42, physics, birdseed, whatever it is.
[00:12:10] MN: I think, there's a lot of antipatterns that are, I feel this article was written for me for sure, that was definitely one of my big issues. It would just be if it's a Monday we'll talk about how was your weekend, what you do? And I just want to talk about the things that I did. It's like, “No, no, no, Mike. We got to be focus – this problem that we have here.”
[00:12:33] SC: We got to get to work, but at the same time, I think some of that is healthy.
[00:12:37] MN: Right.
[00:12:37] DA: Yeah. I think that's the most common form that I've experienced this, is when you have a particular task or it's a user is part of an organization. Then you're like, “Okay, well, fundamentally what is an organization like? Are there other forms of them? Are there different kinds of things?”
[00:12:58] SC: Is it a learning organization? How is it structured?
[00:13:00] DA: Yeah, exactly. Is there nested organizations? Do I need to do this or that?
[00:13:05] SC: Or the properties of the organization? Are they also applying to the sub-organization?
[00:13:11] DA: Yeah. But maybe your story is just login, so you just got to get that person in there, get them into the software. You can make some assumption that's wrong for now about the organization and wait until you run into that and change it.
[00:13:27] SC: Yeah. It's okay to not know everything in order to implement something, I guess.
[00:13:34] MN: I mean, but then you always got to tie in that user to the beginning of the universe. Like how do we ensure that this user goes in – then I'm trying to philosophize again, going back to that, that's my problem. Philosophizing, way too much, some bike shedding, but bike shedding on the universe, I guess.
[00:13:50] SC: Right. It’s 42, let's just like, let's call it one and done.
[00:13:56] MN: I think that's probably why the machine did that, right? It's just like, “Yeah, let's move on. I've been rocking this for – what is it – for millions of years?”
[00:14:05] DA: Yes, yes, yes.
[00:14:07] MN: Yeah. 42 is the answer. I think I just going to use that as my deflective hypothesizing brain to just continue on and stay focused. There is another antipattern, and it is the keyboard hogging. I apologize to anyone I have paired with where I've relapsed to keyboard hog. As a young developer, I used to always want to reach for the keyboard and type and my pair had to sit me down, and be like, “Mike, as a navigator, try not to reach for the keyboard.” I used to just disconnect my keyboard. You know what? This is a problem for everyone when I am navigating, removing it, and taking that out, or I'm sitting on my hands, but then I couldn't write anything, so I had to get used to it. So, don’t be a keyboard hogger. I’m talking to myself.
[00:14:53] DA: Right. I guess that's like, forcing the other person into a more passive role where they're not able to really contribute as much. I mean, I guess this could even be where maybe there is some contribution, but you're not really changing roles at all. We do consider changing roles with some [inaudible 00:15:14] needs to be helpful to the processes to keep it even out.
[00:15:21] SC: One I think too, in a virtual space, right, where you're not in a room with the same physical keyboard then the dictating pairing is what is the equivalent, right? Because when you have someone who's dictating, but they're the navigator, then essentially they're really the driver, because they're saying type this, type that, do exactly this, click this scroll down, scroll up etc. that makes the driver become more passive as well.
[00:15:48] MN: It’s an interesting, interesting look at that. I guess, the question that I have, I mean, my example is, when I paired in a physical space, do you all subscribe to the idea that the person, the host of the screen share is the driver? Because I feel like that is usually the case. I know I'm less likely to type if someone starts the tuple conversation, right? Because I can. I can type, but it just feels weird, because I know it's not my machine that’s doing that.
[00:16:19] SC: I think classically, it's the person who's typing, that's the driver, right? So that's usually also the person who's screen sharing.
[00:16:27] DA: Yeah. You can, with the software Tuple or some other ones out there. You can control more aspects of their computer, but it's still not perfect. There's still some lag. It's there as an option to use. I think the fundamental path that we normally follow is like, “Yeah, I'm going to push up the code, you're going to pull it down, we're going to start running on yours, and test it over there.”
I think in another forum – I'm sensing a theme, where this is all about becoming more passive in the pairing process, different forms of being passive. An interesting form of being passive, it's just being a yes man, where or, it’s 2022 is just a yes person, I guess, like it's anybody.
[00:17:13] SC: Yes, you’re right.
[00:17:16] DA: You could just say, “Yeah, that sounds good.” You're checking the box of engaging or talking or whatnot, but it may not be helpful or constructive.
[00:17:29] SC: Yeah. It's not particularly collaborative, right?
[00:17:33] MN: I mean, but if you do agree and you can just try to contribute more than just saying, “Yes.” Or “I agree.” Try to bring up a discussion. “I agree because” and then you can go in and do that, so that it sounds like your pair is aware that you're understand what's going on, as opposed to be like, “Yeah, that's fine.” Yeah, just rubber stamping everything, because it's just that y'all could then strike a conversation.
I think the opposite of that is, I guess, the unnecessary – I mean, may not be considered unnecessary debates during pairing, but you don't always have to say no to everything either if it's not necessary to say no, right? There are some things that you can just be like, “Okay, that makes sense.” Other things like, “No, I want to have a discussion about it.”
[00:18:20] SC: Yeah. I guess this is like a watch out for bike shedding thing.
[00:18:25] DA: Yeah. Pretty similar to philosophizing, but maybe philosophizing might be one sided where it's like, oh, but then this may be more antagonistic, where it's like, there must be a winner. We all settle this through armed combat, or – So I think this again like comes down to you may have to just make an assumption and come back to it at some point.
[00:18:52] SC: Yeah. I guess the yes person could actually be a response to the unnecessary debates, right? Because if you just agree then there's no basis for debate, but then again, I think also what maybe informs the yes person phenomenon is decision fatigue. This is something that happens in the teaching profession, too, because you have to make so many decisions every day, right? How do I respond to this behavior, this behavior, this behavior. What I do now? This the plan didn't go as I expected. I have to shift it.
I think pairing is that, too. You're constantly making decisions. Should we write the function this way? Should we write this function? Should we write this test? Should we write this other test? Should we put the test inside of a describe block? Should there be a before – just decisions, every moment, and I think that that can lead to decision fatigue. Something to watch out for, I guess.
[00:19:53] MN: No, that makes sense. I agree, because if you’re – by the time you may – somebody has ended – the issue is that they could interesting problem that requires a conversation later. Since you've had that fatigue, then you wouldn't dive into that conversation. I didn't want to end with yes, and then continue on, so that's, I really tried to do that. [inaudible 00:20:13] mentioned, I don't want to be the yes person in that conversation. I really do agree. I think that that is one issue that we have to be careful.
I think one of the things, I want to loop back into the thread, the Twitter thread, and this person talks about pairing is a one-to-one way of sharing knowledge. He writes how there are different ways to share knowledge, whereas one-to-end. I think he uses examples like code review, I think we've had a discussion about code review and how that could be slowed down, or it's documentation. Now, I'm sure we're all aware that documentation gets old really fast. It can be a way to share information, but someone has to maintain that document and oftentimes it falls through the cracks. Have you all had that experience before with documentation?
[00:21:08] DA: Yeah. I mean, I prefer for documentation to be a guiding thing where it's going to point you towards the source of truth, the truth is, someone said this the other. I really liked it. It's like, “The truth is in the code” –
[00:21:22] SC: Oh, that’s deep.
[00:21:27] DA: So deep. I love it. Like, just let’s all get tats. Truth is in the code.
[00:21:33] MN: The truth is in the code.
[00:21:35] DA: Yeah. The truth is out there, making a 90s, another 90s reference, X-Files, but the truth is actually in the code, so they were looking in the wrong place. Yeah, if you can provide a scaffolding for understanding how to jump into the code at eye level then I think that's, that's really helpful.
[00:21:56] SC: Yeah. But like you pointed out, Dave, people over processes, relationships over documentation.
[00:22:03] MN: Yeah. To have your team maintain a document where, when the source of truth is the code, it's better to just look at the truth together, as a pair, is what I believe.
[00:22:18] SC: What if, you and your pair are actually just partners in crime, so speak?
[00:22:25] MN: The partners in crime pair. I feel this happened a lot more in person, especially in offices that have ping pong tables, where it's just like, “Yo, let's finish this. I'll write this, oh, let's write this test, and then run the entire suite, which takes seven minutes, so we're going to go and play another match.” It's like, “Oh, no. Come on. I want to finish this. I don’t care about ping pong.”
[00:22:48] DA: I guess that happens when you're also – sometimes it can be helpful to have a longer break. I feel like, when you get that thing in Pomodoro, if you're doing that, and you're like, oh, a five minute break turns into a 10 minute break, turns into a 15-minute break. It's like, “It’s fine.”
[00:23:09] SC: It's fine. This is fine. Or there's someone who has a bad habit. They like to push to master, which sometimes is fine. There’s use cases where that are all right, I suppose, but –
[00:23:21] MN: You all love driven development, let’s do it.
[00:23:24] SC: Right. The YOLO happens with a pair.
[00:23:30] MN: Oh, my God. Yeah, no, then put them like your other pairs and holding you accountable so you have to let it slide. There's got to be at least one person where it's like, nah, I don't want to call that person like the –
[00:23:45] SC: The maverick.
[00:23:44] MN: Like the other goody two shoes and things, but one person got to be the responsible like, “Nah, Bobby, let's not do that. Let's, let's write that test.”
[00:23:52] SC: Yeah.
[00:23:52] MN: Like, “We definitely should figure out how to do this.” It's not like calling the other person out and then not writing tests. It's just sometimes you want to go play a game of ping pong. So, either you finish this really fast or take a long break and stuff like that. So, be careful with the partner in crime.
[00:24:09] SC: In pairing is a social situation after all, so there can be some social influence in a certain direction.
[00:24:17] MN: Yeah, no, for sure. I totally understand if individuals were against pair programming, but I felt this person came in too hot and it sounds like this person may have given it a try and had experiences with a lot of antipattern that exists. I think that when you are aware of the antipatterns, it becomes a much more conducive way to work with your fellow peers overall. I don’t know. I just like pair programming. It makes me feel less alone and I get to bounce ideas with someone and have a conversation and get worked done together. I mean, two heads are better than one and, of every single phrase, that is the phrase that it's often said, but for whatever reason pair programming is not –
[00:25:03] DA: Yeah. For that reason and it’s just important to, I think, consider it as part of the toolkit. Maybe it's not the only tool that you're using, but it should be one of – you should consider that as one of the greater tools to get things done, reduce silos.
[00:25:22] SC: Improve your effectiveness.
[00:25:23] DA: Yeah, exactly. Yeah, keep your mental sanity.
[00:25:28] SC: You got to. Pretty essential.
[00:25:31] DA: So important.
[OUTRO]
[00:25:31] 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 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 co-host, Dave Anderson, and me your host, Michael Nunez, thanks for listening to The Rabbit Hole.
[END]
Links and Resources:
