Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Programming Technology

Experiences with Pair Programming? 125

Posted by Cliff from the gemini-coding dept.
gmletzkojr queries: "I recently was able to engage in some Pair Programming for a couple of days. However, my experience was less than rewarding. I have read books regarding the subject, and all of the case studies show praise for the effort. I found my pair programmer a bit difficult to work with. Has anyone been in this situation, and what things can be done to work around the personality conflicts?"
This discussion has been archived. No new comments can be posted.

Experiences with Pair Programming? More

Experiences with Pair Programming?

Comments Filter:
  • Acknowledge the personality conflict with your partner to your partner and then don't let it get in the way of your work.

  • Personality Problems... (Score:2, Interesting)

    by lesv ( 258710 )
    I've always tried to deal with personality issues when I hire.

    I've also had significant success when using pair programming. It's a great way to make sure process is followed, it improves quality, and it spreads knowledge around.

  • I too find my coworkers difficult to deal with (Score:5, Insightful)

    by Cecil ( 37810 ) on Tuesday September 28, 2004 @06:25PM (#10378505) Homepage
    What is to be done about this? Ask for a different partner, maybe? Pair programming is useless if you can't work with your partner. This should be obvious. Not everyone is compatible, not with each other, and some people probably aren't even compatible with pair programming at all. That's fine, everyone's different.

    Nothing will ever be a magic bullet. Pair programming, agile methods, and all that other crazy marketing-speak, it's just a procedure. If it works for you, use it, if not, try a different approach.
    • I have found that along with Pair Programming, all code needs to be "group owned". Anyone can modify any code they think they need to. Having Pair Programming in this situation helps because you have a second set of eyes to keep your code as clean as possible.

      Since all code is group owned you don't always have to have the same partner all the time, you just end up with whoever is available when you are ready to code. I can't imagine how Pair Programming is much of a benefit if the pair is always the same
    • some people probably aren't even compatible with pair programming at all

      I think I fall into this category. I would probably fall asleep when my partner was programming, and when it was my turn at the keyboard, I would erase everything he had done and do it the way I wanted it done.

    • What is to be done about this? Ask for a different partner, maybe?

      It's good to change pairing parters every 2-4 hours. That's short enough that you should be able to deal with anybody on your team, and long enough to get something done and checked in.

      Also, learning to pair is exhausting. When people are first getting used to it, I encourage them to work into it slowly. E.g., 1 short session the first day, 2 the second, and so on.

  • perhaps this is relevant? (Score:3, Funny)

    by Shaleh ( 1050 ) <shaleh AT speakeasy DOT net> on Tuesday September 28, 2004 @06:25PM (#10378512)
    When I first looked at the comments this was my fortune:

    It's hard to be humble when you're perfect.

    Think that may relate to this issue, as others have commented on personality conflicts.
    • I was thinking the other day about possible personality faults that I have. I was simply going through all the traits I could think of and when I got to 'arogance' my blood ran cold. I'm concerned that my arogance may be holding me back when receiving instructions and training. One personal flag is my wife loves to ask questions and I love to answer them. But when was the last time I actually asked her a question?
      • Did you come yet?

        Well, maybe she's a screamer.
        Not my business, I guess.

      • Don't worry "corganbilly", all your fans have always known that you're an arrogant prick.. ;)

        Not that I'm an expert but having dealt with many personalities over the years, I think the fact that you are introspective enough to even think about this and then post it where everyone can see means that you don't have a real problem. If you're really concerned, look up intJ [typelogic.com] personality types and read a little Venus/Mars and you'll be fine.
  • something the personal hygiene products industry would come up with.

    Guy at KB: "would you quit breathing on me!"
    Guy not at KB: "Hey! your no rose either!"

    Or any variations you can come up with.

  • My Experience (Score:5, Insightful)

    by Apreche ( 239272 ) on Tuesday September 28, 2004 @06:26PM (#10378519) Homepage Journal
    Scenarios and results from my experience.

    1) If your partner is more experienced it is usually annoyance for them and great fun learning for you.

    2) Vice versa of 1.

    3) Neither partner is experience or knowledgable enough to do the work on their own then productivity increases only slightly because you have two people trying to figure out new things at once. Also makes the job programming less painful for both since you share suffering.

    4) Both partners are knowledgeable and experience enough for the work. It depends on the personalities of the people

    4a) personalities are conducive to teamwork, super productivity! Project gets done fast, bugs are caught during implementation, everyone is happy.

    4b) personalities not conducive to teamwork, super bad! Both programmers are knowledgeable and could therefore be doing more work if they each coded separately.

    As long as neither partner lacks basic social skills and is not a complete loner then teamwork is usually good experience because you can enjoy the company and conversation of another programmer while you work.

    • Re:My Experience (Score:2, Insightful)

      by lphuberdeau ( 774176 )

      Totally agree, it all depends on how good the communication is between the two persons. If it's not good, try with omeone else. I have had some great experiences with pair programming with experienced people. It's just good when both are experienced but have different kind of knowledge. This way, both will focus on different aspects and make the entire thing better.

      On the other hand, if both have totally different approaches to the problem, it can cause a nuclear war, especially if both programmers have

      • On the other hand, if both have totally different approaches to the problem, it can cause a nuclear war, especially if both programmers have a large ego.

        Well, this is true whether or not you're pair programming. It's just that in pairing, you get to find out about the conflict before the code gets written. That's generally the best time to resolve things. And if things are hard to resolve, it's often a sign that
        • it's good for everybody on the team to figure out that they're not getting paid to stroke their own egos.

          They're not? Woah.
      • It's just good when both are experienced but have different kind of knowledge. This way, both will focus on different aspects and make the entire thing better. [Emphasis added]

        Different skill sets. That's the crux. When it works, it dominates everything else.

        On the other hand, if both have totally different approaches to the problem, it can cause a nuclear war, especially if both programmers have a large ego.

        If both egos are after the same turf, you will have problems. With a bit of skill in working in

    • Who's in charge? (Score:5, Insightful)

      by GCP ( 122438 ) on Tuesday September 28, 2004 @07:56PM (#10379217)
      I think the best approach is to pair an experienced person with a less experienced person, and make it clear to both that the more experienced person had two votes and the less experienced had one in any disagreements.

      I wouldn't mind being partnered with someone with a lot more experience. I would consider it an opportunity to turbocharge my own learning, and though I would ask lots of questions and might even gently challenge some decisions, I would make it clear that they were HIS decisions to make, even if the boss didn't manage it that way.

      I also wouldn't mind being the senior partner as long as the junior understood that, though I would appreciate his input, the decisions were mine.

      Two inexperienced people shouldn't be paired. All of their arguments will end up being over who is able to make who back down. Complete waste.

      I would also be willing to be paired with another experienced person, with my (senior) level of experience, if it were the right person. It would be harder to make this work with two arbitrary people than the case with unequal pairings and one guy in charge. In the case of two experienced people, if you had to specify which one was in charge, it probably wouldn't be a good pairing.

      I had a discussion with another senior architect (like me) the other day, and both of us agreed that it would be fun for us to try pair programming together some time because both of us have concluded that the other has expertise that we wish we had. ;-) He's the only one in his group I'd be willing to work that way with, though.

      • Re:Who's in charge? (Score:5, Interesting)

        by dubl-u ( 51156 ) * <2523987012@pota . t o> on Tuesday September 28, 2004 @08:49PM (#10379555)
        I had a discussion with another senior architect (like me) the other day, and both of us agreed that it would be fun for us to try pair programming together some time because both of us have concluded that the other has expertise that we wish we had. ;-) He's the only one in his group I'd be willing to work that way with, though.

        That's one good reason for pair programming, but it's far from the only one. Here are reasons I like promiscuous pair programming:
        • instant code review
        • instant design review
        • keeps me from making stupid mistakes
        • keeps me from gold-plating
        • I spend less time debugging
        • I know more about the system
        • handing off work is easier
        • code is more consistent throughout system
        • when we get tired, we notice and take breaks
        • improves truck factor massively


        That last one is probably my favorite. When I'm on an XP team, taking a vacation is never a big deal, because I'm never the only person who knows how to do something.

        • That's one good reason for pair programming, but it's far from the only one. Here are reasons I like promiscuous pair programming:

          * instant code review
          * instant design review
          * keeps me from making stupid mistakes
          * keeps me from gold-plating
          * I spend less time debugging
          * I know more about the system
          * handing off work is easier
          * code is more consistent throughout system
          * when we get tired, we notice and take breaks
          * improves truck factor massively

          And it th

          • And it therefore costs your employer twice as much.

            In many cases, the amount of time saved on code creation, bug catching, and testing far outweighs the initial investment of two developer's time. If the code is better and contains few bugs, it is worth a lot more than the same mass of code with far more bugs.

            I really don't think pair programming is productive. When you are just churning out code there is no need for two people to look at the screen - one is enough and you can get things done quic

          • And it therefore costs your employer twice as much. Good programming teams will pair up when the going gets tough and two sets of eyes are better than one.

            Therefore? That may or may not be true, but you've proven nothing.

            Between me and the previous poster, we listed 11 things that pair programming improves. If those have any effect on productivity, then that changes the productivity ratio. The only thing that's 2x in pair programming is the hand/keyboard ratio, so your theory would only be true when typ

      • Two inexperienced people shouldn't be paired. All of their arguments will end up being over who is able to make who back down. Complete waste.
        This is not my experiance.

        EWither the topic is not important, then they will really fast solve it by chosing either of the two approaches.

        If he topic is important, the one who is wrong will very likely understand the arguments of the other one.

        Smart people usually want to get the job done and move forward to other interesting "problems" like anyone else.

        If the
        • If the guy who is wrong does not step back...

          I think the reason we disagree on the question of two inexperienced people being paired relates to the source of the disagreements between them. You are talking about "the one who is wrong" as if in most disagreements one will be right and one wrong.

          In my experience, almost all of the disagreements are over personal preferences regarding how to do handle something. "We should use a 'for loop' because... No, a 'while loop' is better in this case because...." Or
    • Hi,

      hm, sorry to answer to your post, as your analysis is quite ok.

      Most posts here are really negative. I wished that most of you would start your post with: I've never done it.

      Bottom line: only the posts starting with: "I've done it" are relevant.

      I was allways wondering about an "Gedankenexperiment" (I know this is an english term :D ) like this: Posting a slashdot question: "Hi all, did you ever read Brooks? What about the factor ten programmer, who of you is one? Did you ever meat another one? What is
      • I'm sure you're a great programmer, but your spelling is a Factor ZERO.

        Slashdot needs a spellchecker.
        • Sorry about my spelling erros, when I'm tired I make even more :D
          You saw that post on /. about reading and words where only the starting letters and ending letters need to be somewhat correct for understanding? I guess my problme is, I don't see spelling errors. (Besides the problem that I make errors like piece/peace/ peese and do not really notice it)

          angel'o'sphere
          • Luckily we have compilers to take care of the details. A lot of people think that I'm a really detail oriented person because I can write a program with hundreds of thousands of individual characters, all of them in the right place. The truth is that it's the compiler that enforces that, not me.

    • I think this about sums it up. I've never done this in a work-environment, but can easily guess from doing programming in the CS-major-only lab. Man did I hate 1 / 2 when the other guy was a real dumbass and didn't really care. You have to laugh at 3 if you overhear them talking to eachother from a distance. 4a was the best though. How I wish I could have 4a and still be self-employed. Nothing beats writing a huge chunk of code and finding all the bugs simply because another great programmer is looki

  • Just get off the keyboard retard! (Score:5, Funny)

    by QuantumG ( 50515 ) <qg@biodome.org> on Tuesday September 28, 2004 @06:30PM (#10378545) Homepage Journal
    "Type foo"
    "What?"
    "There, foo"
    "Oh yeah, ok"

    "No, foo"
    "Oh right"

    "Oh for fuck sake.. FOO, the keyword is FOO"
    "Oh sorry, was thinking about something else"

    Pair programming is like watching a woman change channels. "You know what's on this channel, it's shit, keep going."
    • Pair programming is like watching a woman change channels. "You know what's on this channel, it's shit, keep going."

      If it's like that, you're doing it wrong.

      For me, it's like the driver/navigator combination on a road trip through an unfamiliar city. Except it's better. If I notice my partner glazing over, I just shove the keyboard over to him. That's harder to do in a car.
      • It's like that for me too, but it's a woman driving the car.
        "Ok, just turn left before the round about."
        "What? Turn left at the round about?"
        "No, turn left before the round about."
        "So I have to drive up to the round about?"
        "Yeah, but turn left before it."
        "Ok". We then proceed to turn left at the round about.
        "No, you needed to turn left back there."
        "You said turn left at the round about."
        "I said turn left before the round about."
        "No you didn't."
        "I did!"
        "I asked you if we needed to drive up to the round abo
        • >>Re:Just get off the keyboard retard! (Score:3, Funny)

          The funny thing about the comment above was that someone actually thought it was funny. Heh. Wait until you get married ... you won't find it funny then.
    • This is where you need to be using a Mac and SubEthaEdit.
    • Attached, please find an overview of the company
      guidelines, and prospectus.

      Frank Fingerman

      It is most efficient to communicate by means of the
      internet. I have conducted studies to confirm this.
      Please convey your remarks via email.

      Frank Fingerman

      How are you coming along on the prospectus?

      Frank Fingerman

  • I gave up (Score:5, Interesting)

    by sfjoe ( 470510 ) on Tuesday September 28, 2004 @06:31PM (#10378553)
    I was assigned to do pair programming with a more senior person. I got so tired of my suggestions being ignored (not disagreed with, ignored), that I just gave up and sat and watched him. The project had long since morphed into a Death March so this was just one more reason to loathe going into work each day.
    If I ever get forced into another pair programming situation, I'll use my spare time to apply for other jobs.

    • Re:I gave up (Score:1, Funny)

      by Anonymous Coward
      I tried pair programming with my siamese twin, but I guess I pissed him off so much he tried to beat me senseless.

    • Re:I gave up (Score:5, Informative)

      by pyrrhonist ( 701154 ) on Tuesday September 28, 2004 @08:05PM (#10379275)
      I was assigned to do pair programming with a more senior person. I got so tired of my suggestions being ignored (not disagreed with, ignored), that I just gave up and sat and watched him.

      Your experience was done completely wrong. Part of pairing a senior developer with a junior is to teach the junior developer things they didn't learn in school However, the junior developer constantly questioning the senior developer's judgement is equally as bad as the senior developer ignoring the junior developer. Neither developer is there for the other's amusement, and it's good to keep in mind that there should be no criticism; sometimes neither developer's idea is very good.

      These are the problems as I see them:

      • You should have been the one typing. You will learn more this way, the other person should express things as ideas, and not code. Then, as a senior, he can point out optimizations, if you go astray while coding. Telling someone how to type printf is not pair programming, noting that the error needs to be logged is.
      • The senior programmer should have told you why he thought your ideas wouldn't work, and not be such an asshole. It's not helping you any if you don't understand why the senior is choosing not to implement your idea, and he probably has a good reason.
      • Likewise, you need to learn when to shut up and not be such and asshole. The senior has more experience than you, and stating the obvious on every line is not going to accomplish anything. He already knows what to do, so either ask constructive questions or add to the design; don't just spout idioms and cliches.
      Pair programming is a two way street!

      • Re:I gave up (Score:1, Insightful)

        by Anonymous Coward
        some of these so called "experienced" developers are completely idiots with no real skills. There are these terrible hacks who know little about good practices and aren't willing to learn. I think we've all seen this before. If I ever get paired with one of these types, I would lose it, working with them on the same project is bad enough. They break the build constantly, keep files checked out for no reason, make rookie mistakes constantly, get you to help fix a problem that was their fault yet act like
      • Your experience was done completely wrong.

        Agreed. When people are learning to pair, I tell them they should make sure the keyboard changes hands every 10 minutes or so.

        Another good way to force collaboration is to have person A write a test and person B make it pass. Then B writes the test and A makes it pass. It's a fun game.
      • Likewise, you need to learn when to shut up and not be such and asshole.

        That didn't come out right. Before I get flamed, let me explain myself by saying that I'm not claiming that you personally are an asshole. I was attempting (badly) to show how you could be perceived by the senior developer, and that sometimes it requires practice to learn to not say something at the right moment.

        Anyway, I hope I preempted any confusion, hurt feelings, etc.

      • You should have been the one typing.

        That was one of my ignored suggestions.

        ...and he probably has a good reason.

        Possibly. Actually, I don't think he was even hearing me.

        Likewise, you need to learn when to shut up and not be such and asshole.

        I did shut up. I thought that was made clear in my OP.

        • Re:I gave up (Score:4, Interesting)

          by pyrrhonist ( 701154 ) on Tuesday September 28, 2004 @11:32PM (#10380452)
          That was one of my ignored suggestions.

          You were on the right track! Your pair was improperly trained.

          Possibly. Actually, I don't think he was even hearing me.

          That's completely unprofessional. All I can say is that the developers that I have worked with would never do anything like this. In fact, in the last place I worked where pair programming was not policy, we sometimes ended up initiating a pair programming session on our own when we had a particularly hard problem to solve. This happened regardless of the seniority of the engineer.

          I did shut up. I thought that was made clear in my OP.

          Ack, that's not really what I mean; see this earlier explanation [slashdot.org]. In your particular case, being quiet wouldn't have helped you. Unfortunately, your partner is an antipattern, and probably no amount of diplomacy would have helped.

          Let me try to illustrate this better with an example: Back when I was a junior developer, I was put on a project I had no experience with (I didn't even know how to program in the language they used), and told to add a particular feature in a very complicated section of the code. Of course, I had questions, and it so happened that the main developer (and the person I was told to work with) was located right across the hall from me. So, I would pop in from time to time to ask questions about what certain undocumented variables meant, or which part of the state machine I could safely change. I thought everything was fine until my annual review where I got lambasted for, "asking too many questions". Of course, my first thought was, "That greasy bastard!"

          However, you have to look at it from his point of view. The code that I was working on was not critical (it was going to be heavily reviewed and documented before it was passed off on). The code he was working on was critical, more complicated, and on a tighter deadline. He was the more critical resource, and even though he was told to help me, his time was more important. What I should have done was prepare a list of all the questions and sample code that I had, and scheduled an early meeting with him. In other words, working with him instead of pissing him off.

          This is a skill that has to be learned, and unfortuately the way it's usually learned is that the junior developer gets pinged. Over the years, I have found myself in the same situation as the senior developer in my story, but I have, at least, been better about telling junior developers what I expect and scheduling time with them.

      • Your experience was done completely wrong. Part of pairing a senior developer with a junior is to teach the junior developer things they didn't learn in school However, the junior developer constantly questioning the senior developer's judgement is equally as bad as the senior developer ignoring the junior developer. Neither developer is there for the other's amusement, and it's good to keep in mind that there should be no criticism; sometimes neither developer's idea is very good.
        I would hope that any pr
    • The times it's worked for us was in death march mode. One person who was the better-animated zombie for the time being would code. The less-well animated zombie would eyeball the code and look for stuff. Worked well because there were lots of annoying errors popping up: people picking nondescriptive variable names in a for loop then forgetting to actually use the incrementing variable (declaring a descriptive incrementing variable elsewhere that never changed! Genius!)When zombie A wound down, zombie B
      • Worked well because there were lots of annoying errors popping up: people picking nondescriptive variable names in a for loop then forgetting to actually use the incrementing variable (declaring a descriptive incrementing variable elsewhere that never changed! Genius!)

        Wow. Sometimes it's better to just slow down and not make stupid mistakes like that to begin with. When I start to do that I go home... and post on slashdot.
    • As others have pointed out, it's all about working toghether.

      We have bought the book "Pair Programming Illuminated", ISBN 0-201-74576-3, which talks about the practical things related to pair programming.

      I have not read it yet, but I noticed that one of the chapters has the following title: My Partner Is a Total Loser and Other Excess Ego Problems :)

  • Small experiences (Score:1, Funny)

    by Anonymous Coward
    Had a chance to do a few days of pair programming with a coworker. We have worked well together for the past two years, but this was our first time paired. Normally, all coding is done alone in my company.

    I fell in love with her.

  • Hey! You were no rose either. And that whole printing routine was a farce. And its YOUR FAULT. I suggested something different but you had the keyboard. And speaking of which-you hogged the keyboard the whole freakin time too!

  • Missing the point? (Score:4, Insightful)

    by Anonymous Coward on Tuesday September 28, 2004 @06:50PM (#10378719)
    I found my pair programmer a bit difficult to work with.

    That's actually the whole point of pair programming. It's supposed to slow you down so you make fewer mistakes.
    • That's actually the whole point of pair programming. It's supposed to slow you down so you make fewer mistakes.

      Um, couldn't I just type with one hand tied behind my back?

      People either know what they are doing, or they don't. A system which siameses two people to do the job of one sounds like the latest "Managment Consultant" speak, as well as a way to sidestep the issue that some of the people can't do the job.

      Teamwork is for Horses. More can be accomplished by having fewer people exerting individual effo

      • Working by yourself makes the assumption that you are the best there is at everything and you have the time to do everything quickly and efficiently. This does not mean that every task needs a commitee of ten idiots working with you. This does mean that having a 2nd person that is really good covering your weaknesses (and you in return) is something that will be immensely productive.

        The problem lies in the fact that you can't just automatically put two people together and assume that that is the best case
  • Things I would recommend:

    - Communication. This is by far the most important quality to have as a pair.
    - Patience. Sometimes your pair might not be at the same level you are, in this case, it is your job to help get them there.
    - Assertiveness. If you have no clue what your pair is doing, ASK!

    Other recommendations I have are to force your partner to drive if they are more inexperienced than you. This will help you both learn. If you don't have any idea what's going on then tell your partner you'd like to drive for awhile. I find this helps get you focused and allows you pick things up faster.

    Of course, if your partner just isn't willing to cooperate, then I think there are other issues that need to be dealt with. But, for the most part, I think people are more than willing to teach others, you just have to ask and communicate.

    Another thing to keep in mind, too, is to give it time. You aren't going to be a master pair after a few days or weeks.

  • I get a lot done (Score:3, Insightful)

    by Paradise Pete ( 33184 ) on Tuesday September 28, 2004 @06:52PM (#10378727) Journal
    The main thing it does for me is keep me focused on working. It's also good when there's a hairy problem to figure out. But sometimes when it's time to just crank out some straightforward code without getting distracted it's better for one person to go take a break for a while.
    • Personally, I'd rather have an elbow fungus when there is straightforward code to crank out, because I might fall asleep and drive off the road. It's when there's a hairy problem to solve that I need to focus, concentrate, and comprehend the path traced by each follicle in solitude.
    • You mean that having someone sitting next to you keeps you off of /., right?
      • You mean that having someone sitting next to you keeps you off of /., right?

        Well, yeah, that's part of it :-)
        Last week I travelled to an office where I had no internet connection. One of my most productive weeks in a long time.

      • BTW, in pacman I'm seeing trails. I noticed in your notes that you've tried to fix it, and they don't always appear, but sometimes they still do. I don't see an obvious pattern as to when. Also, I tried to look at the source code, but the link that says source points to the jar.
        • I tend to export both .java and .class files to my jar files. So the source is in the jar.

          I am guessing that you own a Mac! Java draws things slightlty differently on a Mac. Drawing a circle is always 1 pixel larger to the right and also down on a Mac. Now that I know this I need to take it into account. I also need someone with a Mac to test it.

          I will put a fix up and reply to this your comment.

  • Nothing different (Score:5, Insightful)

    by The-Bus ( 138060 ) on Tuesday September 28, 2004 @07:16PM (#10378908)
    Not really anything different than working with any other person. Programming doesn't introduce some new kind of situation to deal with that teams of two haven't been dealing with for centuries.

    So, my tips, just coming off about a year's worth of pair work:

    1. The most important thing is that you have to be complementary. That is, their strengths have to fix your weaknesses, your strengths have to fix their weaknesses. If they don't have any strengths, it will be more like training for them, a mentor/student situation as opposed to a true team.
    2. Think of it as a product. If "average" or "baseline" is 1, it helps if you're a 2.1 and they are a 1.4. If you're very good and they're not, the total suffers. Only work with someone that is as good as you or better, and only do it if you're very good to begin with.
    3. Define exactly who is going to do what! This is not terribly succesful when managers do it because they're not you two -- they can't see you in action and suggest anything. It's up to you to figure out what works best --- split up all the different tasks so that each of you are doing what you do best. As you go along you will find out whether it's better to write these down and adhere to them or (better yet) have them be somewhat fluid so that some responsibilities cross over.
    4. One system should keep track of what's going on. Whether that's a calendar you both use, a checklist pinned on the wall, an eraseboard, or just one of you two.
    5. (Regarding the previous). Think in term of goals, not minutiae. You both should be good enough that if you're, for example, auto mechanics, one of you says, "Find out where the noise on the Pontiac is coming from" rather than saying "From 10:30 to 11:00 I want you to inspect the following parts and pieces of the Pontiac: A, B, C, D..."
    6. Keep everyone else out of it! Once a system is established and you've learned to rely on each other it's going to be really obtrusive to have others meddle in.
    7. Meet together with management whenever possible.
    8. It helps if both of you have similar goals as to the level of your performance. Even if both of you are skilled gurus and one of you is checking job sites because they need to leave in the next six months, that's not going to work out.

    This is, as I said before, from about a year's experience working day-to-day with only one other person. I hate paperwork, don't really like a lot of "busy" work and, in both cases, the other person just wasn't very good at some of the major intricacies of the position. The first time, we were more succesful than either of us was alone (generally being 2.5x times as productive as any individual). The second time, we were doing about as much as eihter of us were doing individually.

    The good thing is that now I'm back by myself and have become a lot better thanks to the teamwork environment. I wasted a couple of months, but that's behind us now.

    • Re:Nothing different (Score:5, Interesting)

      by Tony-A ( 29931 ) on Tuesday September 28, 2004 @11:25PM (#10380406)
      Programming doesn't introduce some new kind of situation to deal with that teams of two haven't been dealing with for centuries.

      1. "their strengths have to fix your weaknesses, your strengths have to fix their weaknesses"
      By far the most important. An old rule of thumb (before the Mythical Man Month) was that "if one programmer can do it in one year, two programmers can do it in two years." When and if the "two heads are better than one" comes enough into play, the answer can be two months!

      3. "who is going to do what". Bad place for management to meddle. People tend to hide their weaknesses, even from management. When a team works, individual weaknesses are very well hidden from all onlookers.

      4. "One system should keep track of what's going on."
      Absolutely. In fact one bad system will beat two good systems.
      You can tolerate different goals or directions. You cannot tolerate different positions of where you are now.

      6. "Keep everyone else out of it!" Effective teams become very suspicious of all "foreigners", not excluding management.
      • 6. "Keep everyone else out of it!" Effective teams become very suspicious of all "foreigners", not excluding management.


        Keep the people who are paying the bills out of it? You're joking?

        Keep management out of it? You're joking? They're the ones who tell the bill payers how things are going.

        A teams actions must be transparent and accountable for their actions, right up the chain of leadership.

        D
        • Teams are an "in place of" not and "in addition to" type of thingee.

          Management judges a team on results, not on how the results were achieved.
          If a team fails to perform, it's back to the old way of doing things.
          Management's rights regarding teams is the ultimate solution, to destroy the teams.

          A teams actions must be transparent and accountable for their actions, right up the chain of leadership.
          That isn't a team. It's a chain of command. Weakest link and all that.

          • Management judges a team on results, not on how the results were achieved.

            Really? The ends justtify the means, and all that? I have never seen a management team who judge only on results. They manage, not just judge.

            A teams actions must be transparent and accountable for their actions, right up the chain of leadership.

            That isn't a team. It's a chain of command. Weakest link and all that.

            Really? You've never seen a situation where one team reports to another team? e.g. a Build team reports to a managem

            • "The ends justify the means, and all that?"
              Good one, but if the ends do not justify the means, then what does justify the means? If the means are not employed to effect some end, then why are the means employed? What is true is that ordinary ends do not justify extraordinary means.

              "management team"? Like a "sanitary engineer" is almost certainly not an engineer, a "management team" is almost certainly not a team. The term "team" is used in the hopes of maybe getting a wee bit of cooperation out of the memb

  • Quasi_pair (Score:4, Insightful)

    by cookiepus ( 154655 ) on Tuesday September 28, 2004 @08:09PM (#10379304) Homepage
    First of all, I think the problem is with you. Here you are asking us for feedback on pair-programming, but you barely tell us what problems you encountered. Do you just sit with your pair and say "all this shit is fucked up?" You should probably tell us the specifics of the issues, at the very least for our education, and maybe someone can address them more specifically.

    Anyway, just kidding. Didn't mean to attack you personally, just consider what I said.

    I find sitting and developing with someone very useful, especially if this person is new-ish and I want to bring them up to speed. Basically I watch them do their thing and comment on what they're doing, especially if it could be done better. This is certainly very effective at keeping them from putting in silly errors, because I spot those right away. But the real advantage is that from short sessions like this I can ascertain the person's grasp of the task. If I can see that he's basically looking at the right things and going about it the right way, I feel OK with going back to my desk and doing my stuff. If the guy makes a lot of errors and is generally approaching things the wrong way, good thing I am there to keep him from getting too deep.

    I would guess that mandating 2 programmers per computer at all times is too much, but there certainly are times when doing this for short periods of time is extremely productive.

  • In my most recent contract I've been working with various levels of experience and switch between working solo, teaming with an associate at the same workstation and working remotely on several junior associates workstations. For those that are significantly less experienced I've found that remotely accessing their desktop to demonstrate or help with a problem/question to be very useful, plus I can help more people in a shorter time. I get to continue working on my assignments at a steady pace and they ca

  • The key is communication (Score:3, Interesting)

    by Zarf ( 5735 ) on Tuesday September 28, 2004 @09:59PM (#10379928) Journal
    ... if you are not both effective communicators then pair programming will only be painful. You must be able to handle criticism, give criticism, and do so in a constructive way. If you can't do that then you're too old skool programmer for the new skool programmer ways.
  • And I think it may help if you and your partner have different strengths and weaknesses so that you compliment each other somewhat.

    Right now I'm taking a real-time and embedded systems course at RIT. The idea is that it's inter-disciplinary: CE, EE, CS and SE students are taking the course.

    So for the projects, they pair a CS or SE student with a CE or EE student. This makes for teams with one person who's strong in lower level (assembly/ hardware) work, and another who's more familiar with higher- leve

  • Over the summer I had to do an "extreme programming" project. The group had three members, including myself. I was the 'code monkey' type. I took care of the libraries and helper functions and regular expressions and filesystem quirks. The second member was the database guy and front-end guy. Since both of us could to an extent do the job of the other while being primarily focused on separate components, this worked well. We sat down and worked on our own stuff. Occasionally we would request functions of
    • He was eventually banned from putting functions in the libraries because he had a habit of working from old files and wiping out our good working copies.

      Eek, you had more than one programmer working on the same system, and NO REVISION CONTROL???

      Please tell me you at least had backups?

      • Of course we had backups. The project wasn't big enough to bother with CVS, though. It worked as long as common sense was used. However, this fellow apparently didn't see anything wrong with writing functions into a two week old copy of the library and then dropping it into the working copy.
  • It helps to have a thick skin. The only times I've done pair programming we end up making fun of every little mistake the other makes. It's fun and funny with the right person, but with the wrong person this can go too far.

  • that should be a lot of fun (Score:3, Funny)

    by jdkane ( 588293 ) on Tuesday September 28, 2004 @11:25PM (#10380408)
    From the article: "The other programmer, the observer, continuously observes the work of the driver to identify tactical (syntactic, spelling, etc.) defects"

    Driver: click, click, click, tappety-tap tap tap, click.

    Observer: Dude, Intelli-sense just underlined that word in red. It's some kind of syntax error -- just hover your mouse over it to see it.

    Driver: Ya, I saw it ... I just want to finish up what I'm typing and ...

    Observer: It just underlined something else in your code. I don't think it's gonna' compile.

    Driver: Of course it won't compile. Just wait until I finish this thought .... tap, tap, clickety click, tap-tap

    Observer: I would fix those errors before continuing.

    Driver: WHY? clackety-clack, slam, bang

    Observer: Why not?

    Driver: ARGH!

    Observer: I'm bored. I'm just gonna' go grab another coffee.

    Driver: GO AHEAD. AND WHILE YOU'RE AT IT, HAVE A SMOKE, AN EXTRA LONG LUNCH, AND THEN TAKE THE REST OF THE DAY OFF BECAUSE YOU'RE NOT LOOKING SO GOOD RIGHT ABOUT NOW.

    • When we were pairing around here (gave it up, not appropriate for this business model, etc...) we got over this in the first day.

      Our Driver could type all of the mistakes he wanted to, but since the Navigator was doing the big picture stuff too (in addition to being an observer) he could indicate just before the driver switched functions/files/pages that there were problems. So your conversation would have gone more like:

      Navigator: Modify that bit in Foo.bar() to do such-and-so.
      Driver: clickety-clicket
  • I actually like the working together fact. Not on a regular base, but for complex stuff it is quite usefull. So while we were having two laptops and a screen session to a file I asked out loud:

    Why don't we have two carets in the same file so we can edit both at the same time.

    If someone knows an editor capable for this groupworking please reply.
    • emacs is the solution. meta-x make-frame-on-display and there you have a single emacs instance on 2 displays with the same set of buffers and both displays can edit at the same time. If you are clever with cygwin probably can do this on windows too.

      All praise emacs!
    • If you're lucky and work on OSX you might want to try out SubEthaEdit [codingmonkeys.de].

      You can browse other user's open documents via Rendezvous - errr... OpenTalk, grant them access to your open docs. And nice colors so you can see who is breaking what.

    • "...Why don't we have two carets in the same file so we can edit both at the same time..."

      For the same reason that cars don't have two steering wheels up front.

      You're renaming/deleting class member variables in your editor view, while your buddy suddenly sees the member functions he's working on fall to pieces, because they depend on those variables?

      Of course you could tell him what you're doing, and he can wait until you're done. And like many world-beating multi-threaded concepts, it is degraded i
  • me and my partner run a web development firm, after getting to know eachothers styles, it's a breeze now! we can colaborate together, or finish up eachothers work, it's a great experience. i guess not so much if you're just starting out with someone, but give it time and you'll love the benifits.!
  • Has anyone been in this situation, and what things can be done to work around the personality conflicts?
    One word: Firearms.

  • Working in pairs requires two focuses (Score:3, Interesting)

    by Peter Cooper ( 660482 ) on Wednesday September 29, 2004 @04:50AM (#10381594) Homepage Journal
    Working in pairs can only work if each member of the pair has their own responsibilities, and not, like in most pair programming, the same responsibilities. For example, pilots can work in pairs since while one 'has the stick' or is talking to the tower, the other can be dealing with navigational and environment issues.

    Sitting watching someone program is not the same, whether you're making input or not. Put it into the pilot's position. Pair programming is like the co-pilot constantly saying to the pilot.. 'er, nudge to the left a bit', 'hey, watch out for that cloud there', 'it's time to call the tower', instead of actually doing something productive.

    Mechanics can work in pairs, but generally they'll be working on different areas of the car.

    Surgeons can work in pairs, but each will have a specialty, or more hands are just required to do that particular op.

    Musicians can work in pairs, trios, and so on. But they don't all gather around a piano and give suggestions to the person at the keys! They all have their own instrument and play at the same time.

    If you want to code in groups, code in groups.. but make sure at least everyone has a keyboard!
  • I think pair programming can be useful but I think it is important to pair up programmers of similar skill level.
  • I like the concept of pair programming, but it seems in practice it's hard for everyone to get behind it, and there are other things you can do that are just as good. Like, you can get everyone in the same room with their computers close together. You can occasionally ask "what are you doing now?" and solicit opinions on your own tasks. You can give show-and-tell sessions every day. You can help write unit tests for someone else's code. If everyone understands the high-level issues, and the priorities, and
  • No two people think alike, regardless of any equality of externaly measurable/testable aspects of their intelligence. So what is left to fix? Their EGOs. My understanding of the theoretical advantage of this approach is that it is like the discovery that you could more easily make a waterproof super-thin rubber membrane, despite the tendency of the raw material to have tiny holes, by laminating two thinner membranes: the defects never line up. Two programmers are not likely to have exactly the same blind

  • I hate it I hate it I hate it I hate it. (Score:2, Insightful)

    by Anonymous Coward
    Pair programming is a crutch to prop up people who have no clue what they're doing. Take one smart person, one thumb twiddler, and they just might be a quarter as productive as the smart person alone. But we don't mind, because Mr. Thumb Twiddler isn't twiddling his/her thumbs anymore. And getting things done isn't nearly as important as making sure everyone looks busy.

    The only way to program is on your own. Learn stuff from more experienced people at code/design reviews. If you need someone staring over y
  • I often pair up with a friend of mine on projects - not necessarily programming directly, but sometimes technical stuff (design, implementation, etc with programs already written). My friend is doing his Master's in CS, and I have one year of an Arts major done. Suffice to say, he's the better programmer.

    What I bring to the team, however, is the big picture. I can design in my head in a few moments how things should be laid out and the possibilities of each option, I know enough about languages to pick the
  • I've had a few experiences with Pair Programming at Lockheed. It's been pretty interesting, but it has its ups and downs. Some people are very suited to "pilot" and others more to "copilot". It's important to switch off these two roles, but some people just can't take one role.

    I had to do a kind of emergency-coding-session with my boss, he had dawdled on a project and then management applied thumbscrews, so we decided to just crank it out in a week.

    I started as copilot, and didn't like it very much, sin

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close