I Love Pair-Programming
In the comments for my review of “The Art of Agile Development” an old colleague asked me a few questions about Pair-Programming, one of the key tenets of XP (which the book advocates). My response so was so long and detailed that I felt it deserved it’s own post.
My current job is the first one where I’ve ever pair-programmed. I actually recall interviewing for it, and I was asked if I had pair-programmed before. I said sure, occasionally I would pull another developer over to my desk to help me and we’d sit together to figure it out. This apparently was a decent enough answer to the question that I got the job, but now that I’ve been pair-programming nearly full-time for five months, I’ve determined that what I was doing before was definitely not real pair-programming.
When I first heard I’d be pairing at the new job, I was a bit apprehensive and skeptical. Do I really have to sit next to some fat developer all day, 40 hours a week? When am I going to check my RSS feeds? What if the other developer is gassy or hasn’t showered? How am I going to listen to my totally awesome Death Metal if I can’t wear headphones? Will the other developer be constantly judging and correcting my code? Will pairing prevent me from hitting “the zone” where I’m just belting code out so fast that my fingers can’t keep up with my brain?
Over the last five months, I’ve found answers to all of these questions: “no,” “often,” “that’s rough,” “easily,” “sort of,” and “YES, but that’s a good thing.”
The Mechanics Of Pairing
The way pair programming works in practice is quite a bit different than I imagined it. I envisioned a day where I couldn’t escape the company of some other developer, constantly having eyes looking over my shoulder. I’m not a terribly social person, so the idea of interacting with a single human being all day was not my idea of a good time.
In reality, you don’t sit down at a desk with another person and work all day with them. You pair up for tasks.
So, once all of the stories for the iteration have had concrete tasks assigned to them, people pair up to do them. So a dev and I might pick a specific task and work on it together. Two other devs pick another task. My pairing partner and I sit at a big 30 inch monitor and work on the task (just that task) together. Generally when you pair one person is the “driver” and one is the “navigator” so one person is implementing code and the other is thinking of design implications, refactoring opportunities, or the “next step” for the task. If you get stuck or pause or just want to switch, you pass the keyboard to the other person and switch roles.
When doing Test-Driven Development, one of the things we do is called “ping-pong pairing”. So the other developer will write a test, then make it compile but fail. Then he passes the keyboard to me. I implement the feature just enough to make the test pass, then I write another failing test and pass it back.
When the task is done and code is checked in, the pair breaks up. Generally tasks only have 2 hour estimates (sometimes less) so you’re only pairing for the two hours. Then you pair up with someone else to work on another task. If a task is taking longer than expected, or the pair “goes dark” (meaning they aren’t talking) then you shuffle the pairings.
Between these tasks, you might go have lunch, or take a break from coding to watch a video on youtube at your desk, or check your RSS reader for a few minutes, or go take a walk, or go downstairs and play some ping pong or foosball. We take breaks often because getting away from the code for a few minutes helps keep a fresh perspective when you come back to the task. Physical activities like walking or playing ping pong help with blood circulation, which helps your brain.
It’s also nice to have an odd number of developers, which we do. This way, one person is working without pairing. Usually this person will work on a defect instead of a story, or they’ll work on a story where everyone understands what needs to be done for that part of the code. If you don’t feel like pairing or you need a break, you volunteer to be the odd man out for a task. When I first started pairing, I frequently volunteered to be the odd man out and work alone. Today, having been pairing for a few months, generally I try my hardest to avoid being the odd man out.
In an 8 hour day, I’m probably pairing somewhere between 4 and 6 hours noncontiguously. It’s important to have a good setup for it – big monitors, comfortable chairs, no corner desks (so that the devs can be side by side at the flat desk with the monitor between them).
Effectiveness
I see pairing work so well every day that I consider my career prior to my current job to have consisted mostly of wasting time. When I think back to all the code I’ve written for a job, I’m annoyed at how much less efficient I was then since I wasn’t pairing, and how much better my code and my products would have been if I had paired on them full time.
When you have a second person working with you, you find that you try harder to code well. You’re far, far less likely to be willing to apply duct tape to a problem, because someone else is working with you and he or she is more likely to object to the duct tape. If two people approve a hack and implement it, it’s almost certainly because it’s the right approach given the time constraints. If one person sitting alone decides to pursue a hack, it’s more likely to be a situation where there is a better approach.
Two people attacking a design problem together is easier than one person doing it. Your partner will think of things you don’t, and vice versa. In a non-pairing environment, you can always call someone to a whiteboard to help you work through a design issue, but when you do that you’re only calling for help when you know you need it. The times when you need help and don’t know it go unaddressed – and yet despite the fact that you need help, I guarantee that you’re coding SOMETHING and checking it in. It’s almost certain to be shitty code. The amount of time you spend trying to figure out “what’s going on here” or “why isn’t this working the way I expect” is severely reduced. I’m talking hours of debugging that literally turn into seconds.
Pairing also helps a great deal with collective code ownership. I don’t feel like there are any realms of the code that “belong” to any team member. You don’t have a situation where one person is the “expert” on a part of the codebase, since that person worked with someone else when they wrote it, and everyone likely shuffled around while it was developed. EVERYONE has seen that part of the codebase before, which means EVERYONE feels comfortable refactoring or extending it. This enables the team to perform improvements to any part of the code whenever they are working, which leads to technical debt being paid off very quickly. I often find myself shocked at how good the quality of the code is that we write and that we’ve written before. The product is ENORMOUS in code size, easily the biggest I’ve ever worked on, but there are very few areas of code that I would consider bad at all, and all of those are the earliest parts of the code that were written (and were written without pairing or TDD).
Pairing fosters a collective unity that I haven’t seen anywhere else. There are obviously issues and challenges, and there’s no denying that you’re producing fewer lines of code per day since only half your team is coding at any one point. I don’t consider that a bad thing, though (if you have two solutions that equally solve a problem, the solution with fewer lines of code is the superior one) because the QUALITY of the code that IS produced is so, so, so much higher.
Challenges
There are definitely some challenges to pairing. Pairing at a corner desk absolutely does not work at all. The developers need to be side by side, the same distance from the monitor (which needs to be large). All instances in my career that I thought were “pair-programming” were not, because we were at corner desks. The person further away was, as a result, not as actively involved in the code (moving chairs is harder than moving a keyboard over a few inches). This isn’t pairing, it’s programming with someone watching over your shoulder. It feels like you’re being watched, not like you’re working with a peer. It sucks. I’m so glad that this is NOT what real Pair Programming turned out to be.
We have a team area with individual desks surrounding the area, but with “pairing stations” in the middle of the room. I find myself at my desk so infrequently (by choice) that my friends on IRC complain I never say anything on the channel. A good pairing environment is crucial.
Hygiene can be a serious problem. If one person smells, it’s rough to sit with them. I find myself going back to my desk often and the code suffers for it. If you’re pairing, take a shower, and hold your farts for your next bathroom trip. Just do it, you filthy pig.
The biggest challenge for me personally was essentially mourning for the death of “Programmer Man”. Programmer Man is how I think of myself when I’ve got my headphones in, speed metal blaring in my ears, and I’m coding like a motherfucker. My fingers can’t keep up with my brain. I’m In The Zone. For most of my career, this image is what I’ve considered to be the zenith. When I come home and was in Programmer Man Mode most of the day, I feel like I’ve had a good day.
Pair Programming undeniably killed Programmer Man. This was a tough adjustment, since I’ve considered that mode to be my favorite for so long. I now see, however, that Programmer Man was, without me knowing it, Technical Debt Man.
When you’re coding like a motherfucker, you’re often writing bad code. You’re more likely to be outputting hundred-line methods. You’re sometimes willing to skip writing tests (tests slow down Programmer Man). You’re not pausing as much to think about design implications or ways that the code could be refactored. You may not have time to fix the code you’re working WITH; Programmer Man is too busy working on his own code to give a crap about some other guy’s code. Programmer Man’s code is almost certain to be more brittle and more poorly designed than if someone were sitting with him, making him slow down and THINK more often. Programmer Man’s code may not have been BAD, but it was generally worse than if he had a partner.
Programmer Man was too busy coding to do as much serious thinking, and the quality of the code suffered for it. And in the situations where you can be headphones-on, heads-down but still write tests and think about design, modularity, and quality, it’s almost certain that two heads would have been better than one. If you’re coding at a reasonable pace, pair programming will not slow you down. Conversely, if you code so quickly that pair programming slows you down a lot, you were making mistakes before. You need pairing more than anyone.
Programmer Man is dead, but I don’t miss him. Not anymore. My standards for what is “good code” have greatly increased and quite frankly I’m not sure ANY of Programmer Man’s code ever met that standard. Today, nearly all of my code does, and I have pairing to thank for it.
And the headphones situation is easy to solve as well – at work we pick a musical theme at the start of the day, then use Pandora to provide music consistent with that theme all day. I get my “Killswitch Engage” theme and my “Slayer” theme days because I graciously put up with another developer’s “Angels and Airwaves” theme and “The Cranberries” theme.
Final Thoughts
When I leave my job (which I don’t see happening any time soon) if the next company doesn’t do pair programming, it’s going to be a tough adjustment to me. It would be like walking into a new company and finding out that nobody uses version control – everyone just copies their changes to a shared directory at the end of the day. Sure you get the job done, but god damn you’re being inefficient about it. When people hiss at pairing because they can’t listen to headphones or don’t want to sit next to a fat guy, it sounds to my ears EXACTLY like someone complaining about SVN being too complicated.
I’m not going to advocate pairing, because anyone who reads this post and says “hey, maybe we’ll give it a shot” and then forces their team to do it will find that it doesn’t work. For pairing to work, everyone has to WANT to pair. That means they all at least need to be curious enough about it to give it a genuine shot – attempting pairing with the attitude of illustrating it doesn’t work will certainly show that it doesn’t work. If you’re holding onto Programmer Man, you’re doomed.
But if you’re willing to give it a genuine effort, push through the challenges and difficulties, read a book or two about how to pair, or maybe even hire a mentor to come to your company and help you pair for a few weeks, I think you’ll be pleasantly surprised by how effective it is.
Absolutely No Machete Juggling is a blog about software, programming, computers, and me. I'm a programmer working in Colorado, mostly with Java and Ruby. 
Jake:
Lots to think about in this post. Good stuff.
21 February 2009, 10:28 amDemian Neidetcher:
You’ve made a compelling case. I wouldn’t argue that I couldn’t benefit from pairing. I do think that my “Programmer Man” does TDD; it’s part of my being in the zone. Write a test, it fails, make the test pass, repeat. Claiming my design is flawless in those instances isn’t as black & white. Although when I’m in the zone I’m usually replicating existing patterns, gotta get out of the zone for new design ideas and possibly socialize them.
This might be something that I’ll ‘get’ some day and kick myself for not doing sooner. As it is, I’m still in the not-getting-it camp.
21 February 2009, 11:24 am» Pair Programming killed the Uber-coder… « amazing development:
[...] stumbled over a great eassy on pair-programming (via James [...]
21 February 2009, 1:49 pmMark Nijhof:
Very nice to read and good story about pair programming. Thanks :)
21 February 2009, 2:35 pmToby DiPasquale:
I think some of your assumptions are a bit off. Most of the highest quality open source code is written in isolation with the “pairing” aspect of it happening via community interaction. Pairing can be great, but it can also be counterproductive if the people involved aren’t into it or can’t make the transition smoothly. Pairing with physical proximity is part of XP, yes, but need not necessarily be part of quality software development. As far as that goes, TDD is a far more important practice than pairing with physical proximity.
Oh, yeah, and vi? There’s a reason that its been around 40+ years… You’re making the very common mistake of bashing something without understanding it.
21 February 2009, 4:59 pmJoe Ganley:
Correlation does not imply causation. Killing off Programmer Man is a good thing, but pair programming is not necessary to make that happen.
21 February 2009, 5:02 pmRod:
Toby:
I agree, TDD is far more valuable than Pairing. My point in the post is simply that pairing wasn’t at all what I expected, and I enjoy it a great deal. I, personally, produce far better code when pairing than I did alone.
Like I said in the post, I’m not advocating pairing, I’m just explaining how it’s affected me. And you are right, if the people involved aren’t into pairing it doesn’t work (I say the same thing in the post as well).
Joe:
Pairing makes it easier to ensure Programmer Man is not resurrected.
21 February 2009, 5:30 pmAngelo:
I’ve had to work in a “pairing” situation several times and it’s insufferable if the goal is to actually produce something. It’s like trying to drive a dual control car with an adolescent at the wheel that somehow imagines themselves to be the reincarnation of Aryton Senna. They will not understand any words of wisdom or appreciate any actions you take, because understanding requires experience and not just information. In the meantime it destroys your productivity while making the ignorant kid look good and still completely oblivious to the fact you saved them from wrapping themselves around a tree.
The few good programmers I’ve met cannot abide “duct tape” solutions if it can be at all avoided. They don’t need someone looking over their shoulder to make sure they’re doing the right thing, because they know themselves and the quality of their code is part of their identity.
Anyway, the entire debate is moot. Pair programming died as a viable approach half a decade ago or more. Anyone or any company still trying to push that barrow is simply not going to last. Still, that’s good news for those of us that can actually write software and don’t need to jump on fashionable trends like life rafts to drowning sailors, because ultimately it means less competition.
21 February 2009, 5:52 pmCody Robbins:
You had me until you mentioned vi. If you walk into a new job and the entire team uses vi, you have walked into a job with a team that is serious about their tools and about what they’re doing. Your example should be switched around — the team that DOESN’T use vi (or emacs) is like the one that doesn’t pair. If you’re using vi you definitely are using one of the most efficient and powerful tools for the job. Do you actually know vi so you can be making a fair comparison? (Other than knowing to type ‘:q!’ when you accidentally get into it, of course.)
21 February 2009, 6:44 pmRod:
Cody:
I’m not a vi pro at all, I use it for basic text editing. I’ve never seen anyone step through code in vi in interactive debugging mode or use any kind of refactoring tools in vi to extract methods. If you can do all of that with vi, then the comparison is a poor one.
21 February 2009, 6:53 pmGlenn:
Great post, definitely sounds a lot like the experiences I’ve had in the small amounts of time I’ve spent pairing, especially this:
“The amount of time you spend trying to figure out “what’s going on here” or “why isn’t this working the way I expect” is severely reduced. I’m talking hours of debugging that literally turn into seconds.”
and this:
“the QUALITY of the code that IS produced is so, so, so much higher”
Nice work helping to dispel some myths of pairing as well.
21 February 2009, 7:20 pmWilliam Pietri:
Fantastic article. Your insights on Programmer Man are both novel and keen.
I also love pairing, and have discovered that a lot of the people who grumble about it are doing something I wouldn’t even call proper pair programming. It inspired me to write a list of 21 Ways to Hate Pair Programming.
Oh, and a note to Angelo: actually, there are plenty of people doing pairing these days. I know one startup, Sidereel.com, that has gone from zero users to millions in the last couple years, releasing on average weekly. They were mainly self-funded, and so they were incredibly focused on maximizing efficiency. But they’ve stuck with pairing because they believe it’s the most cost-effective way to do great work. If you’re in the SF Bay Area, let me know and I can arrange for a visit sometime.
21 February 2009, 7:59 pmThe Art of Pair Programming « The Art of Software Development:
[...] is a good post on PP by Rod Hilton. He starts out with When I first heard I’d be pairing at the new job, I was a bit [...]
22 February 2009, 1:00 amPhil Booth:
@Rod: But that is not what vi is for. The best way to develop on Unix is to accumulate a collection of specific tools and scripts that are excellent at what they do, rather than hunt down a single behemoth that does everything for you. vi is an excellent fit for the task of editing code. But no vi enthusiast would affirm that it is the only tool to use when coding. For me, shell scripts, lint, gdb, cscope, grep and so on are all vital complementary tools.
@Angelo: I can’t work out whether you’re a troll or a poor, deluded fool. “Pair programming died as a viable approach half a decade ago or more”. Are you serious? No, you must be a troll.
22 February 2009, 7:01 amKyle:
This was a very helpful article. I have tried to get a perspective on extreme programming or paired programming and hadn’t quite understood the benefits and such but now it all makes sense! Thanks for this!
22 February 2009, 9:56 amnicholas a. evans:
Rod: I also loved your article right up until the mention of vi. ;-)
My personal feeling (from experience) is that the utility of IDEs is heavily language dependent. I wouldn’t be able to cope with C# or Java without a decent refactoring IDE aiding me (and yes, JetBrains does seem to make the best IDEs). But I switched (back) to vim shortly after I started with Ruby, and have only very occasionally been tempted to look back. Likewise, vim does have some support for debugging, but I’ve never researched it, because (in my experience) TDD removes most need for debugging (I start up Netbeans about twice a year to debug something). For a while, I did program in C# with Visual Studio, Resharper, and ViEmu.
On the other hand, vi is not for everyone. So, to bring this comment back on topic for the post: I haven’t yet come up with a satisfactorily smooth way to do ping-pong pairing with different editors. Which sucks, because most developers in my office are familiar with (and prefer) vim or emacs or textmate, but not all three. For us, using an IDE is often a lowest common denominator deal… and one that is slower than gedit or textmate.
Of course, YMMV.
22 February 2009, 11:30 amShane Duan:
Hi, this is EXACTLY how I feel, thanks so much for writing it up.
As for leaving and working for a company that does not have pairing environment, fear not, as that is what I am right now. What I can say is that it is not a dead-end. After two years, I am still trying to bring this practice to my project. I am glad to say that progress is slow, but it is there. I even dare say that I will have something to show in half a year.
cheers, and keep up the good work.
22 February 2009, 1:43 pmRod:
Can you do refactoring in Java with vi? I’ve just never seen anyone do it. In my experience, most people who use vi use it only for scripting languages like Ruby, Python, bash, etc (myself included). The few that use vi for Java development simply don’t refactor at all, which is why I’d be disappointed if I walked into a company filled with only vi-using Java developers. Is it possible that they’re “serious about their tools”? Sure, I guess so. But in my experience, it’s more likely they just don’t refactor, so their codebase is almost certain to suck.
22 February 2009, 2:04 pmMatt O’ Rama » Loving Pair-Programming:
[...] “that’s rough,” “easily,” “sort of,” and “YES, but that’s a good thing. I Love Pair-Programming » Absolutely No Machete Juggling This is a really, really great look at pair-programming for real, not the theoretical discussions [...]
22 February 2009, 4:28 pmBrad:
Great post Rod, it certainly gave me a lot to think about.
Lets start with the easy stuff. There is a refactoring plugin for vim. I have it on my box, and have actually used it from time to time. I do have my vim setup much more like an IDE than most people I have run across, and tend to jump back and forth from my vim setup to netbeans, to grab on to some of the additional functionality. I have to agree with you that VIM/VI certainly is a better setup for scripting languages than java, but there is a lot of work done for java plugins for VIM where if you want all the functionality of and IDE you can get it.
Pair programming as you describe it at your company sounds much more in line with XP and not like anything I have ever come across at anyplace I have worked. If I were presented with the chance to do it like Rally, I think I would have a much better appreciation for it. I have always respected your opinion and if it is working that well for you, then I would say it bears another look.
I do however, think that good code can be accomplished without pair programming. This is not my attempt to hold onto Programmer Man, but rather to acknowledge that we stand on the shoulders of giants, who wrote elegant, clean, “good” code. They have proved that following design guidelines even if they do not include pair programming can produce great code. Thompson and Ritchie on early Unix design, Stevens networking code in “C”, are some examples of good code being developed (dare I say it?) without Agile, and without pair programming. (Waterfall worked? No way?)
I prefer agile (scrum actually), but there have been ways to assure quality (code reviews, design meetings, brown bags, and peer pressure) in the past. Pairing certainly can provide the same elements of quality assurance that have existed in solitary and team environments, and I think that all can work well, and all can be bastardized to generate crappy code.
Glad to hear that pairing is working so well for you. If you want I can send you a vim setup that works well for java, including refactoring, code completion, and class and method popups.
22 February 2009, 6:46 pmRafferty Uy:
Great post. Makes me think that non-XP projects who needs to rush things can add human resources to the team… but only to the extent of doing pair programming (no additional computers!)
Just a question though… how do you check your mail? Do each of you still have his/her own computer?
22 February 2009, 7:53 pmRod:
Rafferty:
Checking mail is the last thing I want to be doing if I’m coding. I check mail when I’m back at my desk or when the code is compiling, same time as when I check RSS feeds and the like.
22 February 2009, 8:05 pmPair-programming « Development at Guidewire:
[...] http://www.nomachetejuggling.com/2009/02/21/i-love-pair-programming/ [...]
23 February 2009, 7:08 pmDante:
Very interesting indeed. You got my attention :)
But this way of developing software is just not feasible in many situations, although it could work better.
Imagine you and your colleagues are consultants developing some super software in a client. How would you convince the client that he was paying rates for people to look at a monitor? In his view, of course…
But this is another war, of course :)
24 February 2009, 4:54 amDan Yankowsky:
Rod:
Thanks for the article. We try to pair program a lot at my company, and have achieved some success with it. However, there are some situations that still trip me up:
1. On my projects, we find that tasks are rarely of similar size, so it’s rare that we have opportunities to switch pairs during the day. We could force a pair change while people are in the middle of a task, but that seems like it would cause churn. Do you have any advice?
2. I find that some tasks, such as research (learning a library or API) and spiking (writing code to prove an approach), don’t work well in a pair. Sometimes, these occur “in flow” (while trying to bind HTTP POST params to model objects in X framework, we discover that we don’t know how to do that, so we need to do some research). How do you cope with that situation?
I agree with the other posters that pairing does not necessarily increase the quality of code you write. But it may increase the quality of the code the other person writes. Pairing may be slowing the other developer down, but it may speeding you up. And it may foster a common understanding among everybody. Raising the Bus Number of the team is usually a good thing.
Yes, it may cause you to be less effective. But it should also increase the effectiveness of the whole team. It might not pay off today or tomorrow, but it should pay off within a month. Pair programming is a global optimization, not a local optimization.
24 February 2009, 9:09 pmNotional Slurry » links for 2009-02-24:
[...] I Love Pair-Programming » Absolutely No Machete Juggling "I see pairing work so well every day that I consider my career prior to my current job to have consisted mostly of wasting time. When I think back to all the code I’ve written for a job, I’m annoyed at how much less efficient I was then since I wasn’t pairing, and how much better my code and my products would have been if I had paired on them full time." (tags: pair-programming efficiency risk-management software development cultural-norms TDD productivity) [...]
24 February 2009, 11:15 pmRod:
Dan,
So, first and foremost, I’m not an agile or XP coach by any stretch. Just a programmer that’s been doing pair programming and enjoying it a great deal. I’d be happy to offer advice, but if your company can afford it you may want to hire someone to come out and help your team.
1. Honestly, switch whenever. Sometimes we go the whole day without switching, sometimes two days in a row. We’ve developed something of an instinct about how much time can go by with someone not seeing work being done before we worry about “hit by a bus syndrome”. If it’s been two days since I’ve looked at the code a developer is working on, I know it’s been too long and I ask to switch stuff up. Do what feels natural, don’t force it unless it’s a problem.
One thing we tried was to set a timer for one hour. When the timer went off, the person who had been on a task the longest moved to another one, leaving another person to continue working on it. This worked somewhat well but it had disadvantages. You might give it a shot.
2. Research tasks don’t warrant pairs. Pairing is for writing production code. If you want someone to help, that’s fine, but pairing is really about improving the quality of the code that gets shipped.
25 February 2009, 12:18 amSoftware Quality Digest - 2009-02-25 | No bug left behind:
[...] I Love Pair-Programming – “I see pairing work so well every day that I consider my career prior to my current job to have consisted mostly of wasting time.” [...]
25 February 2009, 1:00 pmDoug:
I think this article makes the same case against pair programming I usually do: if pair programming makes a big difference to your code quality, you were doing it wrong before. Pair programming helps exactly the people who wrote bad code when working alone. You can hire two of those people to write somewhat better code in pairs, or you could spend a little more and hire one good person to do it the right way from the start.
26 February 2009, 12:13 pmSurya:
Nice post with real examples of benefits. But I do want to put a point here. Let us compare with an example in a more real life. You need to reach a destination and set out single. While travelling you see a lot of stuff, think that there could be another shorter way, you experiment, sometimes succeed, sometimes fail, sometimes you destract etc.. and at last you reach the destination and then if you look back your foot trails will be very clumsy and cluttered to be followed and seem like you were not effective in reaching the destination. Now if you were accompanied in the journey i definetly bet the deviations would be very less, the experiments would be very less (or will be good experiments) and you reach the destination with cleaner foot steps to follow and you feel the journey is effective.
Its like putting the destination on priority than your way of travelling.
So you are getting disciplined in your approach(for the sake of effectively reaching the destination).
So pairing should help you realize the importance of the destination and advantage of being disciplined, but then again you should learn that and practice it on your own instead of having a pair all time. You always cannot afford another person for every journey especially if it costs.
So I recommend Pairing to realize the benefits and start putting it in your blood.
May be people who like to experiment (out of box) do not agree at all with this.
26 February 2009, 12:53 pmKooWii:
Great post. You made me to think about some other stuffs in designing and programming fields. I would love to be a full time freelancer and I have to make a good plan for that.
28 February 2009, 3:55 amZach Dennis:
Great post. I’m an advocate of pair programming. I’ve worked with folks who refuse to do it and I’ve worked on agile teams that always do it. In my experience it takes people who want to write great code and who want to improve. It also takes a lot of humility to be willing to have someone call you out when you write something stupid.
I don’t think everything should be paired on, but it’s a great way to stay focused, talk through solutions, mentor/teach, and learn. It makes the entire team better then it was if everyone just worked by themselves.
The only thing I disagree on is the comment on vi. vi is a great tool. After learning to use vim, emacs, Eclipse, IntelliJ, and TextMate I have to say that the ones I dislike to open the most are the IDEs. My favorite choices are TextMate, vim, and emacs (in that order). I can’t remember the last time I needed to run Eclipse, but then again I stopped coding in Java a long time ago. ;)
6 March 2009, 6:53 pmParag Shah:
Great post. Thanks for sharing your experience.
I have one question. Does your team decide in the IPM, who will be pairing on which tasks. Also do you estimate tasks for the pair or on an individual basis, and then call decide your pair depending on who is available to pair on that day?
12 March 2009, 2:27 amRod:
Parag:
No, we don’t decide on pairs in the IPM. That’s a decision made daily/hourly.
We estimate the tasks as hours of time per pair. So if a task is “2 hours” the expectation is that 2 people will pair on it for two hours and complete it.
12 March 2009, 2:43 pmAdron:
I’m honestly envious. I killed off my “programmer man” years ago (not that I don’t like some honest to goodness breaks to thrash out with some good speed, death, or prog metal). But even though I stomped him well enough, I can’t seem to find a team willing and able to do real pairing like you describe. I’ve tried to get people into it, I’ve tried to bribe em’, but no go. It is so freaking hard sometimes to get people into something that is as scary sounding as pair programming. One day I do hope to either get a team put together that wants to do it or one of these years get on a team that does it.
26 March 2009, 9:10 pmPair programming: he saw the light! « a developer’s breadcrumb:
[...] source: I Love Pair-Programming [...]
9 April 2009, 9:43 pmbbot:
Neither Killswitch Engage or Slayer is death metal, derp derp.
16 April 2009, 12:13 pmPair Programming from the Trenches @ Agile Insider:
[...] http://www.nomachetejuggling.com/2009/02/21/i-love-pair-programming/ [...]
18 May 2009, 7:40 amChris Hedgate » Blog Archive » Pairing should be the norm:
[...] great story of someone who did try real pair programming I really recommend Rod Hilton’s post I Love Pair Programming. I’ll end with a quote from that post: I see pairing work so well every day that I consider [...]
11 June 2009, 3:21 pmGuilherme Garnier:
Well, a smelly programmer may be bad, but it´s still much better than smelly code!
25 June 2009, 4:01 amyo.momma:
Rod, you ignorant slut.
What are you trying to do restart the Great Editor Wars?
You obviously don’t know shit about vi, so why not stfu about it?
I enjoyed you little pair programming bit, but stick to what you know.
17 July 2009, 8:12 pmKyle:
Being in the zone is not unique to software development… ( http://en.wikipedia.org/wiki/Flow_(psychology) )
And it does not take away your ability to choose – you can choose to write untested, unchecked, sloppy code in the zone, and you can choose to write good code in the zone as well.
“The Zone” is extremely valuable – and has some awesome side-effects that increase productivity and satisfaction. Your argument here makes pair programming less attractive – I like the idea of having someone checking my code – and there is a time to step out of the zone – but “Killing Programmer Man” is a depressing thought…I pity the place you’ve put yourself in.
24 August 2009, 10:56 amJames Thigpen / remote Pairing with microsoft SharedView:
[...] I can’t say anything new about paired programming in general that someone else hasn’t already said, but I can say this: it is freaking awesome. Others seem to agree. [...]
29 August 2009, 11:33 amIs pair programming for the embedded folk? « Embedded Stories:
[...] the ideal world of web (for more on why pair programming is so good for the web software folk, read this article by Rod Hilton). I felt particularly devastated by “the no-asshole rule” cause, [...]
22 September 2009, 1:18 pmDan:
Hey, did you take the vi reference out of the post?!
I’m reading all these incensed comments about vi and I started getting pissed off about it too .. then I realized that I hadn’t even seen it mentioned anywhere in the post!
Nonetheless .. thanks for a real world report about pairing, it’s one of those crazy alternative lifestyle choices I’ve always wondered about but was never really brave enough to experiment with (sort of like swinging).
And don’t diss vim. Ever, dude. Or the Programmer Man will take your lunch money.
22 September 2009, 3:47 pmRod Hilton:
Dan:
I did change the reference. I wanted to reach for a simple analogy and used vi, which caused people to completely miss the point of the post and obsess over the vi thing instead. So I changed it.
25 September 2009, 4:13 pmRyan Sobol:
Rod,
I really liked your story about Programmer Man. I think it reveals a hidden truth about the mindset for many of our peers…
Ryan
6 October 2009, 12:28 amDouglas Squirrel:
Anyone who is interested in seeing what pairing is really like should check out http://pairwith.us. You can see a real pairing session, warts and all, with two really experienced developers. Those who are expressing reservations or opposition above: would really like to hear what you think after watching Antony and Andy for 25 mins (tweet me at @douglassquirrel)
15 October 2009, 9:48 amMajakovskij:
Great article… you made me at least curious enough to give it a genuine shot…
14 December 2009, 5:25 pmI Love Pair-Programming: http://bit.ly/8OseSB « f.majakovskij:
[...] I Love Pair-Programming: http://bit.ly/8OseSB When I first heard I’d be pairing at the new job, I was a bit apprehensive and skeptical. Do I really have to sit next to some fat developer all day, 40 hours a week? When am I going to check my RSS feeds? What if the other developer is gassy or hasn’t showered? How am I going to listen to my totally awesome Death Metal if I can’t wear headphones? Will the other developer be constantly judging and correcting my code? Will pairing prevent me from hitting “the zone” where I’m just belting code out so fast that my fingers can’t keep up with my brain? via nomachetejuggling.com [...]
14 December 2009, 5:32 pmJesus Salas:
If you love pair programming, then check http://www.wave-vs.net, it is an Add In for Visual Studio supporting real-time pair programming with built-in Collaborative text editing between other features like Server Federation, IM, Conference Rooms…
Jesus.
24 February 2010, 10:43 am