The Rogues talk about pair programming.

 
AVDI:

Hey, I shave before I go on the show. Are you saying you guys don’t?

My legs are a little raw when I do, so. [Laughter]

Hey everybody, and welcome to back to episode 26 of the Ruby Rogues podcast. On our panel today… and when we do our introductions, we keep hearing that Josh is a self-entrepreneur, so I thought that it would be fun today in our introductions, if we all guess what this entrepreneurship is.

What his company does.

That is so not fair.

[Chuckles] So on our panel this week, we have Avdi Grimm.

Good morning or good evening or good night, depending on where you are and when you are listening to this. And I'm going to guess that it has something to do with office furniture.

[Chuckles] All right. James Edward Gray.

Hey everybody, it's James here. And if I have to guess what Josh Susser does in his selfentrepreneur stuff, it would be kitchen appliances.

All right, we also have David Brady.

Hey, David Brady here. I blog at heartmindcode.com. So the last time I was on the ADDCasts, isn’t dead. We’ve actually got an episode going up. So that’s going on. And I think Josh’s startup is… he is going to start a podcast with several Ruby experts, and when he goes live with it, he’s going to have like 26 episodes all ready to go.

All right. And Josh, go ahead.

So I really have no idea what to guess here. [Laughter]

It’s a really bad sign, Josh.

It's a total mystery to me. But I like all your ideas; I think I'm going to push through all of them.

All right, and I'm Charles Max Wood, and I'm leaning more toward sock deodorizer delivery company.

Or deodorant. Just deodorant.

Deodorant, yeah we were talking about that before the show. So this week, we are going to be talking about pairing. I know that several of us have experience with pairing; some of us have worked in companies where it's been done pretty much all the time. Others of us have… we are freelancer consultants and…

Wait, do we need a sommelier on the show now to talk about pairing, or wine with our meal?

Absolutely.

[In French accent] You are writing C code monsieur? I recommend the [inaudible] of the neckbeard. [Laughter]

If you think this episode is off to a bad start, you should have heard the preshow chatter.

No kidding. I've actually had somebody come to me, and asked to be on one of my podcasts. And he told me that he was a neckbeard. I don’t know, is that something you can actually claim?

It's the verification I worry about.

Okay, so wine and cheese aside, pairing… we are actually talking about pair programming.

Wait, we are?

Yes. [Chuckles] Sorry to shock you guys.

I've heard that you've actually spoken on this before, Josh. Why don’t you give us some insight.

Define it!

Yeah, a definition. The programming activity that requires [inaudible] that I've invented. [Laughter]

Pair programming, it's when two people collaborate on a programming task together. And there's a lot of different ways to do it, and I guess that’s where we will be spending the next 40 minutes talking about.

Right. So that leads me to a question, because it seems kind of like a loose definition. If I pull a couple of developers aside, and we start talking about… “Well, how do we wanna put this together?” And we chat about for 15 minutes, kind of get a game plan together and go split back up, is that pair programming then?

I wouldn’t call it pair programming.

Right. So it’s more than just a couple of people collaborating over some programming problem.

So the typical pair programming day that is the bread and butter of life at Pivotal labs -- where I spent four years -- is you have one big monitor and two keyboard and two mice, so that it's easy for each person to type and drive when they want to. And also, during cold and flu season, you don’t have to worry about germs. And that’s not a joke. That's actually important. But two people, siting side by side, looking at the same screen at the same time, and both people are engaged in the programming task.

So there is a lot of different perspectives about how the two different people take on roles during pair programming. Some people talk about the person who is driving, and the person who is navigating. I'm making air quotes with my fingers, which is horribly effective on podcasts. So there's the driver and the navigator. That’s not how I like to do it. I like to have both people engaged in driving, so both people are coding at the same time, although people are not typing at the same time – p robably the number one cause of injuries during pair programming.

[Chuckles] Is injury a common problem?

Simultaneous typing.

Mostly because if you type while Josh was typing, he will smack you. Look what you made me do!

[Laughs] And we haven’t even paired together. [Chuckles] So there's people who are like, they think pair programming is about one person sitting there dictating, while the other person types – and that’s not what it's about. It's also not about one person doing all the work, while the other person observes; it's both people being intellectually engaged the activity that’s going on right at the moment.

So that said, there are often different roles that occur; one of the ways where you can slice up a programming task -- especially if you are doing test driven development -- the pair will be talking about a problem, they'll say, “Okay, great. Here's something we wanna do; we wanna add a field to this form that asks for someone’s middle name.” And so one person will write a test for it, and the other person will make that test pass. And then once they've made the test pass, they'll write another test that fails and then the other person will… so we call that ‘ping pong’ pairing. I´ll make a test, you´ll make it pass; you make a test and I´ll make it pass. So that's a typical day.

So I admit that I am absolutely the least experienced pair programmer on this call. I just learned a few seconds ago that pair programming does not mean that having sex while you program. So I'm playing catch up here. [Laughter]

So James, I do have to put a disclaimer; in one year at Pivotal I was like working on a lot of different projects with a lot of different people, and I ended up pairing with like over two dozen people in that year, and I kind of got the reputation as the office slut.

Nice.

I was worried I got a TDD, but I got unit tested and it was okay.

Nice. [Laughter]

You got to remember; whenever you pair with someone, you're programming with everyone I've ever programed with.

Oh, that's nasty!

[Chuckles] But it's true.

[Chuckles] I now understand why you guys lobbied to do this episode. Okay, getting back on topic – or trying to – can we talk about some of the benefits; why would you pair program? I mean, if you just think about it in a simple sense, it seems like it takes two programmers, where you are only getting one thing done. So it seems like you are actually doing less.

Right. So there is actually have been some studies about the productivity that use pair programming and it's not… it doesn’t take twice as long to do everything, because you have two people doing the work that one person would be doing. In fact, it's quite the opposite; pair programming teams can be more productive – ‘per capita’ I guess is the term.

So I think as programmers, we all have some experience with code review; you write some code, you show it to somebody else and they are like, “Why did you do that? Why did you write this 50line method, when you just could have made this one API call?” So if you say, the longer I wait to get that code review, the more problems someone will find with my code; so you wanna tighten that feedback, so it's like, Oh, the tightest you can make that cycle is somebody is watching you write your code while you write it. So pair programming has often been sold to development managers as instantaneous code review.

I wanna jump in here real quick, because talking about some studies that said that pair programming can be more productive… and that just ties back to another issue that I have with programming metrics in general, and that is that how do you measure productive? Do you measure it on your code? Do you measure it in the number of features? Because not all lines of code created equal; not all features is created equal; not all anything is created equal.

And so, it's really hard for me to really buy into being able to prove that it's more productive. I think you can kind of get a sense of how productive you are, and I think some people and some pairs are more productive than others, maybe to the point where you are actually more productive together than a part, but I'm not sure if I’d buy that pair programming is necessarily always -- or even most of the time -- is more productive.

So I wanna jump in there because there's a couple of things I think people don’t always consider when they think about, “Would this be more productive or more effective?” And when they just think about, okay so there's two programmers working on the same problem, when they can be working on two different problems concurrently. So I mean the first one is that code review point. I cannot tell you how many times I've come across code that if there had been one other person at that keyboard and that screen, they would have caught the bug. They would have caught just like the complete brain fart that went into production code.

Like just the other day, I discovered that some code had some latent bugs, because the spec for it had failed. They basically put typos in the spec, so the spec wasn’t actually asserting anything. So the spec had left out the ‘should equal’ part of the assertions, and so the assertions did nothing, and so the [inaudible] that they were actually not verifying anything. That’s the sort of thing that when I'm pairing with somebody never gets through, or very rarely gets through. And it's also the sort of thing that may get through, even in a formal code review, just because code reviews are boring; people wanna get through them.

But the other thing is, I think the idea of these two programmers could be twice as productive as they are both working on separate problems, leaves out the fact that not everyone is working at a 100% all the time. And when you look at a typical programmer day, are you really completely engaged the whole time you are working on the problem? What I see with pairing is it really ramps up your level of engagement. Like if you are working with someone else… with the occasional exception of spontaneous conversations that break out, it doesn’t happen as often as you might think, once you get to know each other. You are just completely focused on the problem…

Oh, it is, but I mean it's absolutely important. But what I find is that, most of the pair programming time that I see is completely engaged with the problem at hand; except for the breaks that you take. You might have four hours of just exhausting, totally focused on the problem time. And I don’t really see that as often when people are coding alone, especially if the problem isn't that interesting. I mean, you might see that if somebody is working on a super interesting problem and they are just really excited about, you know, we've all done those all-nighters on a super interesting problem. But when it's less interesting, I think the pairing really brings up the level of engagement.

whenever I see A Star Trek Next Generation episode and two people are working on something together, and they are just like talking about their personal lives while they were working, I think, “These guys suck at pair programming.”

[Chuckles] That’s awesome.

So Avdi, you kind of mentioned that when two people pair, it kind of raises the quality floor. I've also had the experience where it also raises the effectiveness ceiling of the pair. This has only happened to me maybe a dozen times in my career, but it's almost magical when it happens; I've gotten to the end of the long day of pair programming, where we have really, really gelled, and then we turn around and we look at what we just did, and both of us realize there is no way a single human brain could have solved that problem. The gestalt of two programmers well-gelled, it was more than having just two people work on the same problem. It was like having a single pair that has a lot more brainwidth available than a single human being to bring to the problem. And just like really tough problems just get cracked as a result. It's really cool.

You actually brought to mind something else that I left out. What also happens with pairing is it's less likely that you will go down a blind alley, or down the rabbit hole. If you start to go down the rabbit hole, it's far more likely when you have two people, that one of them will say, “This looks like a rabbit hole. Can we somehow avoid this altogether?”

So I can't tell you how many times I've been carrying out a problem, and it was something where I would have just kept plugging away, going down that rabbit hole hour after hour and instead, my pair said, “Do we actually have to do this at all?” And we went to talk to the stakeholder, and they said, “Yeah, actually you don’t really need to do that.” I mean, that could save you an entire day of work, just having someone there to say, “Do we actually have to do this?” And so I mean, I think that’s another one of those things it's easy to miss about the productivity aspect.

So I wanted to talk about that a little. I've noticed that there are certain kinds of people I like pairing with more. For example, one for my big problems is I will just solve a problem. Whenever someone gives me a problem, then I just solve it. and I don’t think about it or decide or whatever. It's, “Can can you do X?” And I'm like, “Yup, sure can.” And I just go do that.

But I've actually paired with people in the past, that were very good at saying, “Yeah, we could do X, but it's probably a lot easier to do Y. we can do that in a lot less time. And we'll probably give you what you want anyway.” And kind of what Avdi was talking about there. “Is this really important? Is this the right way to go?” And I think when I'm pairing with those people, I find that it saves everyone the dramatic amount of time, because if they ask me for something, I just do it, even if it's a bad idea. Whereas, a lot of other people are good about saying, “Should we be doing those?” And then they get redirected back to what would be better for us to be working on.

I've actually seen a really interesting variation on that, which is maybe this is to be filed under ‘when pair programming goes wrong’ kind of thing, but where a lot of us will say, “Let’s do the problem this way.” And the other one says, “I don’t know if that makes any sense. Maybe we should try this other way.” And the other person says, “No, I wanna do it this way. We are going to do it this way.” And so, it's kinds of frustrating. There’s a little bit disconnect there and you kind of grind wheels.

And on this product that I am currently on, I’d say about 50-50, half the time, we get to the end and when I've been the person that's been kind of shouted down by my partner, about half the time, we get to the end and I go.. or halfway through, I finally see what they’re doing, I'm like, “Oh, okay that actually makes sense.” And I just learned something from it, and so there's some very important knowledge transfer and very useful for me to sit back and go, “How come he look at that, and just saw it immediately. And I had to be led to reach the solution?

The other half of the time, we get to the end of it, and I just kind of face palm and say, “See, I told you so.” Because the solution we end up with is this awful Frankenstein. And the really cool thing, and this gets to like what I mentioned with Avdi, where the conversations and the chitchat between people is really essential. Not just knowledge transfer, but also like social capital exchange between programmers, where they learn to gel and they learn each other, and learn to like each other and that sort of thing.

And because that had happened last week, I had a moment where we got to the end of the thing, and the thing that I've been questioning the entire time and my pair said, “No, no, we should do it this way.” We got to the end and my pair said, “Oh, wow, we really shouldn’t have done it that way. You were right.” And that was a very useful… he was the one going, “How come Dave saw that right from the very beginning?” And it was also very validating and social capital exchange there of saying, “You value my opinion. I'm glad, I value your opinion. This is good to go.”

I don’t want us to move on from the benefits just yet, because I think that it's good to... we are talking about productivity, we are talking about code quality. Just real quickly, there's a couple others. Sharing information or transmitting information. And so, if every problem is being worked on by two people, then there's never… so pretty much automatically doubles your bus number.

The bus number is the number of people, that if they were spontaneously hit by buses, would completely hobble your ability to move forward.

The number of people, that if they were hit by a bus, this bit of lore or knowledge would be lost to the organization.

The higher bus number, the better.

Yes. And especially if you are changing codes frequently throughout a project, then everybody sees every bit of code, and it breaks down that sense of territoriality in the code. So there’s less defensiveness about code, and just everybody knows what's going on in the whole project.

And not only that, the way that I learned how to do a lot of things in those couple of years is pairing with people who knew how to do them better than I do. And I've also spent a lot of time mentoring people and pairing with them. And it's just so much more effective to show somebody how to do it, and help guide them into their own leveling up and how to do it, than any other way.

I wanna chime in on that real quick too, because I paired with several people -- including Dave, actually we used to work together -- and I swear there were some times where we sat down, and Dave has a lot more experience than I have, and there were times where I swear, we’d sit down and somehow, he was still learning as much from me, as I was from him, even though I was kind of the junior guy and he was kind of the senior guy. Where yeah, there were some things that I had picked up, some ways that I learned to cope with my deficiencies, that I had never seen before. And just the same, he was imparting some wisdom that he has gained over, I don’t know how many years of programming, that I picked up and appreciated. So it goes both ways.

You forget why you know something and something comes along and challenges your assumptions and you re like, “Oh, let’s talk about that.” And yeah, if you wanna learn something, teach it to somebody. That's absolutely true.

I hear people ask all the time, “How do we spread out knowledge and our practices consistently around the team?” And my answer is always just pair program a lot. I mean, you don’t need anything else once you start pair programming a lot; the idioms and the knowledge and everything will spread out.

The anti-pattern to that is bringing in your expert programmers, making them work on the hard stuff, and making the newer guys work on the easy stuff, because then no knowledge gets disseminated. But a lot of people do it.

And the cool thing about this that was incorporated and help Pivotal does work with client developers is that, if you start a project with a bunch of Pivot developers and the client hasn’t hired any developers yet -- which is common when you got startup just ramping up -- then as you… the client would hire developers, they will join the team, some pivots would blow off the team. And eventually, you'd have a team staffed of pivots and clients, and then you just pair program together for some length time. And when engagement is over, the client developers know everything about the code, there's no hand off, there’s no, “I have to write 300 pages of documentation about how this code works.” Everybody just already knows how it works, and one day, they just start going to work at their own office than coming into Pivotal, and they move forward. It's the easiest hand off ever.

The other interesting thing though is that you are not just handing off the knowledge of the code base, but you are handing off the way that you built it; you are handing off cultural aspects and things like that. And so, it's an excellent way of maintaining not only the integrity of the code base, but the integrity of the company, and the integrity of the team.

It's equally valuable to have somebody say, “Let’s solve this using a class instance variable,” as it is to have somebody say, “Whoa, whoa, whoa, whoa, don’t push that to this server. We haven’t run the specs yet.”

Yeah, well said. And then productivity I think is actually a significant benefit. And it's not just the number of lines of code per day that you’re creating; it's the studies have shown that pair programming produces higher quality code because you got the code review thing going on all the time, that… the maintenance cost of the code… lower bug counts, so it's higher quality, you got lower defect rates, fewer failed launches, and the maintainability of the code overtime is much greater. Especially since because of the knowledge transmission, more people on the team are familiar with more of the code, so you don’t have these confusion moments when a bug breaks, and the guy who wrote the code is on vacation and nobody knows how to fix it. So if you look at two teams and one is doing pair programming, the other is not, that it can be much more productive.

Okay, but let’s be honest, this isn’t productivity just because you are too embarrassed to look at your Twitter account while some guy is watching over your shoulder? [Laughter]

To be fair, yes.

I was going to ask about that. When you take a break, do you pair Facebook? [Laughter]

That's actually a really good point, James. Like Avdi said earlier, it keeps you focused on a task, and you don’t spend all day sitting there in IRC or Facebook. But the downside of that, and not everything is a garden of roses, pair programming for 8 hours a day is incredibly hard work.

Agreed.

Yeah, it's exhausting.

Yeah, I find it harder to psych myself up for it.

You know, I wanna jump in here real quick, because I've noticed that a lot of the things that you guys are talking about are things that kind of come up after you've been pairing for a while, as opposed to necessarily when you haven’t been pairing for a while and you are just trying it out. I've seen a lot of friction which is getting started where people, they don’t gel well , or they don’t know how to communicate when you are pairing or things like that. What tips do you guys have for people that are new to pairing, that are just trying to get started and get used to some of the benefits that it offers?

So I´ll just do my pairing for newbies, which is that an important thing about if you are going to pair program every day is that you have a neutral setup for doing your pairing on. You should not be pair programming one person’s computer. And ideally, you shouldn’t be having one person visit the other person in his office; you should have mutual territory that is configured on a way that everybody on the team can use that hardware equivalently well.

And the reason for that is the power dynamic of being in my office, working on my computer, with all of my software shortcuts, and all of my configuration, is going to be more difficult for you to operate as an equal partner when we are pairing. So in a shop that does pairing well, they have a bunch of pairing workstation setup; usually it's a great big screen and two keyboards, and two mice and whatever ergonomic accommodations you have; box of mints, and some hand sanitizer and whatever else you need to get going. And you sit together working at the computer together during the day, and you don’t have to worry about the power dynamic of who owns what.

Well, I've actually paired with somebody where I didn't really feel like he was more in charge when we were working on his machine, but I spent a lot of time trying to figure out what I was doing with Emacs, while I was trying to program. And yeah, that can be distracting and I can see what you were talking about there.

Yeah, you have to have an editor that you are both comfortable with.

Isn’t that kind of one advantage of remote pairing I've found, that if you just launch up a Skype session, and one of you shares the screen for a while, and then the other one shares the screen for a while, I found the cool thing about that is when you re programming, you get to use your shortcuts and what's comfy for you. And all they have to do is read code, so that’s fine; they can handle that even if you are in Emacs. Or when the other guy is programming he is doing it his way and again, all you have to do is read. So that seems to be kind of one of the advantages of remote pairing.

I think it depends. I think if you are both controlling your remote machine where you’re using Tmux or Screen, then it might be a little harder. But yeah, if I'm coding up something and you are watching me, and we just switched to see your screen instead of mine, then yeah I think that will work just fine.

You can lose some context when you do that though.

It's true. You can lose some context. On the subject of tips for getting started, I actually wanna push a little bit on one of Josh’s earlier points about the rules in pairing. So I talked to a programmer at a recent conference, and she was saying, “We've been trying to do some pairing, but it feels like it's just I'm sitting there writing the code, and my pair is just kind of looking at my shoulder nodding it's head and saying, ‘Yeah it looks good.’” And I explained, “Well, typically when I'm pairing, if I'm not at the keyboard, then I'm watching somebody else code, and I'm basically telling them what to do; basically telling them what to type, what to do next.” And they are welcome to object at any point or to say, “Well, are you sure about that?”

But I wanna say something for especially for beginners, I wanna say something in favor of like the traditional navigation/driving school of pair programming. At least start out practicing those roles with some discipline; it really forces so that the person navigating that’s the person off the keyboard, they have to figure out.. they are responsible for what code gets written; for what we do next. And they have to figure out how to communicate their ideas, without just pushing the other person aside and saying, “Here, let me type this.” They have to figure out how to actually enunciate their ideas, which often helps them either flesh out their ideas, or realize that there is something wrong with their ideas.

And conversely, the person on the keyboard is in a mode where they are really absorbing somebody else’s perspective, rather than sitting there and just like doing their own thing, and just getting approval periodically. They’re basically almost acting as somebody else’s hands, and getting that hands on feel for how somebody else thinks. And in a lot of cases, I see beginners of pair programming falling in the system of one person on the keyboard doing all of the work, and the person over their shoulder sort of nodding and smiling periodically. And so I do recommend at least getting started, trying out those kind go strict navigator-driver roles.

Well, we all need to take turns exercising our necks every every once in a while.

[Chuckles] Yeah, so Avdi, I´ll agree with everything you said; I think that that’s the drivingnavigating setup can work great for bringing someone up to speed in training.

One thing that I've noticed too when I'm navigating, as opposed to driving is that since I'm not concentrating on getting it into the machine, running the test, doing all of the other stuff, I can kind of half watch and make sure that all happens right. But I tend to be able to spare more brain cycles for solving a problem. So in a lot of cases, I can get two or three steps ahead and be thinking about things while my pair is doing a work of getting into the machine and typing it up. So that when we move on to the next stage of the problem, then I'm ready to make my contribution.

I think what Chuck just said there is kind of important. One of the things I was going to say that I've learned in doing it, when I first started pairing, my instinct was I need to talk a lot and contribute a lot, and make sure I'm pulling my weight. And I think that was really annoying to pair most of the time, because you are trying to think and you are breaking up mental stack.

And I think as I've gotten better at it, I've learned mostly just to shut up a lot. And that if they are flowing and moving forward, great, then my job is just to sit there, observe what they are doing, look for problems; like Chuck said, potentially think ahead. And then I usually find when they pause, or stop or get stuck, that’s usually a signal for me that I've been siting there thinking, and I've got the next idea, so I just toss that out there, and then that usually gets us moving forward again, and that seems to make the process a lot smoother.

So there's two sides to that. And I think that you can use that to your advantage sometimes, but there is a downside to that; and that’s that you are not as fully engaged in what your pair is doing at the moment. And you are not going to be as good at catching bugs or the mistakes that he's making while he's working.

Josh, you just used the magic word there -- engagement. For me, it's all about engagement. And if pairing is going badly, it's because we are not as engaged as we need to be. And I find that if I find myself typing, doing all the typing and my partner is silently nodding, I start thinking, “How can I get this guy engaged?” And the easiest way to get your partner engaged is give him the keyboard.

I won't completely disagree with James on the being quiet, because I was about to jump in and say no. Nine times out of ten, if you are having trouble pairing, it's because you are not talking enough. I find myself especially navigating, when my partner is driving off and he is not telling me where he is going or what he is doing, that's when I start kind of getting in his face saying, “Talk to me, tell me where you are going. I need to engage with you.”

Talk to me. Talk to me.

Yeah, exactly. But if you are well… and he’s cruising, then absolutely. But the majority thing I think newbies fall into the pitfall, is that the navigator doesn’t work hard enough when newbies are starting out. So I have ADD; some of you may have read about this somewhere, but I used to bring my laptop to pair program with. And there are some people that absolutely forbid laptops, because it's a distraction, right? If you are navigating and you are typing in your laptop, especially because I've got Twitter open and Facebook open, this is really bad etiquette for pairing and that sort of thing.

But if your partner is typing something that’s like, “Oh crap, how do I do this?” And I've got it googled and pulled up on my laptop before he's even finished asking the question, I feel like I'm doing a good job as the navigator. If I find myself spending too much time on Twitter, if partner says something funny, that’s going on Twitter. But if it's like he's writing code while I'm writing on Twitter, it's time to close the laptop; the value of navigator having the access to Google is being completely subverted by the navigator having access to distractions. And it all comes down to just one word -engagement. How tightly engaged are you?

Yeah, some people like to have separate computers for people to do research on, and have the pairing computer where you do you coding. Other shops just say, “No distractions. No other computers. Everything you do is [inaudible] of attention on the same place.”

I will say, if you are at the keyboard, and you feel like your partner might be sleeping away somewhere, don’t be afraid to just say… just sort of lift your hands up and say, “Okay, what next?” I think maybe some people are afraid to be dumb, when they are at the keyboard. They’re afraid to look dumb or look like they are at a lost, but I think that’s fine. I think that’s completely fine to just periodically say, “Okay, what next?” I do that a lot when I'm at the keyboard.

Yeah, I actually tweeted this yesterday, but the thing that I wanna say to people who are new to pair programming, is that like any other thing that you do as a programmer, pair programming is a learned skill. It's not something that you just take to naturally. And for many people, it's a very challenging skill to learn.

And I remember Obie Fernandez wrote this post couple of years ago talking about how pair programming isn’t for everyone. And it's a thing that only some people were capable of doing. And it caused a lot of ruckus when he did that, but my response to that is it's a skill. And most people don’t like doing things that they are not very good at; they struggle with it, they find it unsatisfying. And if you can learn the skill, have some patience and give yourself the time to learn the skill. When you get good enough at doing it, you´ll actually enjoy it and you'll find yourself getting the benefits of pair programming, rather than hating it and struggling with it.

Yeah, I try to tell programmers that are new to pairing -- especially if they are good programmers -is to say, be patient with this. Remember that your entire skillset does not translate here. You learn to program alone; you learn to program in the quiet; you learn to program in silence of your own head. None of those skills are going to translate; in fact, they are actually going to hand strain you.

Be patient; be willing to suck at this, and talk to me. Get your brain out there so we can integrate.

So I have one more question. I wanted to ask about remote pairing, because a lot of this pair programming talks that we had has been focused around sitting next to the guy that we are pairing with, but what if we are sitting across the world from the guy that we are pairing with? Is there any tricks to that? Is there something different about that?

There are, and I've done a fair amount go them is pairing. I think Avdi has done a bunch of remote pairing too. I have a pick for that, so I don’t wanna talk too much about it. I have an important thing to add before we jump into the picks or what have you. So I wanna drop this message in here, which I think is more important than remote pairing, and that if you talk to people who pair a lot, the most important thing for being able to operate effectively pair programming, is that you have to get you ego in check.

And so if you've you've ever seen like a tight jazz group jamming out, the drummer is not trying to hit his drum as hard and as loud, and as fast as possible, he’s listening for the places where he can do something that’s going to compliment what other people are doing; hitting something where it is going to make the song sound better.

And when you are pairing with somebody, it's not about typing all the time, it's not about you driving all the time, and it's not about you getting your own wall all the time. When you are doing it right, you get your ego in check, and it stops being about you showing off and you getting your way, and you demonstrating that you are smarter or you know what's going on; it's about the two of you working together, you become kind of a group mind and you just focus on the task. And stops being about you and what you can do, and it becomes being about what you can do together as a pair.

Yeah, that’s awesome. I have a very urgent pairing message as well, which speaks very much to Josh’s point about there really ought to be a neutral machine. I don’t think I've ever paired in a company where there is a neutral machine, so I have invaded other people’s laptops, other people have moved in to my machine. I've basically forced myself to become fluent in Vim and in Textmate -- even though Emacs is my editor of choice -- just because if Vim is your editor of choice, then I want to reduce any kind of barrier that you have to the pairing, because I think that’s more valuable. I think the text editor is not the bottleneck when you are pair programming. And the original message that I have to anybody out there is that if I have paired with you and the machine is still locked in the Dvorak key layout, shift control back is the combination that will unlock it. And I'm very sorry.

Anybody who has paired with me, the first thing I do is I turn on Dvorak keyboard layout, and then I

go enable ctrl+shift+back to toggle between US and Dvorak layout. And then invariably, how about once a year somebody will say, “I can't log in.” [Chuckles] And I'm like, “Oh, and you can't tell me your password? Okay, let me go print out you a picture of the Dvorak keyboard.” And they play a little geography matching game to try and figure out how to type the password.

David was the kind of jerk that in high school, when you ask to borrow his calculator, he handed you that thing in RPN mode, you can use it anyway. And the fact that I know that says nothing about the kind of jerk I was in high school. [Laughter]

All right, well let’s do the picks. Let’s go ahead and start off with Avdi.

All right, I have just one pick today, and it's going to be Google Plus Hangouts, which are probably the best way to have distributed teams, stand up meetings, that I've seen yet. And it's 100% freer than all of the other lower quality solutions – at least right now -- so I love doing standups on Google Plus.

Actually, can I do a quick self-plug? I don’t know if it's really a pick, but just on the topic of remote pairing, I have a whole podcast dedicated to distributed team issues -- wideteams.com is the address. So if you are interested in remote pairing and stuff like that, I've interviewed dozens of programmers and people involved in distributed software teams on that podcast. You might find some interesting stuff there.

Dave, do you have your mic set in Dvorak yet?

Yes. [Chuckles] Okay. So I have two picks -- both for pair programming. The first one is Qido, and I´ll put a link on the show notes for that, which is it's a little USB key dongle. It looks like USB thumb drive, expect that it’s got a USB port on the back end of it. And what it is you plug it into the back of the computer, and the computer says, “Oh hey, there’s a keyboard here.” And then you plug in a USB keyboard, and I can type on that USB keyboard, I can type on it in Dora, with no translation.

The keyboard is sending qwerty, it hits this little Qido, which stands for ‘Qwerty in, Dvorak out.’ And it translates it out to the Dvorak layout. And so, I can type the home row, asdf and it goes through… or rather, I can type my home row which is AOEU, and it goes through Qido and it comes out asdf or vice versa. So the end result is that I can sit down at your computer, and I can plug this thing in, and I can plug my external keyboard in, and your keyboard is in qwerty, my keyboard is in Dora, and there was no software driver, and you don’t have to remember that stupid shift ctrl back thing to get out of Qwerty in Dvorak.

That’s kind of awesome.

It's really, really slick. And people that I have pair programmed with, they really love it; especially the ones that I've ever locked out and not able to log in.

And so it will make your sys admin freak-out because it looks like a key logger. And in fact, it was made keyghost.com, who makes key loggers. And just somebody at the company says, “Hey, we make these things that make key loggers. Why don’t we make one that makes key translator?” So that’s what they do.

“It’s a key translator, I promise.”

Yeah, exactly. Just type your password here. And my second pick for pair programming is Dove Men’s Care products. Specifically, they have an entire line of deodorants that are not antipersperants.

I am allergic to most anti-persperants like aluminum hydroxide. I'm not really like allergic, allergic, it just gives me a rash and it's very uncomfortable and I don’t like to wear it. And as long as I am in a dry climate, nobody complains. So I actually stay out here in Utah. But when I go to LA or when I go to Houston, it's not too long before somebody pulls me aside and gives me the talk that I have given to other people about their BO.

And so if you’re going to do pair programming and if you sweat a lot, and you don’t like to wear anti-persperants, go to Dove Men’s Care deodorant, which is they've got a variety of supple fragrances, and they don’t burn your arms and make you sticky and they are hard to wash out. It's just get rid of the smell for 48 hours. It's really nice.

All right, good deal. James, what do you have for us?

Listening to David’s picks, I'm reminded of The castle episode where the guy who make’s men’s products dies and Castle is all hung up on his products, and getting pretty [inaudible] and stuff. And then, they later find out they have these medical problems and every…

They have Butane in them.

Yeah. I think that was hilarious. So that’s kind of a quasi-pick. I do enjoy Castle; it's a witty, fun show. If you haven't seen it, you should check it out.

Okay, as far as picks though, I have a couple; first, when I'm building a new site, I always struggle to find a usable background image pattern thing. And inevitably, I end up making one and it's absolutely horrible because I have no artistic skill whatsoever. So anyways, I got sent this cool site yesterday called subtlepatterns.com and it's a great site of just a bunch of background images that aren’t ridiculous, they look good. You can go through and preview them right there on the site and stuff like that. It's really handy. So if you are like totally inartistic as I am, then this site is definitely very helpful.

And the other pick I had just what I've been reading lately, I picked up the Kindle’s single of Sam Harris’ new… it's really more of an essay than a book called, “Lying”. I'm about half way through that and really enjoying it. So if you haven’t read Lying, you should do it. it's a Kindle single; a $1.99, and it's all about how do humans lie, how do we lie, is it okay that we lie, stuff like that. And it's really, really excellent, so I recommend checking that out.

All right, thanks James. Josh?

Okay, so I thought I’d say something about remote pairing in the picks, so remotepairprogramming.com. So that’s the site set up by former coworker of mine, and he does remote pair programming all day long. He is in a remote office, so he comes here all the time. And he's been doing a lot of talks in the Atlanta Ruby Users Group and various places like that, talking about how they do remote pairing well. And so he set up a blog about it and he’s just been doing a lot of stuff there about what kind of tools to use, and etiquette and practices and how to be effective. So that’s definitely worth checking out.

And then I have another pick for another Pivot, Jeff Dean did a blog post this week about how to do your own object creation methods, instead of using a fixture replacement library factory library like factory girl or the like. And I'm calling this one out because this is the blog post I've been meaning to write for a while. And this is a pattern that gets used at Pivotal a lot. I´ll like this pattern. It's pretty much just about the same amount of effort to use this pattern as it is to use a library like factory girl. And you don’t have a lot of the weird, quirky problems that you get with some of these libraries.

Personally, I don’t like the declarative syntax for doing by test object creation, because big things often need to be done in some sort of sequenced order, and using a declarative syntax for that is really hard sometimes. So just having methods, where we have a little snips of Ruby code in there that do what you wanna do works fine, this is a great place on doing it. So it's called “Rolling your own object creation methods for specs.” We'll have the link in the show notes.

And then I have a last little pick here which is The Adventures of Merlin, which I've been watching on Netflix streaming lately. And if you’re a fan of the Arthurian mythos, King Arthur and the Knights of the Round Table, and you like your classics classic, this will kill you, because they've take liberties with everything; they’ve reinvented everything. It's like Arthur is a kid growing up… or Merlin and Arthur as young kids growing together. It's like, it drives me nuts. But if you can set that aside, it's actually pretty true to the theme of the myths. And they got a lot of it right. So I've been pretty happy watching it as soon as I set aside my classicist hat. I've been enjoying it a lot. It's worth checking out.

Yeah, I've watched a bunch of them, and then I stopped because I thought my wife would like it, so I'm trying to get her to watch them now.

So the first pick that I have is one of those non-concrete ones, and that’s basically just community involvement. When I was out in Colorado this last week, I wound up after the podcast, Tim Pease told me that the Boulder Rb group was getting together, so I drove for 45 minutes from where I was staying up to Pivotal Offices over in Boulder, and went to their users group meeting. And I also wound up having launch with Fernan Galiana, who runs the Derailed Group. And we wound up having a good chat. I was only planning on having lunch with him for like an hour or so, and we wound up chatting for like 3 hours.

So, you know, it's just nice to be able to get together with people in the community, so if you are traveling, or even in your local area, find those communities and hook up with people; get to know them, find out what they know, find out what they are good at, and make those connections. Because it's not just what you'll get from them, but it really is a way of coming to appreciate the community that we have around Ruby and Rails, and just some of the great people that are out there. So, that’s my only pick this week.

I'm going to go ahead and wrap this up, and just remind you that you can get the show notes at rubyrogues.com. And you can find us in iTunes, you can leave us a review there just do a search for Ruby Rogues, and you should be able to find it in there. Thanks for listening and next week, we are talking about training with Mike Clark. Is that correct?

Yes, Mike Clark. Specifically, teaching Ruby.

Okay. So if you are interested in teaching Ruby or I'm sure he's going to have some great tips, so looking forward to that next week. Don’t forget to read out Book Club book, which will be reviewing in the beginning of December. It's Eloquent Ruby by Russ Olsen. And that’s it. Thanks for listening.