Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

TorgoX (1933)

TorgoX
  sburkeNO@SPAMcpan.org
http://search.cpan.org/~sburke/

"Il est beau comme la retractilité des serres des oiseaux rapaces [...] et surtout, comme la rencontre fortuite sur une table de dissection d'une machine à coudre et d'un parapluie !" -- Lautréamont

Journal of TorgoX (1933)

Tuesday April 08, 2003
12:45 AM

Pair programming

[ #11510 ]
Dear Log,

In a book on XP, I saw a discussion of pair programming -- i.e., two people at one keyboard. The mere idea is giving me a claustrophobic fit. I'd sooner abandon programming altogether than have to code with another hyoomon in the room, much less one watching me code, or expecting me to watch him code.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I mean you're a super CPAN magnet, with vast swathes of lovely code behind you. Stuff in Perl core, too. But for 90% of the rest of us that aren't so hot, it's a good idea. It tends to catch the really silly mistakes before the file even hits the disk. And the interface design ones too.

    -Dom

    • It's not really a matter of skill -- it's just the experience of sitting next to somebody and sharing a machine with them for hours at a time. It just crowds my space. I'm probably just being neurotic this way -- but I think a lot of programmers feel the same way.

      "I VANT TO BE ALOOOOONE."

      We are all Garbo now.

      • Yeah, a lot of programmers are scared to death of things they've never done before.

        • I'm not scared, I've done it and I hate it. I think in order for it to work one needs to be a much better multitasker than I am (eg I can't be on the phone and have someone nearby talking to me at the same time, as most humans can -- I'll lose track of both conversations). I can't be 100% concentrated on code and interact with someone at the same time. When I tried I made far more (stupid) mistakes than I usually do, and worse: when my pair pointed them out I failed to see them because I was focussed on

          --

          -- Robin Berjon [berjon.com]

          • That's fine; it doesn't work for some people. The University of Utah study showed only a 90% or higher uptake rate for pair programming. Of course, these were students and they did it consistently, for an assignment, for a couple of weeks.

            Take my comments with a grain of salt, though. The first programming class I ever took, back in the 80s, had too few computers and I had to pair. It didn't go well, partly because we were so very young and partly because we had no idea what we were doing.

        • I agree with TorgoX, and it is entirely, completely, absolutely unrelated to whether or not I have done it before.

          The two coders I work with the most are halfway across the country, and all the way across the country. I've not seen either one in close to two years. We work on IRC together, pointing out line numbers, pasting in code, emailing diffs. We keep the code in CVS and I we look over each other's changes. I much prefer that. Perhaps some things slip through the cracks that wouldn't in pair prog
      • Heh, another reason it's a good thing. It encourages you to get up and go away from the computer more often. :-)

        -Dom

  • 2 Weeks ago, in the middle of a development cycle, I found myself waiting for something to do. My less experienced cow-orker took the larger piece of the puzzle and I finished mine after some hours. Since I couldn't continue with anything else, I started reviewing his code and we actually started working together on his part of the code. We argued a lot more than during our planning process but we always worked it out. I didn't really look into XP all that much but when it comes to working in a team, I lear
  • The core idea behind XP is anything that is worth doing is worth doing continuously. And if you're going to do something continuously, then it must be cheap. Testing is good, so make testing a cheap part of the activity -- write tests first and run the complete test suite at every checkin.

    In this context, pair programming is nothing more than cheap, constant review. I've seen a development shop where a team has been working together on a project for months adapt some of the XP methodologies to suit loc

    • isnt this what company irc/im and cvs commit mail is for? :) i actually prefer the irc route because then, no matter what their location, i can have the whole team in a "room". so when i ask questions like "JESUS CHRIST WHO THOUGHT THIS WAS A GOOD IDEA?" the team can benefit from the discussion and not just the pair. and yes, i agree with torgox. the few times people have tried to pair with me (sitting next to me, watching, and commenting) were disasterous. i hate being watchced and i hate discussing and d
    • Pair programming in XP is more than just code review. It's also a design session. Where the planning game does a little design in the large, it's the test-driven cycle that does planning in the small. As you're baby-stepping your way toward the goal with testing, you're also designing with your tests and refactorings.

      Then there's the "Hey, we just added code without a failing test! Oops!" peer pressure. It's hard to overestimate that.

  • Like so many other things, this just isn't for everyone. If it's the claustrophobia (I personally hate having people hover over me) then there's stuff like Hydra for OS X, which is really cool.
  • Pair Programming isn't for everyone. Some personality types don't take to it easily, and some personality combinations make for bad experiences. There are a couple of specific people who I can not/will not pair with unless I have a titanium crowbar within reach. And there are personality types I find difficult to work with (e.g., people who do all of their thinking out loud, without the benefit of an internal censor to screen out nonesense). But as I've paired with more people, it becomes easier. Even if I
  • "[crash programs] fail because they are based on the theory that, with nine women pregnant, you can get a baby a month." -- Wernher von Braun

    Having 2 or more people working in close proximity on the same problem usually contributes to overengineering of a problem which, in turn, slows down the delivery time and doesn't really contribute to the overall quality. This touchy feely fad will die out once someone figures out that it's not a substitute for a sharp code wrangler who knows how to herd cats and kn

  • Our shop started pairing a couple of months ago. A lot of the enjoyment comes from who's your partner. Last month I had a 15-year veteran of this code, very intense, etc.. and we accomplished a lot. Today I'm with a 4-year novice who's a lot more laid back and I'm not accomplishing as much but I feel better about life.

    Once in a while though I do get a problem where I scurry back to my office and brain on it a bit by myself. Then go back to my partner and we start up again. Sometimes that "go away and