Pair-Programming with a Wide Gap in Talent?

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

Comments

Observations

[kevin_conaway]

Since you feel that you have more experience, why don't you let your partner take a first crack at the design? Afterwards, you can work with the design to refine it and give it the benefit of your "years of experience"

It sounds like you might have to suck it up and let this be a learning experience for your partner. However, don't be closeminded. People who are less-experienced can sometimes introduce a new way of thinking or a different viewpoint that those of us who are set in our programming ways may not have thought of.

Re:Observations

[MBCook]

Sounds like an excellent idea to me. You can teach them some that way.

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.

There are other things you can do too. Much like my parent post suggested, after you design some of the classes, skeleton them out and have your partner fill them in. Then you guys can go in and fix the bugs or improve performance as needed (there are always bugs after all). While there are always things that are going to be very tricky in the system, there are also things that are going to be relatively simple and just take time. You can give him these and work his way up from there.

Besides that, there are other things that can be done depending on what you are doing. For example, I'm not a GUI person. I can do it, but I don't like it (and my GUIs aren't that good). In my situation, I would have my partner not only design the GUI (I'd help, obviously) but implement it as much as possible. In a PHP application they can make all the pages in Dreamweaver or something I can add in the back end code (with their help). They could use a tool like X-Code, Visual Studio, or a Java tool to make the UI which you then attach the code to. They are doing difficult and very important work that way.

My parent's second point is quite important too. Let them take a crack at the design before you say "this is how you do it" because sometimes people will come up with ingenious solutions you never would have thought of.

You say this person is a good friend, and if true that's good. I assume they agree with you on the programming aspect (after all, if they think they are a better programmer then you could be in trouble). But if you two get along then you should be able to work out problems and figure this out in a reasonably balanced manner.

navigator/driver, all the way

[conJunk]

i'm not a skilled coder at all, but i really enjoy coding with a friend of mine who is very highly skilled. when we've worked on projects together before, we use a navigator/drive method

the less-skilled team member can do the bulk of the typing, which is much more effective for learning than *watching* a more skilled perosn work; the more skilled person can be giving instructions, or working on problems that will come up later in the code

another way to say this is that the more skilled person specs the project out while the less skilled person implements it, and it all happens at about the same time

it's worked for me, but i think the dynamic that already exists between the two parties is a huge part of how well this works

Swap out

[Vaevictis666]

Do as the TDD folks do - you write a test that fails, your partner makes it pass. They write a test, and you make it pass. Whenever either of you feels like it, after you've made your test pass, take an opportunity to refactor something (or make your partner refactor it) to improve on the design.

The lesser-skilled one will learn from many things:

• how you approach difficult problems
• how to write tests that effectively target behaviour
• how and when to refactor effectively
• and plus you get to give feedback on his code directly - as long as you're constructive with it, it'll be a good experience.

Plus, you both will get about equal keyboard-time.

Like this?

[woolio]

Do as the TDD folks do - you write a test that fails, your partner makes it pass.

So you write something like

int Add(int a, int b)
{ return a-b; }

int Test()
{ return Add(1,2) == 3; }

And then your partner can make the test pass by writing:

int Add(int a, int b)
{ return 3; }

or if they are clever,

int Test()
{ return 1; }

Or with a little refactoring,

int OldAdd(int a, int b)
{ return a-b; }

int Add(int a, int b) /* NEW */
{ return OldAdd( a, (-1)*b ); }

Isn't this the point?

[gstoddart]

I thought the skillz gap was the point of pairs programming.

I'm not a huge proponent of all of the XP stuff, but the built-in test cases has always seemed a good idea. I've found things like Junit to be hugely helpful -- it's really nice to have code check your code. A co-worker just started using it because he found a real need to have his code verified after new changes/refactorings so unexpected things didn't break -- he was making changes that he didn't realize would impact other things and needed a sanity check.

I always thought the whole point of pair programming was to bring newbies up to speed with stuff, while hopefully bringing a fresh perspective to the code. The newbie is supposed to ask questions that makes the senior coder explain, define, and defend why something is the way it is -- the best case scenario is you document some of the stuff that comes up. Ideally, the pair programming should both improve the code, and increase the sum-total of knowledge of the code in the organization.

Unless your friend is a total newb who doesn't know anything, the process should probably be beneficial to both of you.

One thing I think that XP and pair programming is to codify and entrench a culture of sharing knowledge and technologies. In my experience, those coders who want to keep their stuff l337 and 4rc4ne are crappy team players. If you're not willing to spend an hour explaining how things work to your co-workers or your QA staff/junior programmers, you're probably a liability.

I like to think that our QA staff can know that any question they have about the software is valid -- the more they understand how it was intended to work, the better they can test, and they'll never have to ask again; same for our support staff. I find it gratifying to hear them explain to someone else how it works, because it means I've done my job in educating them. I find it makes for a better QA staff, as well as better software -- and I pride myself on the fact that I've never had to explain the same thing twice. (I've had to clarify, but that was because something was complex, or I didn't fully explain it the first time.)

Same deal for newer programmers -- bring 'em up to speed, educate them, and don't treat your knowledge as something to be closely guarded, and the whole team works better. I can absolutely see how pair programming would achieve that.

What you know is the sum total of what you've seen and been told; if you think sharing with someone diminishes your value, you've totally missed the point.

So, in short, try it. If you're in a personal project, you get to teach, and improve your pet project. If you're in a professional setting, you get to teach and improve the quality of the code -- this makes you more valuable and integral to the orgnization. If what you know needs to be closely guarded to keep your edge, you probably shouldn't be doing it in the first place.

Really, what do you have to lose by trying to impart a little knowledge to someone? Even if you decide that not all tasks can be done in pairs, fine, set limits. Do it yourself, but before you commit the changes to your SCC, review them in peers and justify the changes. Pick and choose the rules of XP; they're designed to be flexible, and they already account for that.

Cheers

He might as well get used to the real world

[nizo]

Read the first few lines describing the assignment. Wait until two days before the assignment is due, and then he can get the donuts and coffee while you pull a few all nighters to finish the project. Get a friend to pretend to be your boss. Your friend should stand over your shoulder, asking if you are done yet, and read the rest of the assignment to you as you program, adding and subtracting requirements at random.

write the tests

[clambake]

In these situations, one of the best things you can do is write failing tests that he can implement. You have more experience, so you should set the tone and teh goals. Write the tests that you want to creat such that, when passing, will not only get the job done, but teach him something in the processess. Keep them small and instructive.

I did this in Grad School for a AI class once.

[Anonymous Coward]

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.

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

Re:Did the same thing in college

[ThePhilips]

I tried that on couple of occasions. But such approach tends to confine less experienced to your vision. That's not nesecary good.

My personal experience. Code sharing. It's complicated as usual. There are lots of collisions. But it really helps.

It helps less experienced to learn 'how' things need to be done properly - and most importantly 'why' they are done so. (Experience is the answers to the question 'why' not 'how' as many wrongly think). Port of working code to another platform is good example of the task that could be given to newcomer. That teaches reviewing and analyzing code, and also automaticaly rookie starts picking up details of several platforms.

Also, that helps the leading programmer. Newbies - when put to task properly - start asking stupid questions. (It's very important to tell people how to ask proper questions - e.g. http://www.catb.org/~esr/faqs/smart-questions.html ) If newbie stumbled on problem - probably others will stumble too. That's the good time to check why the problem was hit and what/how to amend so other newcomers will not hit the same problem. (e.g. improve/reword documentation, change variable names to better reflect what they do, improve comments, etc). Sometimes it happens newbies find problems: when you devel application for N years, you have in head some well established paths thru the programme's interface and logic. Newbies don't and they hit bugs more often since they use to explorer programme in general without any preferences yet.

If process is set properly, newbie can enrich experienced team with modern approaches/thinking, while newbie himself can learn from team how and why things are done. If process is set wrongly - there would be always collisions - and collisions are always the sign that the process and communication in team is poor.

As a rule of thumb, put newbies to solve new problems. That's easiest and simpliest approach. When faced with new problem - newbies and pros are somewhat equal.