 you guys, because I thought you might not notice that I'm a girl. Those butterflies are not girls, they're boys and girls together, the same. I have a present for you guys, but I need you to promise me that you won't play with it until I'm done. We promise? I want to give you this toy. It's very cool toy, but I need you to tell me you won't play with it while I'm talking because that will totally stress me out. Nobody? You don't want my toy? Come on. This is a tutorial that will teach you Vim, the beginning of Vim, because I have the sneaking suspicion that most of us would really like to be cool Vim people, but we're scared. So, you know, maybe not all of us. So write it down, but don't play with it because it's really fun and then you won't pay any attention and it won't be sad. Okay, that's enough of the toy. So I work at Lean Dog in Cleveland on a boat floating in Lake Erie, which is not quite as gross as it sounds. And we're also hiring, so I thought I'd mention it. You can also come and hang out on the boat for a day if you want to. So, does pair programming have to suck? I keep running into people who consider themselves to be craftsmen or artisans or whatever. Rockstar programmers, etc. And many of them like to pair. And some of them teach pairing to other people, but when they can avoid it, they avoid it. And some of them just don't pair at all. So I started asking the question, you know, why do you not pair? And the answer is pretty much always, because pairing sucks. Oh, I forgot to show you my second slide, just obligatory, you know, because everybody else did. Anyway, that's my answer to the question, does pairing have to suck? And I want to go through and talk about, I'm going to spend a little bit of time on why pairing is a good idea, but not a lot. And then I'm going to talk about why it sucks, because it does suck if you don't fix the things that make it suck. So you've all heard the claims that pair programming produces higher quality code and it produces it faster, right? It's not actually slower. Ron Jeffrey says the same thing. There are studies and academic papers which you can Google on your own time. I'll skip those. But I will go over some of the things that pairing gives us. One thing it does is it helps us bring up new. We have new people on our team who are beginners at something, but not everything. They haven't seen the code base before, whatever. They waste their time on easy questions that you would have known the answer to in like four seconds, right? Or they spend their time trying to look smart, which wastes a lot of time. Don't we waste a lot of time trying to look smart, especially when we start on a project? There's like two days just lost with the whole like, I'm totally so good at this. Anyway, it gets them familiar with what we're doing. So it brings up news. It also helps us share knowledge among experienced members of our team so that we can keep our bus number down. You guys know what a bus number is? Number of people on your team, if they got hit by a bus, you'd be screwed. Bus number one is not good. Somebody said that today already. Anyway, it's best if everybody knows what's going on, right? So it helps us share knowledge. It makes our code more expressive. I can't tell you the number of times I've come up with a name that I thought was just so crystal clear and the pair says, what the hell does that mean? Right? And so when we have two brains bouncing off of each other, we come up with better names, better extractions, better expressiveness altogether. And it reduces errors, right? You don't spend 15 minutes looking for something that turns out to have been a stupid typo or reverse logic or something. You don't go down twisty paths that you didn't need to go down and screw things up. You don't miss edge cases or perfectly normal cases on it that day. And it creates simpler solutions. This is really the big one. Collaboration is like this astounding thing that we take our ideas, right? And some people think collaboration is when one person has an idea and the other person shoots it down and replaces it with a better one. But ideas don't work like that. The really good ideas are ideas that evolve. And they evolve through being hacked at. So little pieces of our idea fall away and get replaced by the other person's ideas. Little pieces of theirs fall away and we come up with something new that wasn't going to exist before the two of us worked together. And the result of that is that we end up with simpler solutions. We don't just like get our minds around one idea and then pursue it and come up with some ridiculous, complicated solution that could have been much simpler. And of course, Perin keeps us off Twitter. Not that I'm ever on Twitter. So why don't we look also obligatory fuzzy animals? Why don't we pair? I started asking people this question. And the answers I got were like, well, I'll tell you what happened when I did a survey. I did this little survey thinking that I would get really clear answers about how you need the right equipment. You need the right furniture. You need to have pairs that are talented enough. And when I did the survey, I asked those questions in the graph of the result. And I got like 76 answers. It wasn't like totally puny. The graph of the results was exactly the same. People who were talking about a good pairing experience and people were talking about a bad pairing experience had the same distribution of whether they were working at two key words and a big screen or hovering over a laptop. It didn't make any difference, which I thought was pretty weird because I'm all about a nice pairing setup. And it also didn't make any difference that they felt like their pair was smarter than them or dumber than them. None of that mattered. The only thing that mattered was one thing, which is the same thing Tim Honinger found. He's a, he's kind of a famous pair work and he paired on his, on his agile on a flashback. He's a, if you don't know him, he contributed to clean code. He's an agile coach and the programmer and a famous pair and he found the same thing, focus on the code. That's the only thing that matters. What matters between the description of a good pairing experience and a bad pairing experience was that both people were focused on the code. It seems like a really little thing, doesn't it? When pairs are engaged, not distracted, fully collaborating, that's what makes a good pairing situation. And what I mean when I say focus on the code, I'll be really specific. Like I was on a team where we were pairing and there was a central machine and then each person had a laptop. And the idea was they'd be able to Google answer some stuff. What actually happened was that this very experienced developer said to me, we like to do what I call side by side pairing. That's been like my key phrase now. Side by side pairing is where the advanced developer works on something else. And the person who is identified as junior for whatever reason does all the work except they get to ask questions once in a while. We call things like this pair programming and then people say pair programming sucks and I don't want to do it. Okay. So pair programming takes work. Some people might consider that a reason why it sucks. I don't really think so. I think that everything that's worthwhile takes work, right? So for some of us making the decision to learn something technical is sort of automatic. But the idea that we have to learn something more personal is like what? I don't have to learn that I know how to talk to people. I know how to sit with people. But you really don't. If you haven't had experience in collaborating, you don't know how to collaborate in collaboration is a really useful skill in this business. So I would ask you to open up to the possibility that you can learn things about that stuff too. I'm curious how many people in here in here are pairing regularly now? How many people would like to be? Is there anybody here who would not go to work some place where they had to pair or would be really pissed if they were asked to pair all the time? Wow, that's awesome. No, that's advice. I don't have any biases. Okay, so when does pairing suck? When you're pairing with a newbie? Well, what's a newbie first? Somebody who's less experienced than the tools that you're using? Somebody who doesn't know how to collaborate? They only got to show off. Somebody who's new to coding, a tester who's going to start coding and wants to pair with you? These people, there are a lot of differences, but you can get a lot out of pairing with a newbie, you get the opportunity to describe what you're doing and hear how ridiculous it sounds sometimes. I mean, you get the obvious advantages of they find typos and stuff. But talking to another person who is intelligent and knows how to reason and knows how to ask new questions can be really helpful. So how do you make it not suck? The first thing is you don't hug the keyboard. And how do you not hug the keyboard? You make them drive. And that means swallowing some pride, maybe, bucking up when it's really hard because you want to hug the keyboard really bad. One of my favorite coaches and close friends, Dupadell, says calls it handset pairing, which he learned working with me over Skype. And he says that he learned a lot from this. He learned how to talk about what he was doing. He learned how to express things that he didn't know how to express before. Okay, and then ask them what they think when you when you are driving, say, you know, how does this approach looks you? Talk about everything. And then the last thing I would say when you're pairing with a newbie, it's your job to teach them how to collaborate. And that means you get to model for them what it looks like to make a mistake. You get to screw up and then laugh it off, or learn something from it. You get to model what it looks like to change your mind. You get to show them what it looks like to get really attached to a solution and then go, God, you're right. That was dumb. And be okay with that. And that's how they learn not that they don't have to perform all the time. Maybe you're pairing a rock star. Maybe you're the beginner. Everybody's a beginner at something, right? At least I hope so. If you're not, you need to find somebody who's better at you than something to pair with. So you get the advantage of lots of knowledge that you can get from them, right? But then it can get weird. They zone out and leave you doing the work and you're not pairing or you zone out because they're hugging the keyboard. So here's the challenge with this one. You get to take the leadership role. And what that means is if you're with an experienced programmer who's not an awesome collaborator, it's your job to A, remember that you're bringing value, which is hard. I mean, I have actually, I have actually gone to the bathroom and cried, pairing with a rock star programmer. I confess this to you, because they hug the keyboard, they imply that I have nothing to offer. And yet I'm supposed to be like, able to pair with them. Anyway, so you have to take the leadership role, you have to convince yourself that it's okay for you to be there. And you have to ask questions, lots and lots of questions. You have to stop your pair. You have to say, dude, give me the keyboard. Like 75 times sometimes. Because what you're doing is if you're, if you're a pair or you're teaching them to collaborate, I keep saying that, but that's really, you know, if you're into this, that's what you got to do. Because the people that don't want to pair are people who are scared of collaboration or don't know how to do it. Very serious. What about when you need to work really fast? Does pairing suck when you have to work really fast? When you have something you have to get done? No? Why not, Joel? So we don't abandon TDD when we have to go fast. We don't abandon continuous integration. But if you're in a death march, you have bigger problems, right? I mean, that's like, I don't even know what to say about that. But we, we share knowledge so we can pair and we go faster when we pair. So what about when you need to focus? This one's interesting. I have been told by people I can't pair right now I need to focus. And excuse me. It was really interesting because I was talking to a co-worker about this visa, some of you might know it. And I showed him the slide and besides telling me that it was hideously ugly. He also said, so pairing increases focus, what's the real issue when somebody says that? Is it that it's something hard? So maybe it's a spike, in which case, do it on your own. Fine. You don't need to collaborate on that. You can follow it as long as you want to, or as long as your time box allows you to. But then he said something really interesting. How many people who do know visas? Yeah, okay, so visas is not a guy who talks about his feelings a lot. And he's a really sweet guy, but he's not a guy who talks about his feelings a lot, but he did say, you know, if it's that you're going to feel dumb, if somebody's with you while you're doing this hard thing, you need to say that out loud. I'm like, what? He says you need to notice it and say it out loud. And I'm like, dang. But it's true that if you, if you do that, if you just notice it, sometimes that just like diffuses. And your performance problems go away. Because you just notice it. Try it. You know, I can't show that to you up here, but it does happen. And as a bonus, if you do that, if you say, we have this hard problem to do. And I was going to say, I have to focus so you can't pair with me. But really, I'm scared. I'm going to look stupid. You're modeling openness for your pair. You're modeling that mistake, making being stupid, whatever. So that your parent can learn that it's really okay if you're not perfect. Or if it's something tedious, visa's advice was to write silly tests or make jokes out of things. But if it's something tedious, you're sorry, you're going to screw it up if you're doing it by yourself because you're going to fall asleep or you're going to make lots of dumb mistakes. So what you can do if it's tedious is you can vary your style of pairing, you can try ping pong pairing. And the keyboard back and forth, whatever. And what do you do when somebody's zoned out or bored? Make them tight. Yeah. And you talk about it, right? Because this is again, the same problem. If you're pairing with somebody and they're zoning out or bored, it's because they don't know how to work with you and collaborate. So make them tight, talk about the code, focus on the code, right? And if you're taking the leadership role, you know how to do that, you know how to stay focused on the code while they're typing. Right? So you can take that role, you can hand it over to them and then focus yourself in on talking about what's going on. So pairing can suck when you have code standards. Right? Your pair of complaints about taking the time to name something or complaints about how little the methods are that you want to extract. Where they insist on discussing a name for 20 minutes. So what do you do about that? Anybody know what to do about good standards? Disagreements about good standards when you're pairing? Beat them up? Oh, rock, paper, scissors. You're like, okay. Yeah. Do something for now and let it go. Right? Names are like this. You can get all worked up about a name. Okay, let's call it that for now and then come back to it. Because we have a great factor, right? Or you can flip a coin to rock, paper, scissors. You say, okay, we argue for this bunch of time or and so we're going to kill each other and then we just flip a coin. This one's important. This is a thing something Ron Jeffries advised was do the wrong thing. If somebody's wrong, and you're right, which you know, of course you are. Go ahead and do the wrong thing because the cool thing is that the wrong thing will out itself really quickly, right? Or if you were wrong, you look less stupid because you gave in quicker. But go ahead and do the wrong thing. Don't be afraid. You know, you don't have to win. And then here's the other thing that Ron Jeffries constantly reminds me of when I get scared about things is that these practices are actually things that result in better solutions. Right? That's the reason we collaborate. You can trust that that will happen. They will emerge. Does that make sense? I mean, I could probably do a whole talk on this, but if you're doing the collaborative practices, if you're doing little tiny steps, TDD and stuff, it will grow and change over time into something that works. That's why we do it. So it's fast and it's productive. It is fun. And yet people think it sucks. And so my my contention is that we can change that. We, the parrots among us, are the ones who get to make that change. And we get to make a change by teaching other people to collaborate with us. Right? By opening up our minds to new ideas, to correcting bad ideas and building better ones. I don't know that I've learned to do this the way Chief Law Hill does it. Do you guys know Chief Law Hill? He's a natural coach, but he works in like ugly things, not roomy. But you should follow him on Twitter if you don't, because he's a very cool guy. But what he teaches is that it's our job to charm our teams into greatness, which is about encouraging joy, encouraging the freedom to make mistakes. He's really big on that one. Teaching people how to learn new things and how to not be scared all the time. And I think that what gets in the way of pairing is often fear. It gets to be about am I performing adequately or are they performing adequately or whatever. And if it's about the code and not about worrying about who's inadequate, then it's a lot of fun and productive. Do I have any more? Oh, right. So the mindset that I'm talking about here is something that I'm calling confident humility. And what it means is it means knowing that it's totally okay that you suck, knowing that you're not expected to be perfect, that in fact, the fact that it's okay for you to make mistakes and it's okay for you to suck means you can do whatever the hell you want. You can walk around in the world and you can tell people your ideas. You can listen to criticism because you're so confident that it's totally okay for you to make mistakes or for you to not get right, that there's no risk. That's what we have to teach our pairs. When I'm pairing with somebody and we're just like going back and forth and somebody says, you know, God, that's a stupid thing, you know, I don't want to do that. Or okay, that's a stupid name. That's something that I've heard in pairs. That's a stupid name. If you're in a pair where both of you have this confident humility, it's not an issue for somebody to say that. If you're in a pair where you don't have this confident humility, then somebody says, what do you mean it's a stupid name? I can't believe you're telling me. Right? So it's about teaching our pairs this to modeling it for them. I think that's all I got. Does anybody have questions? Anybody want to tell me about pairing that sucks that can't be fixed by this? What's your favorite book on pairing that talks about this stuff? Or a website? Huh. Somebody else recommended something. The book on, he asked what my favorite book on pairing was that talks about this stuff. I don't know what one. Yeah. Oh, yeah. Oh, so Lori Williams wrote about this. All pair programming. She wrote about nine years ago. Awesome. Thank you. Did you guys hear that? Yeah. Lori Williams book called pair programming. Recommended by Uncle Bob himself. Read it. Okay. Here were two hands back here. Yes. It's a retrospective. If you don't have retrospectives to fix problems, you're not going to fix the problems. See, I wasn't going to go into a retrospective rant, but nobody wants to do retros either. That's the two things, I guess, from XP that don't happen. He told them just because of that. Not because somebody told you to. So he recommended that retrospectives help a lot. And maybe you grow into the ability to have them in the moment instead of having to have them weekly, but definitely you need to have a lot of them weekly. When they get really boring then maybe you can back off. Yeah. Okay. I could name a couple, but none of them are wonderful. They're all laggy. What do you think? Screen and Emacs. Yeah. Thanks. So I guess the people who tell me that it doesn't suck are people that are using some sort of SSH thing. Yeah, we use Team X. Is it fast enough or is it solenoid? Yeah, it's fast enough. So that goes back to the Vim present I gave you guys in the beginning. Learn Vim. Give up on trying to do it over some sort of IDE. And don't care remotely. Okay. That's not your idea remotely. Yeah. On, with regard to, I guess, conflict resolution, something I want to share and get your thoughts on. We have a person on our team that has, for one reason or other, been named the Codesar. Not because he's like a iron fist kind of guy, but he's just a really good example to follow. And he's proven useful in a way that we hadn't really foreseen that when we're pairing and one person's saying do A, the other's saying do B. We both can go to him and say which sounds better to me. He is a tiebreaker. How does that work for you? So far so good. Everybody's happy with that. It's a pretty new practice. I would be cautious. And you can tell me if you disagree with this, Joel, but my caution would be that I think the pair can figure it out and that I go back to do the wrong thing. That I wouldn't want to necessarily get the right answer every time. And you can watch for this and see if the pair starts and not function well together. But having a third person that you go to to answer a question means that you don't get to fully build up your own ability to create solutions. But if it works, then that's cool. Is there a hand over here? I think we have like two or three minutes or something. Joel! So sometimes on a really small team, I was in a company with one other person You do a lot of pairing with just one person. Do you have any experience with pair fatigue or do you want to comment on them? How do you cope with that? Do you? I mean you said you got that experience. What was it like? It took some effort after a while. We both had to recognize who we're kind of getting. I'm going to kill you now. A little bit of friction and you start to realize what's going on. Did the benefits of pairing fade out after overtime? They don't. It just becomes emotionally harder to do. It's kind of hard, I think, sometimes to acknowledge what's going on because they're probably a friend. So you don't necessarily want to necessarily acknowledge that you're tired of them. Because it just sounds rude, but in my experience all of the really great people that I've ever paired with, I've paired with them long enough, it's not really a factor how much I like them or admire them, but we'll talk to them eventually. You get tired of them? Yeah, not permanently, but in a small team where you don't have the opportunity to match around as much as you can be. I know that Tim Auditor, who talks a lot about pairing, has really reeled against fair marriage as a bad thing. And I know that sometimes it happens. And I think we grow to learn to talk to each other. Like, if you have a spouse or somebody that you have a lot of time with, that same thing can happen, right? And at some point you've got to find a way to talk to them. We have to talk to pairs about things like body odor, right? Eventually you've got to have to learn to talk about these things. And it's not easy to do, which is probably one of the reasons people avoid it. But also it's nice if you can avoid having that set up, right? Where you only have one person to pair with. What else can you do? You can go your separate ways and work on other things that aren't committed code, right? Work on spikes or anybody else? Anybody have any advice for Joel? Sometimes. When we have teams that are too small and we don't have people that are in the same role, we even paired with people that aren't developers. Yes. So he said that you can pair with people who aren't developers. And that's definitely true. It depends on how scared they are of your code, right? If they're comfortable, right? If they're testers, if they're designers, they may well be comfortable. Can you swap with other teams, too? Sometimes. If you're like, I'm going to kill this person if you don't let me swap. Somebody back here. One more. Who was it? It was you, yeah. I was just going to... I look at this and I'm thinking like how could that be so productive? And I'd like to try it out. Who would be a good test runner? It's a good way to get an acclimate new team that this idea sounds so crazy to get started with. That's huge. One thing is if you have a code program that all before go to a code retreat, you really should go to a code retreat. December 3rd is Global Day of Code Retreat as it happens. And so a lot of cities are having code retreats. Do you guys know what a code retreat is? It's a one-day thing. It doesn't cost anything. You get decent food. It's the last thing I'm going to say. I have one minute. And you spend a whole day of pair programming on a puzzle. Usually Conway's Game of Life. You get 45 minutes with a pair and then you actually throw away the code and start over again. And you do this over and over again throughout the day working on your craft. Working on making your code as beautiful as you can make it. Making it the way you'd like to make it if you had all the time in the world. That's why we throw it away after 45 minutes. Anyway, it's December 3rd, Global Day of Code Retreat. You can Google it or look at me on Twitter and I'll tell you. We are having one here. There's one in Kansas City. If you guys are interested, go ahead and get one. If you've never paired, it's definitely definitely definitely a really good idea. As for introducing your team, you know, you have me on Twitter. We talked about that for long hours. Okay, thank you.