Pair-Programming with a Wide Gap in Talent? 121
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?"
Did the same thing in college (Score:3, Interesting)
An opinion (Score:1, Interesting)
Unfortunately, you aren't in a corporate scenario, where each individual's contribution to the success of the project will (in theory) be judged more or less independently and rewarded accordingly. You are in a class, and the same score for your project will be assigned to you both. That being the case, try out pair programming if the disparity in skill is not too great and your partner shows willingness to invest in learning. Otherwise, then do the bulk of the work yourself and assign your partner to peripheral tasks, to whatever extent your instructor's directions give you leeway. It is ultimately your grade on the line.
In the initial sessions, assess your partner by observing how he behaves. When not in control, he should be actively contributing to the project by pointing out mistakes and ways in which the code should be better and learning by asking questions about what you've done that he doesn't understand or doesn't understand the reason for. He should also actively be encouraged to take control when he believes his solution is better than yours. When in control (which, as the learner, should be the bulk of the time), he should be able to independently navigate to an acceptable solution, ask questions if a path to a solution or anything else is unclear, and be responsive to your guidance. Within a few sessions, also begin assessing his level of improvement. He should be focused on learning by observing you. If he does not do these things, gently encourage him to do so.
Pair Programming... (Score:3, Interesting)
I think there is a really excellent chapter in the following book Pair Programming Illuminated [amazon.com] which discusses this. Basically, this is a teacher and student relationship in a sense. As such, you need to encourage the novice to ask questions about what you are doing (when you are driving), and to encourage the student to talk out loud about what they are thinking when they are driving. Finally, you must slow down and explain when things are tricky, and never confuse head-nodding or awed silence for understanding.
As the expert, you do need to delegate tasks. I think it is fine to send a student off on small individual assignments on the project, and then bring it back, they can explain it to you, and you provide comments on the work. Together, you can then bring the code into the codebase. This gives the novice the sense that you don't have to watching over their shoulder all the time, and ideally, moving the code into the your project is quick and simple.
If there is an existing code base, one of those assignment could be a simple "Present it to me" task. Learn this bit of code, and explain what purpose it has in the system, and bring me a list of questions and concerns about it. Then, after that, do a pair programming task that involves that code. The novice drives, you watch.
The list goes on and on. One other thing is to try to get the less experienced person to take on more and more tasks. In fact, you can almost challenge that person to know more about a part of the project than you do. This is good, because you don't have to be the expert on everything, which is tiring. And more you aren't the sole expert on, the better for you. You can just bring your experience to bear when it is requested, allowing you to focus on other tasks.
Re:It sucks (Score:2, Interesting)
"I need to check if the user entered a number... ok, so I remember something about ascii codes and that I can check to see if a certain value is a number by checking against this table, ok I've written a little function - done!" Ad nauseum.
Working with a partner involves educating them. This education can in turn help you, because in order to teach someone else something you are forced to learn more about it. Just remember, no one is born knowing that isalpha is in the standard lib.
I did this in Grad School for a AI class once. (Score:5, Interesting)
The kicker was, we could only really meet and work together on the weekends ( unlike everyone else who lived on campus ). He had a day job. Thus we only had 6 weekends to do it ( and I would be missing a weekend because of spring break too! ).
So we said "Whoever can get the basic search functions working first, we'll use that language." By thursday, my framework was working, he was still fighting various pointer problems.
"I don't smalltalk" "You know programming. It's all the same. I'll teach you the language, it's dead simple."
Smalltalk has a very small keyword set, and very simple but powerful semantics. So I explained it to him as we typed. And even with the vast gulf between C and Smalltalk, he was able to catch some common problems, and offer some design ideas.
Working only on weekends, we were one of the few groups to finish a working program that could play the game well. In fact, we had one weekend left.
The last weekend before it was due, we used Visualworks UI designer ( before glade even existed ) to make a gui, hooked it into the engine, and players could then play against the computer with a nice UI. It kicked butt.
We were the only group that finished on time, with a working game engine and working GUI. All the other groups, if their project ran at all, had a command line interface. I remember chuckling to myself at the start when one group mentioned that they were going to use C++ and MFC, and they'd have it working in no time. Famous last words...
We got a 110 on the project. >:)
So yeah, pair programming rocks. It was a educational experience for both of us.
Misses the point... (Score:2, Interesting)
If you follow that path - each working on different areas - you are no longer practicing pair programming. You are just teammates working on different portions of the product.
Re:Observations (Score:3, Interesting)
Rather I would take the lead in the design, but try to leave some room for the less experienced person to contribute something. However the overall structure, I don't think it is wise to loose control over it.
Re:Observations (Score:3, Interesting)
In this case, give your partner most of the gui and you take most of the backend. That way you each learn more about the areas in which you're week.
You'll have plenty of time during your career to do the same damn thing, over and over
and over.