 My name is Joe Moore, and I've pair-programmed for almost 13 and a half years, almost every single working day. And for the last four years, I've pair-programmed remotely, using remote pair-programming, full-time, out of those 13 years. I work for Pivotal Labs for Agile Software Development Consultancy, and I work remotely from Atlanta. There's two of you who didn't hear this. I'd love feedback at bit.ly.com slash pair-programming AMA, it's totally anonymous. And also for the other people who walked in, there's a microphone here and a microphone over here. If you have questions, it'd be great if you could make your way that way and start and queue up while I kind of blab on about some other stuff. If not, I'm going to grab these mics and I'm going to run around and do a, I don't know, a mori, maybe. I don't know who's, is he still around? Anyway, so again, thank you for all, everybody, for coming here. Who is familiar, at least somewhat, with pair-programming? I'm going to call that 80, 10, 90 percent. That's great. So for those of you who don't know, pair-programming is a software development technique by which two programmers work on the same code at the same time, solving the same software problem on the same computer. That's what pair-programming is. And you can throw the word remote on there, and guess what, it's all that stuff just using some remote collaboration softwares, such as video chat and audio chat and screen sharing and such. So what are the benefits of pair-programming? I can have slides and slides and slides, but I'll just give you a few. It's everything from having a continuous code review to cross-training junior people and older people or more experienced people, cross-training people from different disciplines. You tend to introduce fewer bugs because you have two eyes on the same thing. You have differing opinions, which is really great, because that ends up raising what I call the whole team to what I call the highest common denominator, because that kind of disagreement and such is really great. And it goes on and on and on and on from there. In general, the general principle, I think as most of us know, in almost everything, two heads are better than one when you're trying to solve hard problems. What are the challenges of pair-programming? It's extremely, it can be very exhausting. Personality conflicts can be difficult when people don't necessarily get along. It's definitely what I would consider to be the most difficult software development practice to implement, both from a social point of view, from selling it to people on the ground working, to selling it to management, that it's not double the money in twice the time, et cetera. But it also, I feel, has the greatest benefits. So it's the hardest, but it's got the biggest payoff if you're willing to dedicate yourself to it. And this is one of the top three questions I thought I'd go ahead and take care of that now. When do you decide to take breaks? When do you decide to go to the bathroom? And the answer is, whenever you need to go to the bathroom, it's the optimum time when you should probably do so. And it kind of points to, you're just people working together. You decide to take breaks when you're ready to take breaks. If you've been going for an hour, you've been going for more than an hour, yeah, take a break, stretch your legs, play some ping-pong, use facilities, whatever you're kind of into. Take breaks. It's a nice discipline. You do get tired, and taking breaks is super important. And do so whenever you feel like you need to. And with that, ask me anything. Who's got a question? Over here, there's a question. So my team has been doing pairing, but we find that, you're just subjectively, that it tends to slow things down by maybe 50% to 100%. In other words, things tend to go up to twice as slow when we do it. But we still use it for hard things like ramping up a new developer on a project or laying the foundations for a new project, but not for a lot of other things because of the time cost. And I was wondering if you could comment on how it affects your velocity and maybe we just need to look further down the road to see payoffs in velocity? Is it one of those things? Sure. So I'm hopefully not going to raise your hand if you could not hear the question. Everybody could hear the question. That's great. It would be great not to spend time repeating. So it looks like the mics are working. So you all heard the question. Velocity seems to slow down. I think that the empirical evidence has shown that at least in a controlled environment, pair programming has been shown to slow down accomplishment of tasks by 15.15% in a controlled environment. And I think that this was often with college students who are either paired up or doing solo. So that's certainly not 50, wow, 50 to 100%. And there are other payoffs. But I guess my initial reaction would be pair programming is a tool in the, I would call it the lowercase agile toolbox, not the, it's not necessarily mandated. But there are other things that you might be able to apply if you find that things are just going really slow. And that is identifying the issue. Maybe you've already done this. You've already identified, this is taking twice as long. And here are the five reasons why. And they're insurmountable reasons. So I would say you might want to use what's called a retrospective or dig deep into why things are taking too long. Are you arguing about stuff? Are the pairings so unbalanced that the senior people are constantly trying to pull up people who are more junior? Or are there differing opinions and people are just constantly arguing? There could be many, many reasons. So identifying the problem is the first step to figuring out maybe why it's taking that long because in my experience it should potentially be a bit slower on the metric of from moments on the keyboard typing the first characters to maybe doing a commit. Now that's not what encompasses done software. That's just two people coming up with the best solution. And you can have other payoffs further down the line such as your code is not as buggy. Your code is hopefully better factored because two people are coming up with the design versus just one, et cetera, et cetera. So I would encourage you to dig deep into why you're having these problems and see if you can address those problems. And then try it again and measure again. So, thank you. Just as a kind of follow on, my big impression is that in many cases the tasks are relatively straightforward and so it just wouldn't take a single person much longer to do them. Sure. And then so the other person is kind of helping avoid typos and that sort of thing, but maybe not adding as much value as they might be doing. Right. So we've had clients decide that they measure, we use a particular project management tool that lets us estimate stuff. And it's called Pivotal Tracker. You don't have to use it. Cards on a wall. Whatever works for you. So we tend to estimate things sort of on like a one to eight scale. And we've had clients who have said after they disengage with us, you know, anything that's a zero or a one, I guess I should have said zero to eight, they choose not to pair on those things because they finally don't get much value. That's great for them. But they have made a rule that, well, anything that's more than a zero to a one on an eight point scale, then that must be paired. So then maybe you reevaluate with the twos and the threes and then it looks like maybe the threes they have, those are getting pretty buggy. So let's bring pairing back into that. So that's a strategy as well. Let's go over here. If you could clarify, I have another question, but if you could clarify just for a moment that 15% increase, was that compared to one developer doing the task? Or was that compared to the relative work that two developers would do, you know, each individually, right? So one developer doing a task takes this much time, two developers doing the same task takes 15% more time, but then that other developer isn't doing any work, right? So there's actually less benefit than might be. Right. So I believe it was against a solo programmer working by themselves. But there were lots of other measures that showed benefit of pair programming above, you know, sort of out, you know, in the opinion of this report, outweighed this particular slowdown. So I think that kind of plays into my main question, which was how do you quantify to other stakeholders, particularly in the business and even other developers, and maybe measure the benefits of pair programming? I'm trying to incorporate it into our process more, but getting some resistance. We've given it enough to experiment with, but how do we actually measure the benefits and say whether it's working for us? That's a great question. Measuring the benefits and selling it to management or your team, selling it to anybody is, I feel, one of the hardest things to do. And even when I've been going over the empirical evidence, even the empirical evidence has said more studies need to be done, more sort of metrics for measuring the stuff needs to, need to be developed. It's, it is really, really hard to sell it because the math is just too easy. One plus one equals two. You just can't, like, fight that math. It's going to be, take twice as long and it's going to be twice as expensive, right? And like, why would anybody ever do that? And I think, and in my experience, you know, I could, I could, we could try to come up with some metrics and we can look at, you know, I could point you towards these empirical studies and they had particular measures of how they measured, you know, different kind of factors. And I find that that stuff, it, it bounces off people. Like, yeah, well, that's all great, but you've heard of one plus one equals two, right? And I think that this is an unsatisfying answer that I'm about to give you. There's a leap of faith that needs to happen. And I think you can kind of come back to, like, let's pretend we're in a world where we can still do TDD. In a world where we did TDD, that was a leap of faith too. Because it's like, that's twice as long. Why would you, you can't test something you haven't written yet and that's going to take twice as long. And I'm willing to bet almost everybody in this room has had that argument with somebody who doesn't practice, like not just TDD, but any kind of testing. Too slow, it takes twice as long. And finally, like, you're spouting all this stuff and you're talking about all the things that you make almost, I'm willing to bet everybody in this room love testing to somebody and it's just bouncing off. It's just bouncing off. And finally you're just like, you just got to try it. You got to try it. You're going to see the benefit, I swear. And then finally they do and usually you win them over. Actually, but I'll turn this around because I know that there's lots of people in the audience here who have been more on the sales side of pair programming than I have. Would anybody like to comment on the success stories they've had selling management or clients, if you're consultants, on how they address this issue? Anybody, maybe in this row here? Can I encourage anybody? Does anybody have anything to say? I've got a mobile mic. Excellent, Sarah. Don't break your ankle. Hello, hello. So what of the, is this working? Can I get this hand-held mic on? Oh, OK. Hello. Excellent. One of the easiest ways that I found to get pair programming into a team is to talk about the benefits of increasing your ability to absorb junior developers into your team. A lot of, I'm from San Francisco, a lot of companies in San Francisco are hiring their first junior developer, like right now. And so a lot of discussions I've had recently have been along the lines of, OK, so we're bringing on our first junior developer. Everything we do has to change because we need to vocalize a lot more things than we used to. And so what I tell them oftentimes is, like, OK, one of the ways you can practice that before the junior developer shows up is by pairing amongst yourselves, getting used to this idea of vocalizing your thought process, understanding how you talk about writing code with each other. And then you can bring someone in who's in a very different place, and you'll be better equipped to talk to them about it. Thank you so much. Excellent, so go ahead. I had two things to say. Part of selling a pair of programming. For me as a developer, it's been really awesome just because it forces you to get out of your own box of thinking and see how other people think about writing code. And maybe you thought this one practice of how to do something was bad because you got bitten by it once, but maybe you can get convinced that, oh, no, that's actually worth doing. It's a great way to share knowledge about gems that someone found on another project if you're coming into something. And then to the junior developer point, it's great because you're there and you ask, have you seen this part of the code yet? No, then you go through and you explain everything about it because you wrote it and you understand it so it helps bring them in more than just sort of looking through all this code that may not have comments or it was written by someone who left the company later. So those are my big selling points. I think it's made me a much better and much more open-minded developer and made it much easier for me to collaborate, which yields, I think, better code and overall makes your group better because you're just better collaborating and sharing ideas and sort of tears down the barriers of worrying about bumping shoulders and communication. We'll get kind of heated, like you said, and we'll just get through it. And in the end, come to an agreement on what will hopefully be a better idea or revisit it later. My question was kind of around pair rotation. So if you're working on a team in an office or we work with one of, we work with the client's developers separately, remote pairing, we'll spin up in EC2 instance. And we're trying to sort of figure out proper pair rotations so on a particular feature, two developers won't be the only ones who work on it, know it, and make some, except make all those decisions. And I'm curious what your thoughts are on that and what you have found to be a good rate of pair rotation if you've practiced that at all and things like that. Yeah, absolutely. So pair rotation, super important. I think several things can help encourage pair rotation. So yes, we do rotate pairs on a regular basis. There are extremes to this. There's something called, I've never done this, but it's been dubbed permiscuous pairing. I don't know if anybody has heard of this. And it's where you pair many times per day on a timer, basically. And there's been a little bit of evidence to show that that can be very productive. It's also shown to be disruptive and exhausting. So I think that give it a try, perhaps. But for us, for practical purposes, what we tend to do is it ties into the art of breaking down work. So we call our, the stuff we're working on, we call them stories. And we've gotten quite good at being able to break down deliverable stories to small enough pieces. This is in almost every case, to small enough pieces that, ideally, a pair of developers will be able to get one or two of them done per day. And a long story, we'll say a big story, it's going to take a long time, quote unquote, long. That might be several days, two days, maybe three days. So what I'm not saying is this is going to take three weeks to do. Now maybe there's a giant track of features, a huge feature set, the entire profile page rewrite. That might be weeks of work. But getting that link photo upload thing, just that small thing, that might be a day's worth of work or less. And so we tend to rotate pairs every day, if we can, at our morning stand-up meeting. And because ideally people will have completed one or two things previous day and they're ready to move on. And if they didn't complete it, there's just a little bit left. And you can wrap it up with a new pair the next day and go on from there. What will happen sometimes is that pairs will request to stick, if we call it. Working on this thing, it's really long. We have a lot of context. We'd like to stick on this. OK, second, that's the next day. Cool. Then the third day comes around. Like we're still, we're almost done. We'd like to stick. And the whole team collectively is like, hmm. Maybe? OK, maybe. OK, go ahead. Fourth day rolls around. We're really almost done, I swear. And at that point, as a team collectively, we should get somebody else in. Often at that point, the pair will say, one of us is going to swap out. Bob's going to stay on. Let's get who's available. Sally, you're available, jump in. Fresh pair of eyes, they're probably stuck. You need a new perspective. And so we will force rotation that way, too. And just maybe taking it a step further, something that will often come up after this is, yeah, we rotate very often. But it's kind of like the same people, like with the same people on the team, and kind of the same four people just kind of go around and around and around. What you can do to combat that kind of a situation where there's rotation, but it's not balanced amongst the entire team, is you can just start tracking it. Just you could do a whiteboard by keeping track of who's paired with who, how many times. All the way to a, there's even a website called Hair Tricks, I believe, where you can sign up your company and you can put all the pairs in and it'll randomly assign people and do weighting based on how long it's been since they've paired and things like that. So you can do something like that, or just keep track of it on a whiteboard or a Google Doc or something like that. Good questions? Kind of a follow-up to that. How do you combine that with sort of junior developers, making sure that they're not going through so much context, switching that they're not really getting anything out of it. They're just sort of starting a feature and then like, you know. So like in our case, we'll start something and it won't be done in one day and then sort of they'll switch and it's just kind of like, I'm kind of like lost. Right, right. I was barely getting to grasp that part of the code that I was going to work on. So I think just being flexible, just because it's 9 o'clock the next day doesn't mean that the judge comes in and breaks everybody up or something like that. And I think that if the team decides, hey, it seems like this junior developer, they're three quarters of the way, the senior and junior developer, they're three quarters of the way through this task they're trying to complete. Yeah, let them complete the task because they're going to get a lot of benefit out of seeing it from beginning to end. So don't be, I'm personally an advocate of just kind of playing it out here, just kind of seeing how it works out. Don't be so strict that you're being too disruptive. But don't let people stick to so long that you get these little sort of knowledge silos and ownership and such. Great. Thank you. Sure. A few questions on, I guess, team dynamics with pairing. Once I kind of a follow on to this one, I guess I'll spit them all out. Go for it. I'll mobilize things a little. One is, do you have any thoughts on if you have a group of spectrum of people at different experience levels? Can you talk about sort of the pros and cons of going with senior, senior, junior, junior people at like levels or to go junior, senior to get more mentoring? Have you had any barriers with tools where people just would be incompatible, say one guy likes VIM and one guy likes Sublime? And then thirdly, do you have any wisdom to share on adding a test or QA person to a pair to get that person involved early and what role a QA engineer would play throughout working on a story with a pair? OK, I may have to refer back to you to remind me what all those are. But I believe they were experience level pairings, tool conflicts, and adding a QA or a support person to the team. So let's do experience level pairings. I like personally, I don't consider it being a big deal to mix up almost any kind of experience level pairs except the junior, junior situation. I wouldn't just randomly personally do that. So the obvious one is senior and junior, those can be great pairings, especially for the junior person. And that may be a lot of people will talk about pairing and say, oh, we pair when we're ramping somebody up. And they'll kind of use that as the only excuse for pairing. We're ramping up this junior person. But that can put a lot of burden on the senior person. They're always ramping somebody up. If you get a new person every so often, then if they're a senior person, they might feel like they're always ramping somebody up. I would encourage everybody to have the attitude of, well, one, share the load. The junior person shouldn't just stick with the same person all the time. And also have the attitude if you're a senior person or have your senior people have the attitude that they can always learn the junior person. On the last project I was on, I've been doing software development for 16 years. And I was pairing with a guy who was fresh out of college. And he didn't even have a CS degree or anything. He was just one of those smart people who just graduated from college. And he was doing something that was clearly way below his skill level. We're like, you should probably do some programming. Here, get over here. And I learned something new from him every single day. And I'm a supposed expert. And every day he's like, oh, did you know about this? Whoa, no. That's really cool. I would usually write it down. I tried to keep track of the things I learn each day. And then people at the same experience level, that's great as well. You do sometimes have to watch out for people, especially senior and senior people, who maybe, let's say they once had the word architect on their names. Sometimes people can be extremely opinionated and not want to budge from ideas. It's something to watch out for. People kind of, we call it thrashing. Junior, junior, should you ever pair junior people together? And I think the answer is sometimes yes. Especially if they've both been through multiple pair rotations, they're kind of, maybe one of them has kind of been on that, let's make up the user, new user profile rewrite or something like that. A junior person who's kind of bounced between pairs, all kind of in that area, and they're kind of getting pretty good at learning some stuff. It might be good to swap in and have a junior person who doesn't have any experience in that area, pair with this newbie, but newbie with a lot of context. And then you can really help them exercise what it's like to have them own something, owns a bad word, whatever, you know what I mean. Bringing this other person up to speed, transferring that context. I've always found it amazing how when I feel like I don't really know anything and I'm really relying on this other person and suddenly the person I'm relying on kind of drops off and I have to explain it to somebody else, it really forces me personally to dig deep, understand the problem much better. And I almost always surprise myself both in how much I actually do know and how much I don't know. So once in a while having those junior people pair up and yes, struggle, like have problems, have to figure some stuff out the way we all used to have to do when we were working by ourselves. Okay, so that was a lot of that stuff. Tools, wow. You can see the email threads go around at our company. These guys know, these guys know. Keybindings, tools, Vim versus RubyMind versus, versus Sublime versus TextMate versus Brickin, Dvorak, give me a break. I mean, come on people. Yeah, that's a, it can be a huge struggle. And you can go to an extreme that I don't really know of anybody else doing. Maybe some of you do this, I don't know. But we pretty much standardize on a particular kind of key binding and often an editor. It evolves, it isn't like the manager doesn't come down and say, today we're a Vim company. The team ends up adopting and the people who are kind of holding on to those other texts they inevitably kind of like, okay, fine, fine, I'll do it. And I did that because I used to work out of the San Francisco office, now I'm working out of the New York office and they use different tool sets. It's just evolved that way and rather than stomp that out, we'd let it evolve and it's been great. My advice on that front would at least be this. One, be open to learning new things. Two, if you have your super awesome custom setup that's just for you and your own, your precious Vim bindings, don't stomp the defaults. Because maybe that person who doesn't really know Vim very well, they might, or Rubyvine or whatever your editor or tool of choice is they may not know your thing, but they may know kind of enough of the default settings that they can kind of get around and maybe they start adopting yours or maybe they say, yeah, I don't really use that key binding for this, I use it for something else and be open for that. But people can sometimes be too closed-minded about, you know, they build this little ecosystem just for themselves and not want to change and I encourage people be open to change but leave the defaults and be open to trying other stuff. But there's no silver bullet unless you mandate our office is a X office and everybody just learn it. Okay, integrating other people into the team like QA folks and if you don't mind, I'll sort of mutate that question into pairing across different disciplines or integrating anybody of any other discipline into the pairing structure. I'm a big fan of that. Be it QA person, design people, design, front end design or visual design, even your product owners, product managers, whatever you want to call them. I think that that's great. One, it builds up a lot of empathy just from a person to person point of view. Two, it can be super practical, especially with say visual design and actually QA as well. Like that last mile I've always found of say a visual design where, you know, you've pretty much got all the assets in, let's say you're building a webpage, got all the assets in and you're tweaking the CSS and all the stuff that came from visual design, it's pretty good right now, but you know that field or that area of the page that looked great with the lorem ipsum that only had like 25 characters? If somebody puts in 1,000 characters and they can, the whole thing goes, right, crazy? Getting visual design in to say, hey, like the last bit, let's just sit here and work on this and then you can just, especially if you're using like web, if you're doing web development and you can literally tweak it right there on the screen together, that can be super powerful and I've even been in situations where, you know, they were so good that they, you know, we were working on this thing and we're like moving stuff around, they're like, ah, now that we move this to here to here, those icons look terrible, hold on and they're like somehow spew out an icon out of their fingertips and they're like, okay, now pull in this icon and wow, it's just, it's like the most rapid changing finalization wrapping up of something I've ever worked in and that was one of the best experiences I've ever had pairing was with this person who was not technically a software developer. QA as well, I think, like a really good QA person is worth their weight in gold. I think if anybody here is kind of tied into the capital A agile community or at least extreme programming, you know, somehow the strange notion came up that like, you don't need QA, we've got tests for that and it's like, ah, those are two different things. So integrating QA people can be really good, especially if you're, if they're in a mode of, maybe you got a really big release coming up and they're hammering the site and finding all these bugs and pairing with them as you're fixing the bugs and as they're like pressing, trying all their different attacks on the system and saying, okay, when you fix that one, but that makes me think of this other thing. Oh, look, it's broken. Okay, try this, try this and like just kind of purposeful pairing when it's needed can be super valuable as well. Now I haven't say just, you know, like, where, hey, we're making an Android application and today I'm doing some, you know, a big feature and just pair with a QA person instead of another software developer in the middle or at the beginning of the development process, I haven't done that. But give it a shot. All right, that was three. I hope they were good. Cool. Quick comment about the cross tooling or cross editor. There's a tool called FluBits, F-L-O-O-Bits, which lets your VIM people work with your Amax people and the ideas, like, one of them's got their computer and the other one's got their computer and they're each running the same damn thing, but it's all synced and good and there's a fallback with just like a diff shipper for other apps. So it's- Okay, cool, FluBits. Yeah. I've heard of it, I haven't, I technically did try it when it was early and it didn't really work very well, but I'm gonna try it again. Because people have mentioned it. It's still fairly early, I think, but the promise is there and more plugins would probably help it. Excellent. So a couple of questions. One, when you're driving, how much vocalization do you do to the other person explaining your thoughts? And the other one is when you've got a senior developer paired with a junior developer, there's, I frequently find, I'm the senior one on the side and I know I need to let them work through it, but at the same time, I want to rip it out of their hands and it's like, what tools do you, techniques do you use to combat that and work with that and help them to learn? Sure. So the first question was, wow, this is really terrible. What was the first question again? Vocalization. Vocalization, yes, ironically. So vocalization and then being a keyboard hog, right? I'll take on a trip with that one because I can be that way. Or at least letting junior people struggle through something when you already know the answer, for example. Vocalization. I vocalize a lot, especially because I do remote pair programming and I lose a lot of the a lot of the visual cues and physical cues that you might pick up sitting side by side. I lose a lot of those. So when my whole view into somebody is from say the neck up, or like the midsection up, it's harder for me to say see somebody's hands. I almost never see anybody's hands. So are they reaching for the keyboard right now? Are they reaching for the mouse? Are their hands on their laps? You know, are they about to do something? I don't really know. When you pair side by side and out of right now, I can still kind of see you over there. And if I see this hand going out, then that's a cue for me to be like, oh, it looks like they want to do something. I wasn't in the middle of doing something, so I'll kind of back off. So maybe a little bit less verbalization consciously verbalizing anyway. But when I'm remote, I'm constantly saying things like, I'm going to grab the mouse. Can I look at this? Would you like to drive? Do you mind if I drive? All that kind of stuff. And to the point where I've pair programmed with remote paired with people, and they've told me later that they found themselves doing that much more when they were pairing side by side. And they felt it made them a better programmer or a better pair anyway, because they found themselves being more vocal even when they were in person, which I thought was great. What about vocalizing like, okay, now I'm making this case statement because of such and such. Do you go to that level? I will sometimes go to that level if I feel like that it's needed. Often, yeah, I'm kind of like constantly talking and I've recorded myself doing it so I could show like that for a presentation or something like that. I actually kind of hate listening to myself do all that. But I think it's valuable. And I find that often my pair will in sort of call me out when I'm not doing that. I'll be kind of like in a zone and kind of going and like the fonts are coming out and they'll say like, well, what are you doing? And I'll realize, ooh, I haven't, I'll realize I haven't been saying anything. I haven't been vocalizing it. And so, that I think is also kind of a tick mark in the be more vocal column. Were those the two questions? Junior developers. Junior developers, my God. Let's happen to me. Letting them work through the problem when you know it. Yes. So techniques for trying to let the junior people drive more when you're more senior. It's certainly hard. Some people never get it. Some people, it can be especially bad if you have a person who's, say, naturally or professionally more passive and somebody who's naturally or professionally more assertive. Tricks for that are just both sides trying to be more honest and vocal about things. Like, oh, in saying like, hey, do you mind if I drive now? Would you like to drive? I have physically sat on my hands, like underneath my thighs. And when I feel myself like, pull my hand out, I'm like, ah, get it back in there. Down. And ping pong pairing, if people haven't heard of that, is a great sort of structure to implement, to kind of enforce a rigidity in the bounce back and forth. So again, this is testing, test driven development. So if you're doing test driven development, you can have one person write a failing test and the other person implement the code to make it pass. And then they, the second person writes a failing test and the other person writes the code to make it pass. And you can sort of enforce that rigidity while you need it. And it can actually be a not so subtle cue that somebody is being a keyboard hog. And I encourage people to do this if they maybe don't want to be confrontational about like, give me the damn keyboard. But if somebody's kind of going, or say if you're going along and you're coding and everything's great, and then your pair says, hey, how about if we do some ping pong? Like, oh, hmm, maybe I'm driving too much. Or you can, you can say like, oh, let's ping pong this one. What do you say? Like that can be a, maybe a less assertive way of saying, let's balance it out. Chase, do you have something to say? Oh, just. Really glad you mentioned ping pong as a technique to help manage that. When I first started pairing, it was definitely something that was very hard for me to do and I had to do the same thing. I sat in my hands for three weeks. I saw people like, when I'm next side by side with someone, I'll see their hands come near the keyboard and mine will always leave or if their hands leave the keyboard, okay, that's my time to speak and I'll raise them up. So I've heard of some of the other paradigms like Driver Navigator, for example. What are some of the other pairing patterns in addition to ping pong and when might they be good to use? And what are their names? Okay. Let's see, yeah, Driver Navigator is sort of the canonical pairing structure people think about where one person is literally driving and one person is literally saying, okay, well, you missed this and hey, maybe let's use an if and not an unless there and that kind of a thing. And they're kind of also kind of looking over the rest of the code and say like, hey, how about we extract, finish that up but let's extract that as a method next and kind of a thing. As far as, that's the one I'm most familiar with. And that can be great. I think that's kind of the natural mode of most pairings is like one person is like actively engaged and driving the other one or actively engaged in typing, the other person is doing more navigating. I think that the challenge can be figuring out when to switch. Testing really helps for that. And if you don't do testing, let's say you don't, then maybe you can use some other kind of bounds like you just wrote this method, okay, now the next guy writes the next method or you're doing a bunch of refactoring and extracting classes and methods or something like that then you bounce back and forth between the thing you're extracting, for example. Okay, we've got a couple of minutes. One minute actually. The most useful thing that I ever did for stopping myself from over driving was getting a chess clock so that we could actually see how much time I spent driving. And so when I'm looking at the clock and I'm 45 minutes ahead, it's very helpful. That is excellent. And another technique is to just turn your keyboard over if you have two keyboards, just make it so you can't type. That's a really good one too. Okay, 40 seconds, go. Based on your experience, can you share what you consider to be good habits and effective habits in parabrogaming and then can you, are there pitfalls that people tend to fall into? Are there commonalities that you see in? Sure, in 25 seconds I will put it this way. I think the main thing is to remember that we're all human and that it's not really about technology or really about programming per se. It's about being patient and having a good attitude and building trust. So as long as we all have a good attitude with each other, trust each other, are patient with each other as we're all learning, I think that's really the key to pair programming. You can apply that to almost any situation but especially this very strange and extreme version of software development. I hope that helps. That's it, we're out of time. That's it, thank you.