Posted
by
Cliffon Wednesday March 29, 2006 @09:25PM
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?"

(I assume that you refer to the agile practice known as pair programming, and not coding as team of two people.)

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.

Okay, firstly, in full disclosure, one of the authors of this book I am discussing (recommending, even) is my PhD advisor, and the other author was a fellow graduate student when I was working on my MS. So, with that in mind.

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.

I must say that I've never experienced someone re-inventing the wheel knowingly - mostly I've seen this happen because newer coders tend to be unfamilar with basic library functionality. It all comes down to RTFM, which is a skill I am still trying to instill in my students. I think the biggest problem that new coders have is the tendency to rush write into a problem without doing research, and without a plan. The thought process goes something like this:

"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.

My lab partner was a continuing education guy from IBM who had 20 years of experience ( he had white hair ) and was earning his MS. Me, I had no industry experience at all. We had to write a program for class that played a game using AI techniques. Since a lot of dynamic programming stuff was involved, I reccomended Smalltalk ( Visualworks ). He was only familiar with C, mostly in a systems programming vein. I was wary of trying to troubleshoot pointer problems, as AI code in c can get pretty hairy.

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.

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.:D

Depends, if your goal is professional (I'm in a bit of the same situation, but within my company) I don't think it is a good idea. When a less experienced person has made a design, it may require complete replacement. It may be very disencouraging for the less experienced person to see his design bein diplomatically killed and completely replaced.

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.

My suggestion would be rather obvious, but is there anything that they are better at than you, or something you are weak on? For example, you could give your partner the GUI and you do all the back end stuff (which may be much more complex). They do programing, they help you out, they learn about the system, and you don't do it all.

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 overand over.