Forgot your password?
typodupeerror

Pair-Programming with a Wide Gap in Talent? 121

Posted by Cliff
from the there-is-no-"i"-in-team dept.
efp asks: "I'm a graduate student and have a programming assignment coming up. We're encouraged to work in pairs and I've agreed to work with a friend. However, while I'm far from l33t, I've several years more experience than my partner. Are there effective techniques for pair programming with a wide gap in talent? I want us both to get a lot out of the assignment, and I do not want to do all the work (which has been specifically identified and disallowed by the instructor anyway). Navigator/driver scenarios? Index-card design techniques?"
This discussion has been archived. No new comments can be posted.

Pair-Programming with a Wide Gap in Talent?

Comments Filter:
  • peer programming (Score:2, Informative)

    by schematix (533634) * on Wednesday March 29, 2006 @09:36PM (#15022704) Homepage
    There are quite a bit of things that you can do in this situation, and most of it depends on the skill differential and the type of project. If your partner is not a very good programmer, expect to be their teacher. However, you can't expect to hold their hand the whole way and help yourself or them. They will have to contribute their share in one way or another. As the more experienced programmer, you should have more control over the direction the programming starts off in. Don't leave your partner out though. Talk with them about what you are doing and why you are doing it. Give them tasks that you know they'll be successful at. You might need to do the most complex code yourself, but they can certaintly help fill in the gaps whether it be by writing and testing functions, doing research for the code you need to write, testing what has been written or doing documentation or other right-up related material. I think the bottom line is that you need to excerise your superior skills in a way which positively impacts your partner. Don't be over bearing but don't give them enough rope to hang themselves (or you for that matter).
  • Re:Swap out (Score:3, Informative)

    by Anml4ixoye (264762) on Wednesday March 29, 2006 @10:17PM (#15022910) Homepage

    Exactly what I was going to recommend. By writing the tests first, you can help drive the design as the more experienced person. But by them trying things to pass it, they learn a lot too.

    The biggest challenge is to consistantly do the simplest thing possible (not the dumbest thing).

    If you run into problems, I'd highly recommend the TDD list [yahoo.com], or you can feel free to ping me offline.

  • Try this... (Score:2, Informative)

    by owlman17 (871857) on Wednesday March 29, 2006 @10:30PM (#15022980)
    Extreme Programming. http://www.extremeprogramming.org/ [extremeprogramming.org]
    One of its basic tenets is pair-programming: http://www.extremeprogramming.org/rules/pair.html [extremeprogramming.org]

    Of course, if your partner is way below your level, every session would end up being a tutorial, very counter-productive. In which case, he should either step-up by practicing in his spare time, or worse comes to worst, get a new partner.
  • by chromatic (9471) on Thursday March 30, 2006 @02:50AM (#15024262) Homepage
    I always thought the whole point of pair programming was to bring newbies up to speed with stuff...

    That's a benefit when it occurs, yes, but the real point of pair programming is to get two people working together on a single task to stay disciplined, to implement all of the necessary features, to produce the best possible code, and to spread the knowledge of the entire system throughout the team. It supports many of the other XP practices.

  • by Rudi Cilibrasi (853775) on Thursday March 30, 2006 @12:54PM (#15026948) Homepage

    The best way to bring up a newbie in pair programming is to give her simple stuff that she can do reasonably quickly and well enough. The most common highly delegatable by far for text-based programmers like me is translation scripts. It's a breeze to specify; You need to figure out what other programs you are going to interface with and then just tell them what you need in and out. Best to have real files to work with. For example, in my field I use a lot of distance matrixes that consist of an array of labels and a 2-dimension square of numbers that is diagonally symmettric; but there are many different formats for these and my CompLearn [complearn.org] system only supports one text matrix format. So already there are a bunch of simple translation programs that I can easily delegate by saying "see this distance matrix output from program X?" Translate it to something that works with CompLearn! This is also useful for the output side of most programs that need to work with the real world. And of course the venerable and highly useful HTML screen scraper is a great subtype of this big class of programs. The reasons this is so good to delegate are as follows:

    • It only needs to work, it doesn't need to interface to the rest of your program, so if they really mess up the interface or have bad style it is probably no big deal.
    • It is usually simple enough to dispense with all custom objects/classes and sometimes even functions are unnecessary for these things. the goal should be to get it working as quickly and easily as possible with a minimum of fuss: perfect for agile goal-oriented development and extremers.
    • Once they write a half-dozen or a dozen of these they are ready to start playing with lambdas, functions or maybe small classes. As a scientific programmer, half my coding is translation scripts and as I get more and more into text-based systems the percentage seems to go up. text goes a long way and the skills are very composable with existing unix utilities and pipelines without any hassle at all.

    My favorite language for this kind of thing is Ruby, but I think Perl or Python would be fine too; anything that supports regexp and decent strings is a winner.

    Happy Pair Programming and good luck! Rudi [cilibrar.com]

"We are on the verge: Today our program proved Fermat's next-to-last theorem." -- Epigrams in Programming, ACM SIGPLAN Sept. 1982

Working...