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.

Re:Observations

[plover]

While I agree that the design work needs to be shared, I think both of them would be better served by writing unit test cases for each other and sharing the coding.

If they develop use cases, I'd suggest leading the novice through a story or two to show him or her how it's done. Then, split off the simplest use case, and let the novice tackle it on his or her own, while the expert works on another story. (During design, it helps if the expert arranges for a couple of simple use cases for this purpose, when possible.) The expert always needs to be there for the novice, but with any motiviation the novice will pick it up.

Ownership of the code is a good motivator for some people. To that end, I'd recommend against blanket refactoring, if possible. If the code passes unit tests, (and the original design work was solid) there would be no reason unless the novice specifically said something like "I know this code isn't great, is there a better way to do this?" Then, refactoring becomes a powerful teaching tool. But if the novice doesn't ask, there's probably no harm in leaving his or her sub-optimal code in place. Let them feel the pride of accomplishment, rather than slap them down with a refactoring. To a novice, an unasked-for refactoring may seem like programmereese for "nice try rookie, but a REAL programmer does it like this."

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

New eyes!

[djsmiley]

S/he will hopefully be looking forward to this too!

s/he comes with a new pair of eyes, wide and amazed by all that stands before them. Make sure you dont "ignore" them and they will work hard for you. Just because they are less experinced doesn't mean they will work any less hard. Hell, they will hopefully work harder because they know they have a chance of producing a better project due to having someone with better skills.

I know im currently looking to do a java project, outside of uni, with a small team, so hopefully i can actually produce something which works. Currently i produce stuff that doesn't work, because for uni i can still pass with just that! :-/

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.

just let it flow

[usrusr]

i had a similar situation a while ago and to no surprise i was the one who did 95% of the coding, since both of us had the priority on "getting the job done" instead of "learning as much as possible".

still i quickly noticed how my code got better whenever i at least tried to keep a pace at which the other guy could understand most of what i did, so in the end i got into that teaching role (that always teaches yourself a lot too) without deliberately forcing me there and the other guy got more than we initially expected.

if you now deliberately let the other guy solve some of the easier problems himself (which is not "alone") then the learning result might even be close to optimal, because doing little things right will teach you more than barely finding something that might pass as a solution to a bigger problem if that means employing bad practices.

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 ); }

Some Pointers

[miyako]

I've always been a big advocate for pair programming. In my experience, two equally skilled programmers working together on a project tend to progress more quickly and produce better code. When you're working with someone who has less experience than you in the subject on which you are working, I think there is a sort of natural tendency to try to "take over". The most common way this happens that I've seen is that the less experienced programmer says "why are you doing A? wouldn't B work better?" Many times the more experienced programmer will disregard a better solution because they've been using their solution forever and a day. Remember that a less experienced clever programmer has that sort of fresh set of eyes and hasn't become clouded into thinking something is good just because it's common. Remember to use that to your mutal advantage.
Another thing, as other posters have mentioned, is that a lot of code that would be boring broiler plate stuff to you may still be an interesting challenge to your friend. Consider the 90/10 rule (10% of the code takes 90% of the time) and use it to your advantage here. As the more experienced programmer, take on the "10%" (I use quotes because it will probably vary depending on the project anywhere from 1% to 30% of the actual code) and let your friend work on the "90%". Also remember that you and your friend probably have different areas of expertise, so something that may seem difficult to you could seem obvious to her/him.
In the end, play to your respective strengths. Respect eachothers knowledge and opinions, and don't forget the insite that can come from fresh eyes. Keep things light and fun, and try to learn from eachother.

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

It sucks

[thegrassyknowl]

Writing code with someone who is majorly less skilled than you is a real drag. They tend to want to reinvent the wheel for every common programming problem instead of pulling in standard libraries. They do this for even the most simple programming constructs (like isalpha(), isnum(), etc).

That unwillingness to reuse becomes painful becase you can see the project isn't getting anywhere. Meanwhile your partner has written hundreds of lines of code to solve menial problems that libc.a or libm.a already could have solved and not actually touched on the real problem you have to solve. Of course, they think they're making splendid progress because of all this code they've written.

A lot of the unwillingness to reuse comes from being scared of something they can't see the innards to. I often heard "but the document's don't describe $OBSCURE_CASE, I'd better write my own version that handles that case too" even though they could have just tested for $OBSCURE_CASE before the function call if they thought that it might occur.

Anyway. Good luck on your project, and try as best you can to get your partner to actually work on your project, instead of reinventing the wheel. Sit down and plan the whole thing out. Break it up into manageable chunks and agree how the chunks will talk. Hand out the chunks and start coding. Keep an eye on your partner and if you see them going off on a tangent pull them back into line and show them simeple ways to do things.

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.

Re: Think: Apprenticeship Leech

[maeglin]

If I make mistakes, or allow too many novices on board, or allow a novice on board that do not happen to have a sufficient desire to learn or to perform due diligence...someone literally suffers. Somewhere someone will recieve a poor medical outcome, or fail to get a home loan, or watch their startup fail for lack of a quality tool, or labor unneccessarily in the absence of a timely product, etc.

What, you have no unit testing? No QA? That's your failure, not the novice's.

You develop freaking SOFTWARE. No more, no less.

Personally, I'd rather develop software, AND people, but maybe that's just me.

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.