Welcome to the Rabbit Hole podcast!
Our panelists today: David Anderson and William Jeffries.
In this great episode, we discuss the concepts and uses of pair programming, remote programming, and mob programming. Don’t worry if you’re unfamiliar with any of those terms; we’ll talk about them in more depth in the episode, and explore what is (and isn’t) cool about each one.
Just to give you a short preview to help you decide whether to tune into this episode (hint: you should!), let’s take a moment to define what we’re talking about, at least for our main focus of the episode. Pair programming is when you have two programmers working on the same task, usually at the same workstation.
This offers an incredible array of benefits compared to typical, solo work. For example, if you’re in a pair programming setup, there’s no way you’re going to be checking your email, phone, and social media while you’re working. That means you’ll be more focused; in fact, one of our panelists points out that pairing can lead to being tired (in a good way) because you’ve been so productive. Pair programming also offers great motivation to be your best, because you don’t want to let your team down by not giving 100%.
Tune in to hear more about pair programming and its benefits and potential pitfalls, and to learn about remote programming and mob programming too!
[00:52] - We hear a basic definition of pair programming.
[02:02] - What were the panelists’ first experiences with pair programming?
[03:39] - Pair programming can be incredibly valuable in that it doesn’t allow you to get distracted or lose focus the way you might if you were working by yourself.
[05:50] - We learn about the use of chess timers in pair programming. We then hear how pair programming can be valuable when you’re learning a new language.
[08:12] - Have the panelists seen Livecoding.tv?
[10:35] - The panelists move on to talking about remote programming, initially emphasizing the importance of a strong, fast internet connection.
[12:32] - If you’re pairing with someone remotely, the person who is sharing is (almost) always the bottleneck.
[13:26] - What kind of editors do the panelists usually use on their projects? They mention, for example, Screenhero, AtomPair and Floobits.
[16:47] - The problem with all of these editor plugins is that they don’t tackle the shared browser bit.
[18:46] - One of the panelists brings up an issue that happened to him in pair programming but not remote programming.
[20:02] - The panelists discuss Dvorak in more detail, explaining what it is and why it’s a good choice for people with wrist injuries, for example.
[20:55] - We hear the story of how one of the panelists inadvertently introduced a coworker to pair programming. They then talk about various modes of pair programming, particularly “evil mode.”
[27:20] - We move on to mob programming, with the panelists sharing their experiences with it. The consensus is that it’s fun because it’s so collaborative.
[30:45] - Mob programming can often be with some subset of the team instead of the entire team. Even if it’s with only three people, though, it can be helpful in breaking ties.
[34:01] - Have any of the panelists had any particularly good pairing experiences?
[39:00] - We switch to the other side of pair programming now: challenges and bad experiences working in a pair (including a story of overwhelming body odor).
[43:05] - Another resource that people should check out is the RailsConf 2014 video “I’ve Pair Programmed for 27,000 Hours. Ask Me Anything!”
Michael: Hello, and welcome to The Rabbit Hole podcast. I am your host, Michael Nunez. The panelists today are William Jeffries and David Anderson. How's it going, guys?
William: It's going well, going well.
David: Hey, great.
Michael: Awesome, awesome. Today we will be talking about pair programming, remote programming, and mob programming. And for those who are unfamiliar with any of those things, we're gonna touch on those topics and figure out what experiences we have with them and the cool aspects and the not-so-cool aspects and why we enjoy doing the pair programmings. So, let's do it.
William: So, what do we mean when we say pair programming? For the listeners who aren't familiar with that term, does somebody wanna toss out a definition or an explanation?
David: Pair programming is basically when you have two programmers working on the same task. And, not just on the same task at different workstations, but typically at the same workstation, sitting side-by-side with one monitor. Maybe one keyboard or two keyboards. That's kind of a detail. But they're both gonna looking at the same piece of code and there'll be two different roles that the two different programmers will switch between. One will be driving and they'll be writing the code, and the other person will be navigating and they'll be trying to do more of the thinking role and direct the person who is driving and look out for any pitfalls and let them know what's up.
Michael: Anderson, that's a pretty good definition, you sure you didn't use the Googles?
David: No, man.
William: I think you cheated, Dave.
David: No, I just read Extreme Programming, you know. Art of Agile, every day before I go to bed.
Michael: Yes! There you go.
William: What was your first experience with pairing?
David: So for me, my first experience with pair programming was kind of late. I did a programming retreat called Recurse Center and it's self-directed retreat and everyone works on what they want to work on. But often, people will group together for projects or for doing spikes, like small explorations about a technology. And that was my first time doing that.
Previously, I was working at a company where all the programmers were remotely distributed, so it wasn't very easy to work on pair programming. But, you know, at Recurse I first had the opportunity. And it was a really awesome experience to have.
Pretty eye-opening because a lot of the time that you spend programming by yourself, you might be doing a lot of research and thinking about how to get something done and having that context switch between, you know, thinking about it and actually doing it can be challenging. But when you have someone sitting there next to you then it becomes a lot easier to have that social pressure to get started and, you know, time box things and say, "We're gonna look at this for fifteen minutes, do some research, and then we're just gonna jump in and see where it takes us". So I did find that, when you have two people, it's oddly way more productive than for either person to work by themselves.
William: Yeah, I definitely agree with that. I think, if for no other reason than the fact that I cannot get distracted, pair programming is super valuable for me. If you are working on the same computer as another person, working on the same task, you really cannot stop and check email, or the news, or get distracted by a text message on your phone. Because it's just so obviously rude. The social pressure to continue paying attention to what you're doing is really effective. Which is actually one of the main reasons why I have to use the Pomodoro Technique, because I couldn't actually pair for eight hours straight. Or, I guess, two four-hour segments straight. When I pair, it's so all-encompassing. It's like having a conversation for all day. And you need, if for no other reason than to go the bathroom, you need breaks periodically. I actually joke around about how my bathroom breaks are my body's Pomodoro clock. Because, if we skip too many Pomodoro [inaudible 00:04:50], I'm just sitting there doing pee-pee dance.
David: Yeah, especially if you're hydrating properly. But yeah, I guess that's a good point. You need to recharge every now and then when you're doing pair programming. Especially as, I mean I'm sure I'm not the only programmer who's an introvert, but I am an introvert. It is very socially draining to be in that close contact with someone for so long. You know, it's really quite intense the level of involvement that you have and the depth that you get into the conversation and thought that you're having with the other person. So, it definitely helps to break that up into chunks. And also to enforce the idea of switching between the roles. Because it's very easy to, kind of, just sit there in the navigator role and get out the popcorn and watch the other person go. So having that bell to make you do that switch is really helpful.
William: On my project we've been using a chess timer so my pair and I will each get a clock. And we can monitor how much time we're spending driving because, when it's the other person's turn to start typing, you can hit the chess clock and it'll stop your timer's countdown and start theirs. And then that way, if somebody runs out of time while the other person has a bunch of time left on their clock, you know that that person was hogging the keyboard. That's been helpful for me for my tendencies to hog the keyboard. So, I'm constantly trying to keep myself in check. I'm the one who bought the chess timer and brought it in.
Michael: Yeah, I think the first time I paired I was also learning the language in which I was pairing in. So, I came in as a Java developer, and I was in a Ruby on Rails project. So, it was really, really helpful to have someone there next to me. Together we were able to A) able to solve the problem that the client had, but it also taught me the intricacies of Ruby and stuff like that. So, I was literally writing Ruby code with semi-colons at the end and doing all sorts of weird things that you don't do in Ruby and someone was there to say, "No no, Mike, you don't want to do that in Ruby, the syntax is simply this. And, you don't wanna do that. And let's refactor a little more". So, I definitely gained a lot of knowledge in a programming language through pairing, while still bringing value and content to the client with whatever stories that they had played out. Ever since then, pairing has been great and I really enjoy it. I pair whenever I get the chance to, cause it's a chance for you to .. I mean, you had mentioned before that, as an introvert, it's like very draining. I would say that I'm the opposite where I look forward to that contact and get a chance to speak to someone about the problem that we're solving together makes it a lot more fun than if I were doing it by myself.
David: Yeah, I definitely can't argue with that, that it is more fun. It's just so much more engaging when you're not only being more productive, but interacting closely with someone.
William: Have you guys seen Livecoding.tv?
Michael: No, what is that?
William: It's sort of like Twitch.tv except for live coding. I did it for a while. I was working on open source stuff, and whenever I was working on it I would log on to Livecoding.tv and live stream myself, like my screen. And also I had a little picture-in-picture of my face. And you get random people from the internet coming into your channel and commenting like, "Oh, hey. It looks like you missed a variable declaration over here" or whatever. Giving you suggestions and asking questions and it was super fun. I really enjoyed it.
And I think it has a lot of potential as a way of learning languages like you were talking about how you learned Ruby by pairing with someone. And I remember I taught another developer JavaScript and one of the first exercises we did was, when we were pairing together, I asked her to direct me in pairing hard mode where I would do nothing except for what she explicitly told me what to do. But, I would do all of the syntax for her. And so she got to do all of the actual programming work without having to worry about whether or not you needed semi-colons or where the parens go and so forth. And she gave me really positive feedback on that as a way of learning a new language. And it occurred to me that I could probably get that same experience myself, or something close to it, by getting on Livecoding.tv and just watching other people in my target language.
David: Yeah, I've actually seen a lot of websites where they offer, kind of, remote mentorship or remote pairing experience. Where you can pay some kind of hourly rate and use some collaboration software to work on the same editor with some more experienced programmer on a problem that you have. I guess, something for freelancers to get that experience, even though they're physically separated from people who might have that expertise.
William: Yeah, that might be a good transition there. I don't know if you intended this, but that is a very smooth transition over to remote programming.
David: Yeah, sure, let's do that.
Michael: I mean even before, my experience with remote programming has been very difficult. We used tmux before, and I'm not really ... Don't kill me but I'm not really well-versed in Vim to be useful in it or EMAP. But even then, you know, I was still learning how to Vim remotely and that still worked out fine. I just think that the number one thing you need is an internet connection, a strong internet connection. If one of you guys are lagging, you're gonna have a bad time.
David: Yeah, that's true. I had tried doing remote pairing with folks in India, and that was always problematic. It's very hard to get a reliable connection out there and, you know, the software that we were trying to use may not have been quite ideal. And, also, when you're trying to collaborate with someone who's far removed, it can be hard cause you don't have those subtle social cues. You don't have body language, and you can't just look over and see if the person is thinking and they're driving and they stopped, or if they're checking their phone or whatever. I feel like it might be hard to get that, kind of, social pressure too.
William: Yeah, I think that Vim is also totally not the answer to peoples peer programming woes. In my experience, if you're doing web development, at least, being able to share via tmux doesn't really help that much. You can't do web development without being able to share a web browser. What happens when you open the Chrome development tools? What happens when you need to refresh the page? So, for me, it's been all Screenhero. But what I've found is, if you are pairing with somebody in Screenhero or whatever tool it is, the person who is sharing is always the bottleneck. Well, not always, but almost always the bottleneck. And the reason is because, for most carriers, for most Internet Service Providers, your upload speeds are slower than your download speeds. And so if you have the person with the higher upload speeds be the host, you're generally gonna do better.
David: Yeah, that's true. So what editor do you guys normally use for pair programming? Because, I guess we kinda had a little tiff about tmux and Vim and Emacs. Obviously, the three of us would not be pairing very well right now if we're trying to satisfy all of our needs. So, what kind of editors do you normally try to use for that on your projects?
Michael: I mean I think I've done a Screenhero with ... This was really laggy, but I've Screenheroed with RubyMine. When you Screenhero you can still, like William mentioned before, but you can share the screen so you can kinda see what's going on. But, RubyMine just takes a lot of resources so that only adds more to it. But, that's one that I've done it, and tmux. I don't think I've ever done anything beyond that.
William: There's an excellent xkcd about the editor wars. There's Cueball sitting there and somebody comes over and looks over his shoulder and is like, "Nano? Real programmers use Emacs". And then somebody else chimes in, "Real programmers use Vim." And then it goes, "Real programmers use ed". And then it goes, "Real programmers use cat". And then it goes, "Real programmers use a magnetized needle and a steady hand".
David: I'm sure there some programmer in Brooklyn who's doing that right now.
Michael: Exactly.
William: So, I remember using AtomPair back in the day, and by back in the day I mean, I dunno, maybe last year? Not that long ago. But, it was pretty janky and I have heard that they have made a lot of progress now. It used to be when you switched tabs the other person would not know that you were on another tab. And I think they've fixed that now. So that might be an interesting thing to experiment for people who use Atom. I think that there was another project out there, Floobits. I think they got shut down, or rather gave up.
David: I did see that there was a Floobits plugin for Emacs. Being that I'm not remotely pairing with someone, I haven't looked into it too deeply. But it seems like pretty much most of the editors have some kind of remote pairing plugin. Sublime has one as well.
William: So, I remember using them a while ago. I checked their website a month or so ago and it was just gone. So, I thought they had gone under, but I'm on Floobits.com and it looks like they are at least still hosting. As I recall, these are the guys who forked Vim. Apparently, Bram Moolenaar, I'm probably butchering his name but the guy who created Vim, is really iron-fisted about PR's, [inaudible 00:15:53] Vim. And they needed to implement a synchronicity in order to interface with another editor. And allegedly they spent months going back and forth with him and building out a pull request and, at the end of all of this labor, he told them that he was just not going to merge their pull request.
David: Yeah, I've been looking at their website and there is not Vim here. Only Neovim.
William: Yeah, I think they actually made Neovim by forking Vim and then merging their own pull request.
Michael: That's how you do it. Merge your own pull request. Don't do that kids, please don't.
William: I remember using this, and what was cool about it was that one person could be using Emacs and another person could be using Sublime, or whatever. You could have different editors and it would sync them up anyway.
David: Oh, okay. I like that. I like that idea.
William: The problem with all of these editor plugins, in my mind, is that they don't tackle the shared browser bit. And you need that. You also need audio, and preferably video of the person, that would really be ideal.
David: Yeah, video I think would be pretty huge.
William: I don't know. Maybe you could still make it more performant because you would only need to stream a very small video file or video window of the person's face. And then diffs showing the code changes, and I don't know how you would sync Chrome. It seems like you ought to be able to have a pair-in-Chrome plugin.
David: I wouldn't be surprised if that was out there. They have Chromecasts and all that fun stuff. But, yeah. The less things that you're shooting up your pipe, then the better it is for your lower upload speeds. Something like Floobit sounds like it would be ideal in a low-bandwidth situation. But I see your point, you won't have the richer media experience with audio and video and whatever else might be happening on your partner's screen.
William: I've been pairing in a really low bandwidth with another developer who's got major bandwidth restrictions and it is really tough, I have to say. That interruption to your thought process when you're typing, and the screen stops responding to what you're typing. And then, you try and fix it and then all of a sudden all of your key commands go through at the same time.
Michael: Oh, gosh.
David: Oh, oh yeah. I've definitely done that before with rating SQL commands or something on someone else's screen.
Michael: Oh, man.
David: Yeah, oh my gosh. What a mess.
Michael: One of the issues that you brought up that was interesting that has happened to me in pair programming that didn't in remote programming ... You mentioned that one of the applications will allow you to use any editor and it'll still sync up correctly, which is pretty cool.
In a regular pair programming situation, I used to pair with someone who used to type in Dvorak and I used to type in US Normal, and it was kind of like we had to set up a system in place and know, "Hey, if you're gonna drive and I'm gonna take the keyboard, make sure you switch it back before I end up writing in Dvorak thinking I'm writing in English or American, as I like to call it". Top of the icon, you can keybind ... We used to have, I think it was alt-spacebar. And it would change ... It'll toggle from DV to the American flag. So, we'd just say all right, if it's America, that's me. It's my go, bolt. And if it was the other person, it would be on Dvorak. And in pair programming, we had to keep that in mind but when we did it remotely, he could type in ... In tmux, he could have done whatever in Dvorak and it wouldn't have mattered because the keybindings are all the same.
David: So, for Dvorak, refresh my memory. It's a weird layout for the actual keys themselves. You don't have QWERTY, you have some other thing.
Michael: You have all the vowels on your left hand.
William: The idea is to keep your fingers on the home row as much as possible, so that you can type faster and strain your fingers less.
Michael: Yeah, cause I think the person has wrist issues. So, he felt comfortable typing in Dvorak. And it was pretty interesting, I was just not ready to learn a new keyboard layout. I felt like that was too stressful. I wasn't ready for that, at all. [crosstalk 00:20:56] He was like, "Hey, you wanna remote? And we remoted that day, and hey, everything was all fine. All good.
David: So, maybe we could talk a little bit about challenges? Like getting it to work on projects that you're on or what are difficulties that you've had with pairing and getting it to be effective?
William: I had one experience on a team where, it was a big corporate client, and they had a very time consuming process for issuing new laptops. And so, for my first month, I didn't have a company computer that I could get a copy of the code on. I had my computer, but not one of the client-issued ones that had passed through all of their security checks and whatnot.
And, so, I asked one of my colleagues if I could share his computer and he could get me up to speed on the code base and whatnot and I would just hook up two monitors and two keyboards and two mikes. So, we ended up pairing for that whole first month because, just by happenstance, that was kind of required. It was a great experience, we ended up getting to be really great friends and it also sort of set a precedent for the rest of the team to do pair programming. It was funny, I think it was the first or second week that we were doing it ... He invited me to a meetup and I went to the meetup with him and it was sort of just completely by coincidence, they were doing a workshop on pair programming. And I remember he turned to me and he was like, "Oh, this is like a real thing that people do on purpose?".
David: So did you sneak that in there? Did you subtly introduce him to pair programming without ...
William: I wish I could say that it was this grand scheme and I was masterminding it the whole time. In reality, it was a very practical solution to the problem that I didn't have a computer with code on it. I had some experience with pair programming going into it, and so for me it felt very comfortable. And for him, I think it was more of a, in the beginning, sort of a shock. But, he came around. Especially after we went to that meetup. It was a Code as Craft meetup and we did Ruby katas practicing pair programming. Practicing that skill of passing between driver and navigator, and doing ping pong pairing where one person writes the test and the other person makes a pass, and back and forth.
And we did, I think that was the meetup where I learned about hard mode. Have you guys done hard mode in peer programming?
Michael: No, you mentioned that before but I didn't know exactly what that meant.
William: It's when the driver refuses to do anything that would require hard-level thought. So the navigator has to give very specific instructions on how they want the code to work. The only thing they don't have to specify is syntax. Like: define a method that accepts these three parameters with these parameter names and if the first parameter is nil, then do whatever. So on and so forth.
And, we did another thing called evil mode which I think is much more common. And also much more useful, frankly, where you're ping pong pairing and you try and write your code to do the absolute bare minimum possible to get the test to pass. So, if the person says, "We're implementing a square function. I'm going to write a test where we pass in the number two and we get the number four". Then the other person takes over and instead of implementing what would be a very basic function, accept your first parameter and then you multiply it by itself and return the result, you would return the number four. You'd hard code in the number four.
David: Right.
William: And then, you write the test, the next test. Like oh okay, so you pass in the number three and it has to give you back nine, and force the other person to do the hard part. And then you go back and forth and you try and force the other person to do as much of the implementation work as you can. And what's nice about it is that it ends up building these super robust suites.
David: Right.
William: Cause it handles every possible edge case, cause you've been trying to force the other person into these edge cases.
David: Right, it's like kind of game-ifying TDD, where you're punishing the other person for not writing a proper test case.
William: I would argue it's still a proper test case, it's just, you know ... A good test case is only gonna handle one scenario, right?
David: Right.
William: You wouldn't want one spec to handle every possible edge case.
David: Yeah, you have to get enough constraints to properly pin down what the functionality is gonna be.
Michael: Oh, that's funny, so that's called evil mode of pair programming, or test-driven development?
William: That's what they called it at that workshop, and I liked the term for it. Cause there's also evil mode in Vim, where it'll punish you with a one second timeout if you hit the wrong key, to force yourself to learn how to do the right keybindings. It's so annoying.
Michael: So evil mode. I used to call that "wise guy driven development". Because you're just trying to one up the other person, like a wise guy. [crosstalk 00:26:36] And then you have a snarky one liner after the person finishes writing their code. Like, what are you, a wise guy? Yeah, what are you, a wise guy? Wanna be a wise guy, eh? I'll show you who's a wise guy. Then you go back and forth, being wise guys. And whoever ... And at the end of that, at the end of the wise men pair programming session, you do have a ton of tests. Cause you just try so hard to have the other person fumble and are forced to implement something. And then the tests are just great. And what comes out of it is awesome. Wise guy driven development and there's evil mode. I'm gonna have to use one or the other depending on [inaudible 00:27:19].
David: You're gonna see what the crowd is like.
William: Have you guys done much mob programming?
Michael: I've had the opportunity to do that once. [inaudible 00:27:30] like really quick, it was during one of the Open Source nights after one of our recordings of the podcast, actually. I walked in and saw there was about four or five people pairing. Well, not five people pairing, but it was just literally on the big TV, I would say about forty inch TV and the computer set up. And there's one driver, and then there's like five people just watching the driver.
David: Yeah, that was actually my experience, as well. But that is literally my experience because I was one of those people.
Michael: Yeah, exactly, no. So, I mean, you probably have more cause you were in the room longer than I was. Cause I saw it. I was like, "Whoa. This is a lot of people. That's probably a lot of opinion. How do you move?". And stuff like that. Tell me more about it.
David: It was really fun, actually. So, we were working on a JavaScript code base using React and Redux and we were trying to dig deep and find a bug in an open source code base. And, I had never seen this code. Actually, none of us had ever seen this code base before. Some of the folks in the room were familiar with [inaudible 00:28:45] and React but I am on the less familiar side of that spectrum, so. I think in this pair programming experience, or the mob programming experience, I experienced a lot of the things that we've been talking previously about pair programming. Like, there was that guidance for, you know, learning the language. There's plenty of people in the room who were able to shout and let you know what the appropriate syntax was.
So, I was kind of nervous going up there and taking the keyboard because it seemed pretty high pressure. But actually, it was really fun because it was so collaborative. And because it was kind of like the hard mode programming, but everyone in the room was doing the hard mode. So, it was actually pretty easy for everyone. So, you know, when I was stuck there was so many people in the room who had ideas about where we should look or what code we should update, you know, what the method name was. And even myself, when I was part of the mob, [inaudible 00:29:52]. Even though I wasn't the most familiar with React, I was able to pull up the docs and look at the docs and even teach some of the people in the room some things about how objects or different plugin libraries for React behave. So, I thought that was really cool.
Michael: Would you do it again?
David: Yeah, definitely. I'm trying to think if there's a situation in the business world where this might happen. It's really exciting, and I guess you wouldn't do it every day. You wouldn't have all of your developers come in to a room and just yell at each other all day. But I'm trying to think of where in the scheme of things this could fit into an actual project. But, for a fun project with friends, it's absolutely the best.
William: My experience with mob programming has been usually some subset of the team. I've never done a mob programming session with the entire time. But I think when you're pairing it's often really helpful to bring in a third party, if for no other reason than to break a tie. If you've ever been back and forth with your pair on some nuance of an implementation that you just can't agree on, one person things that it should be one way and the other person thinks it should be another way, I find it's really helpful to bring in a third person and say, "Hey, why don't you pair with us for a little bit and you break the tie. And we'll just both agree to go with whatever solution you think is best". And sometimes that turns into the other person wanting a third opinion, or fourth opinion, and so you end up with a big group of people all huddled around the screen watching one person sketch.
And I think that has value. Scaling it up to the point where you have an entire team of people who are regularly working on one single work stream is another level of that that I haven't personally experienced. But, I have heard that there are teams that do that. I don't remember if it was the Ruby Rogues or if it was another podcast, but I heard a podcast on mob programming and the person giving the interview worked at a company where that was exclusively what that team did. It was like eight or nine developers and they would all mob program every day. And apparently, that team was really high performing within the company. So, whatever they were doing was working. And their explanation was that you had perfect agreement about all of the decisions that had ever been made in the code base. Because you literally had everybody on the team there all the time.
David: I guess you don't have any merge complex, also?
Michael: I think one of the things that's pretty cool ... I guess, in this team's example, as well, is for really big architectural designs that you want everyone to be a part of, everyone is in that room to know exactly how that particular feature was implemented. Which I think would be pretty dope.
David: Yeah, I like that. Kind of having that as maybe a starting point, where everyone is in the room laying a foundation down. And then, maybe breaking off into smaller pairs as necessary.
Michael: I'm thinking about doing that soon at the client that I'm currently in. Just to bring it up and see what people think. Peer programming is pretty good, the client likes it when it happens. So, I wonder if I can bring in two or three front end developers and three back end developers to determine, "How to we implement a feature that may ... Like, we may have to deal with this for the entirety of the code base for the feature that we're building?". And I think that if we have more than one person making decisions, it would definitely make the code better in the long run.
David: Cool, that's awesome.
William: Does anybody have any particularly good pairing experiences?
Michael: Good ones? I would say that I had a great pairing experience when, at the end of the eight hours that I paired with that person, I'm exhausted. Cause that shows that, you know, I think it was definitely mentioned before that there was no time to check Facebook, or your emails, or lollygag or whatever the case may be. It's just intense. You know, intense work with this other person who you wanna support and get the job done together. And its just like, great work, you go and you bounce back and forth on ideas. So, at the end of the day, after all that talking and all that coding and programming thinking, you're just drained. I just wanna go home and have dinner and go to sleep. I think those times are definitely great times of pair programming for me.
David: Yeah, for me, the best pair programming experiences are when you each have, kind of, a difference perspective or different set of knowledge and things that seem really hard by yourself then become really easy. And you can help each other remove obstacles very quickly. And I think that's when the technique really shines. And because of that, because you're not just sitting there trying to find an answer to a setup issue, for example, or figuring out what an esoteric error message means, you have a lot more time to actually be creating good code and really burning yourself out for a good sleep at the end of the day.
William: So, the feeling of tiredness at the end of the day is sort of a flag that you have really given it your all and that your pair has really brought out as much of you as you can give?
Michael: Yeah, I think so. I agree. I think another thing that happens to me when I pair is I reflect on the pairing session. And like, something was very difficult for me, or I didn't fully comprehend a feature that was made, I try and read up on that programming language or that design pattern that we chose to do. Because, the following day, you want to be better than yesterday cause you don't want to let your partner down.
So, I always think about, I mean an extreme example, I always think of it as this person you're out on the battlefield with. And you guys are in the trenches trying to figure out how to get out alive and well. And, if one of you are weak, then you guys are pulling each other back from producing that good code. So, the next day I wanna be sharp and ready to get the job done. I know it's an extreme example, but I always think of it that way. Cause I don't wanna let ... The following day, I want it to be better than yesterday. So, just being sharp is important. But being tired at the end of the day meant that I gave everything at the end of the day and just want to go home, rest up and do the same thing the next day.
William: So, it's a motivator, the fact that your pair needs you to be well-rested and fully present as a motivator to come in well-rested and fully present?
Michael: Yeah, cause you don't wanna ... I mean, you don't wanna come in and not be a good pair. All right? Cause then you're bringing the team down by not giving your one hundred percent. I think that's called ... What do they call that in [inaudible 00:37:46]? I think its energized time. You wanna make sure that the time that you spend pairing has a lot of energy because you guys are using that energy together to solve that problem. And, if you come in and you're not energized then you're being the weight of the team that shouldn't be there.
William: The fact that your pair derives energy from you is a motivator for you to bring lots of energy?
Michael: Yeah. Pretty much. And it's dope. You know, whatever gets the job done. And I get to do it with a pair, that both at work and outside of work, is a cool person that I can ... Cause that is a thing too, right? I imagine it would be a very difficult pairing experience if you didn't enjoy being around this person. Imagine that. You have to sit next to this person for eight hours and he's obnoxious. Or he or she, excuse me, is obnoxious in any way shape or form. Or they belittle you as you code and stuff like that. I would think that that would be a bad experience. But, I mean, if I know that I'm gonna pair with someone I want to make sure that I give my one hundred percent to the table.
William: Have you guys had any particularly bad experiences with a bad pair?
David: For me, sometimes it can be challenging to convince a new team that pairing is something that is worthwhile. You know, the developers might have a lot of pride in their own work and not want to share time with other people and lose some ownership of the work that they're doing. If the culture of the team is that's where it lies, then it can be challenging to work against that.
William: Like, if people want their name associated with a particular feature and are reluctant to pair with someone and, thus, share credit. Then it's difficult to convince them to give pair programming a shot?
David: Yeah, I think so. I think that that's definitely a challenge that you can face.
Michael: Yeah, I've had pairing sessions with people who are really self-conscious as well, who don't ... They feel like they don't product good code. And that's another thing, cause it's one that, if I'm paired with someone, I know my code is perfect. I mean, I know I'm gonna write the greatest code on the planet on that day. And I'm joking, I don't really mean that. But the way that I come into pairing, I'm gonna write some code and it's gonna be good, and it's gonna be bad, and that's okay. But some people see a pairing session as, "Oh my god, this person's gonna look at the way I code and is gonna make fun of me. Or is gonna belittle me" and stuff like that. And they have had a bad pairing experience where it's a downward spiral of that pairing experience which then makes the next pairing experience worse. Because you thought about the last one that was bad and then that one ends up being bad and then it just keeps going down, down, down, down.
David: Yeah, I guess that's where something like social roles can be helpful. Where you're not trying to jump on someone for not knowing something and just trying to work with them and learn from mistakes that you're making and just accept that things are not gonna be perfect. And that's perfectly fine.
William: I had a bad experience with a pair once. It was really uncomfortable. My pair had a body odor issue, and it was really strong, and I just could not concentrate on the code because ... You know, I was having a hard time breathing. And it was really ... I don't want to make fun of the person. This was an actual challenge for me to figure out how to ... I never really figured it out. What I ought to have done is found some graceful way of letting the guy know that there was this odor issue and that if he could address it then our pairing sessions would be far more productive cause I would be able to be fully present and bring that energy like Nunez was talking about. And what actually happened is that, after a couple of days, I ended up on a different assignment, pairing with someone else. And it just sort of went unresolved.
I talked to a couple of people about, "What is a tactful way of bringing that up?". Because if I had a B.O. issue, I would want someone to come up to me and say, "Hey, other people are avoiding you because of this thing that could be very easily solved with soap".
Michael: Yeah, I'm always really conscious about that, too. I don't know, it's just that for me, I don't want to be that person. So, I always have in my bag deodorant and a toothbrush and toothpaste. Just in case if I eat something with a lot of garlic, the person who I'm pairing with may not want to speak to me cause I got a hot garlic slash onion breath. I might as well take the five minutes to brush it up a bit so that we can both be comfortable. I think that is the number one thing about pairing. You gotta establish the comfort zone.
William: There's another resource that people should definitely check out, and we can include this in the show notes. But there's this guy who worked at Pivotal Labs, I don't know if he's still there or not. But, he's the guy behind remotepairprogramming.com. I think his name is Joe and he has pair programmed for ... He released this video, it was an AMA called "I have pair programmed for 27,000 hours, Ask Me Anything". And it's really interesting.
Michael: Oh, wow.
William: Yeah. He's got a link to it on his blog and we'll link to that in the show notes. So is there anything else that we have neglected to cover that relates to pair programming that people desperately want to share?
Michael: No, I think we covered it. Pair programming can be awesome. Remote programming has a lot of applications. Mob programming is great. You know, make it comfortable. Wear deodorant and be awesome. For you and your pair. I think, if anyone wants to add any more to that?
William: Oh yeah, check out Livecoding.tv.
Michael: Yeah, Livecoding.tv. That was mentioned before.
William: We'll add a link to that in the show notes, as well.
Michael: Cool. So, thanks for listening to The Rabbit Hole. We had William Jeffreys and Dave Anderson here talking about pair programming, it was great, and I hope to see you next time. Take care, have a good one.
Stride Consulting
Rabbit Hole on Twitter
Livecoding.tv
Screenhero
Real Programmers on XKCD
AtomPair
Floobits
“I’ve Pair Programmed for 27,000 Hours. Ask Me Anything!”
