Slashdot Mirror

← Back to Stories (view on slashdot.org)

Experiences with Pair Programming?

Posted by Cliff on 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?"

3 of 125 comments (clear)

  1. Re:I gave up by pyrrhonist · · Score: 4, Informative
    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!
    --
    Show me on the doll where his noodly appendage touched you.
  2. Actually I'm doing this right now... by BeatdownGeek · · Score: 2, Informative
    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- level programming concepts.

    I've found that while my teammate knows the assembly much better than I do (I'm SE) I can more easily grasp the overall design and algorithms involved to complete the task. This actually made for very productive work since it's like having two different perspectives working on the same puzzle.

    I imagine that if both of the ppl involved were at the same level knowledge-wise, it could get frustrating. In that case I would just look for peer review. But in my case it's been working great.

  3. Re:Pair Programming with two keyboards by firefarter · · Score: 2, Informative

    If you're lucky and work on OSX you might want to try out SubEthaEdit.

    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.