7 ms·

I Love Pair-Programming

37 points by jarnold 18y ago

mcav 18y ago
Interesting analysis. Have any of you pair programmed? Did you find it as useful as the author of this article did?
- arebop 18y ago
  I've done it, with two others on my team of six. The three of us thought it was good for quality and a preferable alternative to code review. I think each of us was a little shy at first, but once that faded we didn't feel held back by the pairing. We used it mostly for collaborative design. It was helpful for bringing a new team member up to speed on our code base. We also used it as an interview technique, and that seemed very successful although that one hiring decision is weak evidence.
- bjclark 18y ago
  I've done it at my current gig for about 5 months now. I'm not sure I'd work anywhere where I didn't pair, from now on. Infact, I've started pairing with my friends via iChat screen sharing when I'm working on side projects away from work.
- dfox 18y ago
  I did pair programming on some occassions and it is certainly useful. Also in my experience pair programming is good way to fix things that are so horribly broken so nobody wants to touch them with ten foot pole or quickly finish other tasks that are somehow obscure or boring.
- snprbob86 18y ago
  I also love pair programming. It usually begins with about 5 minutes of joking around and wasting time, but it takes only a minute or two to achieve flow. Individual programming can take 30 minutes or more to achieve flow. Once in flow, it is much harder to come out of it because you aren't tempted to browse to Hacker News. Also, no one will stick their head in your office and bother you because it looks like you are in a meeting. Partners are incredibly helpful spotting errors and act as an extra cache for all the little details you need to keep track of. Usually the person not typing has a lot more capacity for those details because they don't need to spend the energy operating their editor and manipulating code (no matter how good you get at it, it still requires some brain power: a limited resource). Also, when all is said and done, you now have TWO experts on a topic. Redundancy is a good thing.
- jrockway 18y ago
  I found it useful when everyone else on my team was incompetent. Sitting down with them at least prevented them from going off and doing negative work all day. The result was pretty consistent output from the team, which is what companies aim for. It was less productive than firing the incompetent people and letting me do their work instead, however. (Incidentally, this makes it sound like I didn't get along with my coworkers, which was not at all true. After we started pairing, we all got along too well, and started wasting the entire day socializing instead of programming. Oops.) Anyway, now that I don't have coworkers like this, I find it's easier to go off on my own. I also don't find it particularly useful to write a failing test and make it pass, I tend to alternate between big batches of code, a batch of passing tests, some todo tests, and then making that all work again. YMMV, but you have to keep in mind that things like XP, Scrum, Agile, TDD, etc. are designed to make big groups do things in a consistent amount of time, so that the code works reasonably well and it is delivered in a predictable amount of time. It is not necessarily a good way to do things if you are a good programmer. (Strict rules are for robots, not artists.)
- ahpeeyem 18y ago
  I've paired for small amounts of time and my experiences were similar to those in the blog post, 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." I'd attribute this very much to the extra "cache" of the second brain that isn't having to manage typing and editing as snprbob86 above mentions. Have you ever watched someone searching for some piece of info on Google or Wikipedia, or looking for a phone number on a website? The person not wielding the mouse/keyboard can often parse and comprehend the info on the screen more quickly. I also agree strongly with this: "the QUALITY of the code that IS produced is so, so, so much higher" I think the post helps to dispel some myths of pairing as well, and it works best if pairing to reach the goal of completing specific tasks.
- axod 18y ago
  Tried it for a while, it was sort of fun, but way less productivity.
nirmal 18y ago
I pair programmed with a friend all the way through my graphics class. It worked out really well because my linear algebra was really strong and his C powers were unstoppable. We easily finished in half the time of other groups. I'll provide more detail when I'm not on my ipod.
jacquesm 18y ago
I've learned programming this way with a good friend, even 28 years later we're still in touch. It's one of those things where you can see how much it matters that you can rely on each other to catch stuff before it becomes a dead end, when you're programming on your own it's very easy to waste some time every now and then, and to have to backtrack later. If you can't actually program pair wise I'd certainly recommend that you go over your design with somebody competent before you commit to code, you'll be surprised how much time that will save in the long run.
sqnz 18y ago
I never really pair programmed but I'm going to give a try :P
pavelludiq 18y ago
The vi analogy was really stupid. If you know Vim(not Vi) well enough, you probably won't need an IDE to be effective(unless you are using an IDE dependant language, which is bad). And yes, your IDE is bloated.
- snprbob86 18y ago
  I don't want to start an editor war, but... If you know your IDE well enough, you probably won't need a powerful text editor to be effective (unless you are using a language that is not toolable, which is bad). And yes, your powerful text editor is feature poor. You like what you like. He likes what he likes. You are in a mutually recursive Bulb paradox. This, of course, assumes your IDE doesn't suck. Most do. If your IDE isn't powered by JetBrains, chances are it actually does suck.
  - sharkbrainguy 18y ago
    If my text-editor has tight unix integration, smart-completion, a repl, and good build integration... what am I missing out on?
    - snprbob86 18y ago
      http://www.jetbrains.com/idea/features/ http://www.jetbrains.com/idea/features/ http://www.jetbrains.com/resharper/features/ http://www.jetbrains.com/resharper/features/ http://www.jetbrains.com/ruby/features/index.html http://www.jetbrains.com/ruby/features/index.html
    - jrockway 18y ago
      You are "missing out" on "code generation". Apparently some languages have so much verbose boilerplate that the only way to be productive in such a language is to pick the boilerplate out of a menu when you need it. Or so the IDE folks say. (Other problems include insane organizational schemes that require the computer to move code between specifically-named files in order for your app to run.) Anyway, the IDE thing is a classic example of a "local maximum". The language made a bunch of bad decisions, and the only to get productive again was to invent an incredibly complex tool to abstract away some insanity. Sure, it's kind of good. But if you threw both away and started over, you'd get a better maximum with less complexity. The word "blub" comes to mind. So in the end, you are exactly right -- if you are using a reasonable programming language. If you are using Java, you need all the help you can get. (And yes, I mean that in two ways.)
richcollins 18y ago
Does it make you more productive or do you just find it more fun? I suspect companies that institute pair programming because employees are less likely to goof off when they have another set of eyes on them. I have a hard time believing that it actually makes motivated people more productive.
- arebop 18y ago
  When our manager discovered us pairing, we had to defend the practice against the objection that it would surely halve our productivity. I think those of us who initiated pairing on our team were the most motivated programmers, and those who wound up pairing regularly were likewise the most enthusiastic about the project and about professional development too. I'll admit that it's hard to separate causes and effects here, but I do believe that on our project, pairing was more of an effect of our desire to improve our productivity.
  - richcollins 18y ago
    Yes but the question is did it increase your productivity? If so, then why do you think it did?
    - ntoshev 18y ago
      Nobody knows a good way to measure this and you know it. Just because we can't measure it doesn't mean it is not real (I'm not claiming either way).
      - arebop 18y ago
        Right. I was tempted to say that our pace was somewhat reduced (not to 50%), and our code was greatly improved, because that was our impression. We did not adjust old estimates to account in any way for pairing, and we saw a trend toward improvement in |actual - estimated| costs. Then again, every feature/bug and programmer is different. We didn't have many old estimates for unfinished work. We didn't consciously account for pairing in new estimates, but we didn't have any sort of experimental rigor. The non-pairing programmers definitely wrote worse code, but they were the weaker programmers in the first place. Maybe our improved estimation accuracy was because our product was maturing. There are some reviewed papers covering experiments on pairing. Laurie Williams [http://collaboration.csc.ncsu.edu/laurie/ http://collaboration.csc.ncsu.edu/laurie/] is an author of many of them. Here's one not by her: http://portal.acm.org/citation.cfm?doid=1145293 http://portal.acm.org/citation.cfm?doid=1145293.
sharkbrainguy 18y ago
I really think that tangentially attacking the vi(m) strawman at the end really hurt your credibility and focus.
- jrockway 18y ago
  Maybe. It is just an under-education type of thing. If all you've ever seen is Java and the IDE world, it's hard to imagine anything else. "blub" is the usual word. (I could rant on and on about this, but I won't. Basically, if you haven't programmed seriously in a dynamic language, a functional language, Smalltalk with Squeak, Lisp with Emacs/SLIME, and Java or C# with an IDE, any commentary you have on programming languages and tools is worthless. You haven't experienced enough yet.)
dustineichler 18y ago
Personally, I love pair programming because I feel like i'm learning more faster. Some of the more experienced engineers I've worked with passes some insight and knowledge, which has been a huge benefit to me.
ewiethoff 18y ago
Aside from physical, eyesight, accessibility, noise, etc. problems, I pretty much can't stand pair programmming. It's good for social bonding and instructing noobs, but my work is hardly up to snuff. I can't "navigate" someone moderately competent because it takes me forever to stuff a pile of someone else's code into my head. I have to keep scrolling here and looking there, which I can't do without a separate keyboard and monitor. I want to navigate from an extra computer so I can flip through the code, look up docs, and so on. But, by gum, that's not "pair programming." Hence, the only thing I'm good for as a navigator is catching syntax and spelling errors, which is something an appropriate editor or IDE can do. And I can't accomplish much while I'm "driving" because either I have to spend all my time explaining everything to the noob, or I'm not allowed time to think. If I stare into space or scroll around a bit, the navigator thinks I'm stuck and feels compelled to chatter away with advice or questions or something. And unlike the author's "Progammer Man," the code I produce solo in the Zone is better than the code I produce in a pair out of the Zone. The best "navigator" is someone who watches awhile then gives up and "pairs" with someone else! No, I take that back. Apoorva is a decent navigator. He mostly just sits there and makes a few pleasant quips, occasionally raising an insightful question. I guess I'm very, very finicky about navigators.
- alabut 18y ago
  Seems like your main criticism revolves around being chained to a newbie as half of the pair - I'm not sure pair programming is designed to work well in that setup. It's pair programming, not pair mentoring, and if there's a huge disparity in skill level, then it'll feel like a drag. Yes there's an amount of mentoring in good pairs because everyone's at least slightly better in at least one different area than their partner, but similar enough in skill sets that you can build upon the differences when needed, rather than constantly bringing the partner up to par. The places I've seen it work seamlessly has been where it averages out the work to a consistent level, whether all intermediate coders that no longer make rookie mistakes or all advanced ones that no longer slow down for newbie speed bumps. I've even seen pairs attack projects in programming languages they've never worked with before. I was brought in to Pivotal for an afternoon or two to give Flex/actionscripting advice to the programmers working on a friend's prototype site and they didn't need my help at all, I was happy to see that they knocked it out just fine. On a side note, I just tried out pair designing this week (instead of programming) and it was a really interesting experience. You could see that we each had different focus (me = interaction designer, partner = visual designer) and that helped compliment our work rather than act as a source of friction. And not to get into a toolkit debate but we also shared similar philosophies about hating Photoshop and long design cycles, loving Fireworks and quick clickable prototypes, etc.
jon_dahl 18y ago
My theory on pair programming: a good pair is _more_ productive than two individuals on hard tasks, and _less_ productive on easy tasks. Basically, when you pair, you get one better programmer instead of two lesser programmers. Think about the old 10x/100x developer question (http://c2.com/cgi/wiki?DevelopersWithHighProductivityTenxHundredxThousandx http://c2.com/cgi/wiki?DevelopersWithHighProductivityTenxHun...). In reality, it isn't that simple. A 10x programmer won't write simple code (Hello World) 10x faster. On the other side, a mediocre programmer may be unable to do some of the things that a better programmer can do, no matter how much time you give them. So it's silly to compare productivity along a linear scale like this. Pairing is similar. It's meaningless to say that a pair 2x as productive as 2 developers, or 3x, or 1.5x, because it depends on the task. They might work far faster at a complex problem, but no faster one programmer at an easy one. That's why my preference is to pair on anything that is moderately challenging (or harder), and to work separately on the easy stuff.
bitwize 18y ago
Having another programmer around to talk me through a gnarly bit of code is often enormously helpful. This tends to happen organically. When it comes down to the heads-down time necessary to plow through some changes, a second pair of eyes hovering over my shoulder becomes a distraction and a productivity killer. There exist shops where the mantra is "Pair Programming = Good" and you are encouraged (and socially pressured) to do most or all of your coding at a single screen with someone else. I tend to do not so well in these.

37 points by jarnold 18y ago

mcav 18y ago

Interesting analysis. Have any of you pair programmed? Did you find it as useful as the author of this article did?

arebop 18y ago
I've done it, with two others on my team of six. The three of us thought it was good for quality and a preferable alternative to code review. I think each of us was a little shy at first, but once that faded we didn't feel held back by the pairing. We used it mostly for collaborative design. It was helpful for bringing a new team member up to speed on our code base. We also used it as an interview technique, and that seemed very successful although that one hiring decision is weak evidence.
bjclark 18y ago
I've done it at my current gig for about 5 months now. I'm not sure I'd work anywhere where I didn't pair, from now on. Infact, I've started pairing with my friends via iChat screen sharing when I'm working on side projects away from work.
dfox 18y ago
I did pair programming on some occassions and it is certainly useful. Also in my experience pair programming is good way to fix things that are so horribly broken so nobody wants to touch them with ten foot pole or quickly finish other tasks that are somehow obscure or boring.
snprbob86 18y ago
I also love pair programming. It usually begins with about 5 minutes of joking around and wasting time, but it takes only a minute or two to achieve flow. Individual programming can take 30 minutes or more to achieve flow. Once in flow, it is much harder to come out of it because you aren't tempted to browse to Hacker News. Also, no one will stick their head in your office and bother you because it looks like you are in a meeting. Partners are incredibly helpful spotting errors and act as an extra cache for all the little details you need to keep track of. Usually the person not typing has a lot more capacity for those details because they don't need to spend the energy operating their editor and manipulating code (no matter how good you get at it, it still requires some brain power: a limited resource). Also, when all is said and done, you now have TWO experts on a topic. Redundancy is a good thing.
jrockway 18y ago
I found it useful when everyone else on my team was incompetent. Sitting down with them at least prevented them from going off and doing negative work all day. The result was pretty consistent output from the team, which is what companies aim for. It was less productive than firing the incompetent people and letting me do their work instead, however. (Incidentally, this makes it sound like I didn't get along with my coworkers, which was not at all true. After we started pairing, we all got along too well, and started wasting the entire day socializing instead of programming. Oops.) Anyway, now that I don't have coworkers like this, I find it's easier to go off on my own. I also don't find it particularly useful to write a failing test and make it pass, I tend to alternate between big batches of code, a batch of passing tests, some todo tests, and then making that all work again. YMMV, but you have to keep in mind that things like XP, Scrum, Agile, TDD, etc. are designed to make big groups do things in a consistent amount of time, so that the code works reasonably well and it is delivered in a predictable amount of time. It is not necessarily a good way to do things if you are a good programmer. (Strict rules are for robots, not artists.)
ahpeeyem 18y ago
I've paired for small amounts of time and my experiences were similar to those in the blog post, 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." I'd attribute this very much to the extra "cache" of the second brain that isn't having to manage typing and editing as snprbob86 above mentions. Have you ever watched someone searching for some piece of info on Google or Wikipedia, or looking for a phone number on a website? The person not wielding the mouse/keyboard can often parse and comprehend the info on the screen more quickly. I also agree strongly with this: "the QUALITY of the code that IS produced is so, so, so much higher" I think the post helps to dispel some myths of pairing as well, and it works best if pairing to reach the goal of completing specific tasks.
axod 18y ago
Tried it for a while, it was sort of fun, but way less productivity.

nirmal 18y ago

I pair programmed with a friend all the way through my graphics class. It worked out really well because my linear algebra was really strong and his C powers were unstoppable. We easily finished in half the time of other groups. I'll provide more detail when I'm not on my ipod.

jacquesm 18y ago

I've learned programming this way with a good friend, even 28 years later we're still in touch. It's one of those things where you can see how much it matters that you can rely on each other to catch stuff before it becomes a dead end, when you're programming on your own it's very easy to waste some time every now and then, and to have to backtrack later. If you can't actually program pair wise I'd certainly recommend that you go over your design with somebody competent before you commit to code, you'll be surprised how much time that will save in the long run.

sqnz 18y ago

I never really pair programmed but I'm going to give a try :P

pavelludiq 18y ago

The vi analogy was really stupid. If you know Vim(not Vi) well enough, you probably won't need an IDE to be effective(unless you are using an IDE dependant language, which is bad). And yes, your IDE is bloated.

snprbob86 18y ago
I don't want to start an editor war, but... If you know your IDE well enough, you probably won't need a powerful text editor to be effective (unless you are using a language that is not toolable, which is bad). And yes, your powerful text editor is feature poor. You like what you like. He likes what he likes. You are in a mutually recursive Bulb paradox. This, of course, assumes your IDE doesn't suck. Most do. If your IDE isn't powered by JetBrains, chances are it actually does suck.
- sharkbrainguy 18y ago
  If my text-editor has tight unix integration, smart-completion, a repl, and good build integration... what am I missing out on?
  - snprbob86 18y ago
    http://www.jetbrains.com/idea/features/ http://www.jetbrains.com/idea/features/ http://www.jetbrains.com/resharper/features/ http://www.jetbrains.com/resharper/features/ http://www.jetbrains.com/ruby/features/index.html http://www.jetbrains.com/ruby/features/index.html
  - jrockway 18y ago
    You are "missing out" on "code generation". Apparently some languages have so much verbose boilerplate that the only way to be productive in such a language is to pick the boilerplate out of a menu when you need it. Or so the IDE folks say. (Other problems include insane organizational schemes that require the computer to move code between specifically-named files in order for your app to run.) Anyway, the IDE thing is a classic example of a "local maximum". The language made a bunch of bad decisions, and the only to get productive again was to invent an incredibly complex tool to abstract away some insanity. Sure, it's kind of good. But if you threw both away and started over, you'd get a better maximum with less complexity. The word "blub" comes to mind. So in the end, you are exactly right -- if you are using a reasonable programming language. If you are using Java, you need all the help you can get. (And yes, I mean that in two ways.)

richcollins 18y ago

Does it make you more productive or do you just find it more fun? I suspect companies that institute pair programming because employees are less likely to goof off when they have another set of eyes on them. I have a hard time believing that it actually makes motivated people more productive.

arebop 18y ago
When our manager discovered us pairing, we had to defend the practice against the objection that it would surely halve our productivity. I think those of us who initiated pairing on our team were the most motivated programmers, and those who wound up pairing regularly were likewise the most enthusiastic about the project and about professional development too. I'll admit that it's hard to separate causes and effects here, but I do believe that on our project, pairing was more of an effect of our desire to improve our productivity.
- richcollins 18y ago
  Yes but the question is did it increase your productivity? If so, then why do you think it did?
  - ntoshev 18y ago
    Nobody knows a good way to measure this and you know it. Just because we can't measure it doesn't mean it is not real (I'm not claiming either way).
    - arebop 18y ago
      Right. I was tempted to say that our pace was somewhat reduced (not to 50%), and our code was greatly improved, because that was our impression. We did not adjust old estimates to account in any way for pairing, and we saw a trend toward improvement in |actual - estimated| costs. Then again, every feature/bug and programmer is different. We didn't have many old estimates for unfinished work. We didn't consciously account for pairing in new estimates, but we didn't have any sort of experimental rigor. The non-pairing programmers definitely wrote worse code, but they were the weaker programmers in the first place. Maybe our improved estimation accuracy was because our product was maturing. There are some reviewed papers covering experiments on pairing. Laurie Williams [http://collaboration.csc.ncsu.edu/laurie/ http://collaboration.csc.ncsu.edu/laurie/] is an author of many of them. Here's one not by her: http://portal.acm.org/citation.cfm?doid=1145293 http://portal.acm.org/citation.cfm?doid=1145293.

sharkbrainguy 18y ago

I really think that tangentially attacking the vi(m) strawman at the end really hurt your credibility and focus.

jrockway 18y ago
Maybe. It is just an under-education type of thing. If all you've ever seen is Java and the IDE world, it's hard to imagine anything else. "blub" is the usual word. (I could rant on and on about this, but I won't. Basically, if you haven't programmed seriously in a dynamic language, a functional language, Smalltalk with Squeak, Lisp with Emacs/SLIME, and Java or C# with an IDE, any commentary you have on programming languages and tools is worthless. You haven't experienced enough yet.)

dustineichler 18y ago

Personally, I love pair programming because I feel like i'm learning more faster. Some of the more experienced engineers I've worked with passes some insight and knowledge, which has been a huge benefit to me.

ewiethoff 18y ago

Aside from physical, eyesight, accessibility, noise, etc. problems, I pretty much can't stand pair programmming. It's good for social bonding and instructing noobs, but my work is hardly up to snuff. I can't "navigate" someone moderately competent because it takes me forever to stuff a pile of someone else's code into my head. I have to keep scrolling here and looking there, which I can't do without a separate keyboard and monitor. I want to navigate from an extra computer so I can flip through the code, look up docs, and so on. But, by gum, that's not "pair programming." Hence, the only thing I'm good for as a navigator is catching syntax and spelling errors, which is something an appropriate editor or IDE can do. And I can't accomplish much while I'm "driving" because either I have to spend all my time explaining everything to the noob, or I'm not allowed time to think. If I stare into space or scroll around a bit, the navigator thinks I'm stuck and feels compelled to chatter away with advice or questions or something. And unlike the author's "Progammer Man," the code I produce solo in the Zone is better than the code I produce in a pair out of the Zone. The best "navigator" is someone who watches awhile then gives up and "pairs" with someone else! No, I take that back. Apoorva is a decent navigator. He mostly just sits there and makes a few pleasant quips, occasionally raising an insightful question. I guess I'm very, very finicky about navigators.

alabut 18y ago
Seems like your main criticism revolves around being chained to a newbie as half of the pair - I'm not sure pair programming is designed to work well in that setup. It's pair programming, not pair mentoring, and if there's a huge disparity in skill level, then it'll feel like a drag. Yes there's an amount of mentoring in good pairs because everyone's at least slightly better in at least one different area than their partner, but similar enough in skill sets that you can build upon the differences when needed, rather than constantly bringing the partner up to par. The places I've seen it work seamlessly has been where it averages out the work to a consistent level, whether all intermediate coders that no longer make rookie mistakes or all advanced ones that no longer slow down for newbie speed bumps. I've even seen pairs attack projects in programming languages they've never worked with before. I was brought in to Pivotal for an afternoon or two to give Flex/actionscripting advice to the programmers working on a friend's prototype site and they didn't need my help at all, I was happy to see that they knocked it out just fine. On a side note, I just tried out pair designing this week (instead of programming) and it was a really interesting experience. You could see that we each had different focus (me = interaction designer, partner = visual designer) and that helped compliment our work rather than act as a source of friction. And not to get into a toolkit debate but we also shared similar philosophies about hating Photoshop and long design cycles, loving Fireworks and quick clickable prototypes, etc.

jon_dahl 18y ago

My theory on pair programming: a good pair is _more_ productive than two individuals on hard tasks, and _less_ productive on easy tasks. Basically, when you pair, you get one better programmer instead of two lesser programmers. Think about the old 10x/100x developer question (http://c2.com/cgi/wiki?DevelopersWithHighProductivityTenxHundredxThousandx http://c2.com/cgi/wiki?DevelopersWithHighProductivityTenxHun...). In reality, it isn't that simple. A 10x programmer won't write simple code (Hello World) 10x faster. On the other side, a mediocre programmer may be unable to do some of the things that a better programmer can do, no matter how much time you give them. So it's silly to compare productivity along a linear scale like this. Pairing is similar. It's meaningless to say that a pair 2x as productive as 2 developers, or 3x, or 1.5x, because it depends on the task. They might work far faster at a complex problem, but no faster one programmer at an easy one. That's why my preference is to pair on anything that is moderately challenging (or harder), and to work separately on the easy stuff.

bitwize 18y ago

Having another programmer around to talk me through a gnarly bit of code is often enormously helpful. This tends to happen organically. When it comes down to the heads-down time necessary to plow through some changes, a second pair of eyes hovering over my shoulder becomes a distraction and a productivity killer. There exist shops where the mantra is "Pair Programming = Good" and you are encouraged (and socially pressured) to do most or all of your coding at a single screen with someone else. I tend to do not so well in these.