Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Pair-Programming with a Wide Gap in Talent?

Cliff posted more than 8 years ago | from the there-is-no-"i"-in-team dept.

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

cancel ×

121 comments

Observations (5, Insightful)

kevin_conaway (585204) | more than 8 years ago | (#15022670)

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 (4, Insightful)

MBCook (132727) | more than 8 years ago | (#15022732)

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.

Misses the point... (2, Interesting)

Captain Entendre (696145) | more than 8 years ago | (#15024389)

For example, you could give your partner the GUI and you do all the back end stuff (which may be much more complex).

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.

Splitting Pair Programming (1)

SeanDuggan (732224) | more than 7 years ago | (#15025473)

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.

While I think the GP missed the point, it actually does work in a way. While you wouldn't want to be working seperately, pair programming is all about one person driving (running the keyboard and generally the main algorithm) and one person watching and commenting. By having the person most experienced with an area driving, you still move at a decent clip, the person watching learns a fair amount by watching and listening, the watcher often catches a lot of little syntax bugs, and by being forced to give at least a running commentary of what they're doing, the driver is learning too.

I've recently had the experience of doing pair programming with someone just out of college, unfamiliar with the work we were doing and unfamiliar with the language and it still worked out. Admittedly, he hasn't driven much yet as he's still getting up to speed, but he's got a decent grasp of the architecture now and he's starting to get the language too.

Re:Splitting Pair Programming (1)

Harlequin (11000) | more than 7 years ago | (#15028628)

When I was learning PHP I worked with my boss in a pair programming environment. I found that the best way for me to learn was to drive while she gave direction and suggestions. When we got into an area where she had a definate idea of what she wanted (and I was more lost), we would switch and I would learn from her process while helping her keep things logical and in order. At other times, I would take part of the project and work on that myself. Be flexible.

I would suggest both of you talking over the design before doing anything that way you both know the direction the project is headed. Make sure your partner is comfortable asking questions like, "why do you want to do X that way". Much of the time, you'll have a good reason, but you'll probably find some of the time, you'll like your partners suggestions.

You'll both end up learning about how the other thinks and the work will be split up into individual as well as pair parts.

Re:Observations (1)

hal2814 (725639) | more than 7 years ago | (#15025465)

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

If you're a student, then I assume you're supposed to be learning. So why not both tackle the areas you are the worst at instead of each tackling your relative strengths? If your partner doesn't know much about the backend and you are weak on GUI then you do the GUI and have your partner do the backend. Then you can do th over-the-shoulder looking the parent advises and learn more in the process than you would've if you just stuck to what you each know.

Re:Observations (1)

ameline (771895) | more than 7 years ago | (#15025695)

Both of the posts above are excellent advice, but particularly the first.

Re:Observations (2, Interesting)

FacePlant (19134) | more than 7 years ago | (#15026019)

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

Re:Observations (1)

MBCook (132727) | more than 7 years ago | (#15028088)

I agree completely. You'd both do both parts, each would just do more of one part than the other. This would allow you to get a lot done while still learning the stuff you are weak in though helping the other person, debugging that code, adding things, etc.

Re:Observations (1)

theguru (70699) | more than 8 years ago | (#15022946)

Agreed. You do a high level design together, let him code, then walk him through some re-factoring and clean up.

Re:Observations (3, Insightful)

plover (150551) | more than 8 years ago | (#15023620)

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

Re:Observations (0)

Anonymous Coward | more than 8 years ago | (#15024413)

I don't think that this is a good idea. In my experience, his design will be, well, less than correct, and you'll have to change it. This will create tension, because he will have insvested a lot in the design. Furthermore, he will not be able to throw away the design, so it will be a compromise. We all know how this work.

After that, all the problem in the project will create additional tension, because:
1/ Mood will be bad
2/ Less experienced will think that the problems occurs because you should have kept his design, and the more experienced will think that the problems occurs because he had to compromise.

Don;t do that. Do the design and the unit tests. Let him do the code according to the design.

Re:Observations (2, Interesting)

Baki (72515) | more than 8 years ago | (#15024449)

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.

Did the same thing in college (2, Interesting)

Marxist Hacker 42 (638312) | more than 8 years ago | (#15022675)

I took on the role of Architect- and doled out other assignments according to the skills of the team. Mine was a three person team though....

Re:Did the same thing in college (4, Insightful)

ThePhilips (752041) | more than 8 years ago | (#15024701)

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 [catb.org] ) 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.

A good opportunity (2, Insightful)

wetfeetl33t (935949) | more than 8 years ago | (#15022687)

One of the best ways of learning/practicing something is to teach it. As the more experienced person, you have a good opportunity to help your partner, even though you yourself may not have the chance to do anything really incredible on this project. By delegating some responsibility, but at the same time being very helpful about how something shoudl be done, this can be a very good experience for both of you.

navigator/driver, all the way (4, Insightful)

conJunk (779958) | more than 8 years ago | (#15022688)

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

did not work for me (1)

mu22le (766735) | more than 8 years ago | (#15024716)

I had to work with a less expert friend of mine twice and the first time I ended up rewriting most of the bulk work she made since the design had holes that could not easily be patched.

The second time around we first agreed on the specs (and made them strict) than each one wrote its part and later we exchanged the code and looked for bugs in the other's code. It worked much better.

(I have to mention that the second time she had become much more better than she was the first, that played a role too :)

"much more better" (1)

mu22le (766735) | more than 8 years ago | (#15024735)

I actually wrote "much more better" argh!!!

all work and no coffe makes muzzle unaware of the grammar :)

Re:"much more better" (1)

Sirfrummel (873953) | more than 7 years ago | (#15026020)

Don't worry -- I always used to say "a lot more better" :-D, really, what's wrong with that anyway?

Then you didn't navigate (1)

Laz10 (708792) | more than 7 years ago | (#15025880)

If she did the driving, you should have done the navigating.
So it would have been you that should have kept her clear of the design holes you got.

If you just lets a novice program alone, expect that you have to rewrite it.

Nav/driver vs Driver/nav (1)

SeanDuggan (732224) | more than 7 years ago | (#15025524)

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

I always kind of preferred it the other direction with the more experienced person at the keyboard. Unless both of you are good listeners, good typers, and in general have a very tight bond (as you and your friend likely do), progress will be slowed by misunderstandings and errors as the person navigating suggests code and the driver types out what he thinks he hears, not what's being said. ^_^ And given programmer communication skills, sometimes the problem is that the driver is writing exactly what's said, not what's meant.

So long as the person driving at least does a running commentary on what they're doing and why, the navigator will be picking up on things as they go and by forcing the driver to explain himself and answer questions, he'll be paying all the more attention to what he's doing and why.

Re:navigator/driver, all the way (1)

David Horn (772985) | more than 7 years ago | (#15025797)

This is exactly what we're encouraged to do during the Practical Software Development modules at the University of Leeds. Works for me.

peer programming (1, Informative)

schematix (533634) | more than 8 years ago | (#15022704)

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:peer programming (0)

iaminthetrunk (945825) | more than 8 years ago | (#15023215)

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.

If your partner is not a very good programmer and you are an expert, you should delegate the instruction of the novice to a journeyman. Experts should teach journeymen, journeyman should teach novices.

Depending on your personal preferences, obviously some experts may enjoying teaching novices. But many will not. If the skill gap is too wide, it can be akward, and it is unjust to put the onus on the expert.

New eyes! (3, Insightful)

djsmiley (752149) | more than 8 years ago | (#15022707)

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 (4, Insightful)

Vaevictis666 (680137) | more than 8 years ago | (#15022728)

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.

Re:Swap out (2, Informative)

Anml4ixoye (264762) | more than 8 years ago | (#15022910)

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.

Like this? (5, Funny)

woolio (927141) | more than 8 years ago | (#15022939)

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

Re:Like this? (1, Funny)

Anonymous Coward | more than 8 years ago | (#15024994)

He said his partner was inexperienced, not retarded.

who is she? (-1, Flamebait)

Anonymous Coward | more than 8 years ago | (#15022736)

you said "my partner" instead of him or her. you're doomed if you want to fuck her.

Old procedure: (2, Funny)

hackwrench (573697) | more than 8 years ago | (#15022749)

First find an old monk and a young monk...

just let it flow (3, Insightful)

usrusr (654450) | more than 8 years ago | (#15022764)

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.

Sorry (2, Insightful)

ShakaUVM (157947) | more than 8 years ago | (#15022775)

Sorry, but what's going to happen is that as time goes by, your project will asymptotically approach 100% your code, as you replace and redesign almost everything he's written. I understand that your project can't be all done by one person, but I've been in this situation a lot of times, and so trust me -- do it all yourself and save yourself the headache of having to rewrite the entire project.

That said, pair programming with other people at your level can be quite good, as having two people working together keeps one or the other from getting distracted.

If you want your friend to learn something from the experience, have him do it all by himself, and then when you're done, show him the right way to do it. Or, hell, he might surprise you and you'll learn a new approach yourself. But the total man hours will be less than doing one project together.

Re:Sorry (1)

famebait (450028) | more than 8 years ago | (#15025042)

That doesn't sound like pair programming to me; more like a small team working indpeendently. If they truly are pair programming and the less experienced one is doing the typing, he will be writing what the mentor telles him to, not some crap that will have to be rewritten later.

Sorry again, but... (1)

dalroth5 (63007) | more than 8 years ago | (#15025343)

...I have to disagree. You should never let it get that far.

The minute your instincts tell you that you are heading towards an abyss (for example an antipattern) you should speak up and question it, pointing out that you happen to know there is a 'bridge out' just around the bend. Then you should explain your reasoning, as it may just be that your partner knows it too but intends to swerve onto a new path which _you_ don't happen to know about. None of us knows everything.

To force the metaphor entirely beyond reason: anybody who has had to rewrite a whole project either wasn't there when the car passed the forks in the road, or else was asleep in the passenger seat.

Two heads are nearly always better than one.

Think: Apprenticeship (2, Insightful)

ivi (126837) | more than 8 years ago | (#15022899)


  What better way than to round out a new / young programmer's
  knowledge than to work with a more experienced colleague?

  Compare & contrast notes & techniques as you go... & learn.

  I don't mean to accept all that's put on the table (screen),
  but to have the author right there to ask the odd question -
  now & then - has to be an improvement on having the source.

  Yep, as we read in a recent article on OpenBSD's attempts to
  get (typically: non-Asian) hardware makers to release source
  and/or info needed to write drivers, having the source alone
  may not be enough for understanding, at least in such cases.

  Go for it & get what you can from the experience.

  PS What we need is more Pair Teaching (not only the less exp'd
        teacher would gain, but so would students... more than one
        perspective on the subject matter has to be a win for them)

Re: Think: Apprenticeship Leech (2, Insightful)

iaminthetrunk (945825) | more than 8 years ago | (#15023174)

What better way than to round out a new / young programmer's knowledge than to work with a more experienced colleague?

How about the young programmer read source code from a variety of projects. Why should I bother to teach someone who can't be bothered to make that effort, or who remains fundamentally ignorant about not what to learn, but how to learn ?

How about the novice actually crack open some difficult textbooks and sandbox programming environments and really study the fundamentals. Why on earth should I teach any basic concepts broadly available in the standard literature ?

How about the novice actually study up on the domain of the work, in addition to the vanilla comp sci topics. Why should I have to cover and compensate for his lack of motivation and lack of desire to engage in domain subject matter ?

Before we advocate the merits of apprenticeship with great enthusiasm, how about we also concurrently and ruthlessly consider trading, firing, or safely sandboxing the less competant elsewhere, and replace them with sufficiently competant staff.

I'm not out to troll you, I seriously think most novices are problematic. For every ideal novice and situation you can posterchild, there are a dozen that are dysfunctional, unpleasant for the expert, or simply inefficient.

Most expert developers I've known at a variety of companies and settings have little interest in training novices. Linear to our degree of expertise, we want to execute with high competance and attention to detail on complex domain models and enterprise warehouses and highly scalable services and so forth. Novices are not welcome.

Journeymen not yet up to speed on certain project specifics or domain specifics are fine. I would submit they are usually journeymen because they actually do the things I listed above, which your novices ought to do bother bothering people. e.g. reading source code widely, exploring and practicing difficult spaces in the compsci literature, branching out to studying a non-compsci domain, signficantly contributing to an open source project, etc.

There are places for being a novice, but they include school, your own time, hobbyist open source projects, official company-sponsered training courses or free days, professional conferences, and so forth. They do not include expensive, complex, or mission critical work projects, which are, candidly, a sizable majority of work project, else they wouldn't be professional work.

I am myself a novice in new domain areas or technologies, as is any expert, but I don't inflict myself on my work collegues in those areas, or ask them to train me when I have wide resources to train myself. At minimum, I come for clarification or a quick tip at the journeyman to advanced journeyman level, and have a variety of worthwild knowledge to exchange.

Or to spin your quote another way:
What better way for the young programmer to round out his knowledge. But what a painful-to-watch, project-delaying, time-consuming, novice-code-rewriting, overtime-causing chore for the unlucky competant collegue.

I'm paid to develop software, not to teach.

Re: Think: Apprenticeship Leech (1)

rah1420 (234198) | more than 8 years ago | (#15023820)

How about the young programmer read source code from a variety of projects. Why should I bother to teach someone who can't be bothered to make that effort, or who remains fundamentally ignorant about not what to learn, but how to learn ?


That begs the question of whether or not they know how to learn or not.

How about the novice actually study up on the domain of the work, in addition to the vanilla comp sci topics. Why should I have to cover and compensate for his lack of motivation and lack of desire to engage in domain subject matter ?


That begs the question of whether they are indeed unmotivated and lack desire.

Geez Louise, you're jumping to so many conclusions here you probably wore out your new tennis shoes already.

I've been training a new person since November in my particular specialty. Beyond giving me rare insights and making me think twice and thrice about what I'm doing, the social interaction and the joy of watching them grow and develop is something that I'll treasure long after they have moved onto another group (or I have.)

Clearly you're paid to develop software.

I'm paid to develop software AND develop the next generation of people to develop software.

And whether I'm paid more than you or not, I'm a lot wealthier.

Re: Think: Apprenticeship Leech (1)

iaminthetrunk (945825) | more than 8 years ago | (#15024004)

Clearly you're paid to develop software.
I'm paid to develop software AND develop the next generation of people to develop software.

that I'm paid to develop software that accomplishes a purpose that betters the world. 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.

I'm not willing to develop the next generation of people to develop software at the expense of my end user's or the company's customers. I'm not against the obvious neccessity of novices learning, I just don't think it's appropriate on serious projects. They should cut their teeth elsewhere.

You may indeed be richer, regardless of wealth. I am not so full of hubris not to notice the validity of your critiques. As regards wealth, I can say that it is not the money that obliges me to perform, it is the obligation and the responsibility that accepting the money entails. We, as experts, are being paid exceedingly well to deliver, not to engage in pleasant social interaction. And we have an addition obligation not merely to the company that pays us, but to the users of our products and to society.

I question whether the training of novices comes at the expense of other people, and I find the likelihood that it often may, rather tragic, with due respect to the possibility that you may be in an honorable and beneficial situation. I am not persuaded your circumstance is not an outlier of good luck, nor, particularly, whether it is biased towards overlooking instances and costs of failed apprenticeships.

Re: Think: Apprenticeship Leech (3, Insightful)

maeglin (23145) | more than 8 years ago | (#15024201)

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.

Re: Think: Apprenticeship Leech (2, Insightful)

rah1420 (234198) | more than 7 years ago | (#15026082)

I'm not against the obvious neccessity of novices learning, I just don't think it's appropriate on serious projects. They should cut their teeth elsewhere.


To bring this back to the original poster, by the way, remember that it was a grad school programming project. If not that sort of project, then what? If not there, then where?

We, as experts, are being paid exceedingly well to deliver, not to engage in pleasant social interaction. And we have an addition obligation not merely to the company that pays us, but to the users of our products and to society.


Sorry, I guess we have to agree to disagree. You are paid exceedingly well to do what your employer tells you to do, no more and no less. Unless you're a sole proprietorship, that may involve doing things that cut against your grain - like training a new employee.

I did not start training this employee because I liked her (although I do, she's definitely easy on the eyes) but because our mutual manager instructed me to. Therefore, it became part of my performance assessment to make sure that she was trained adequately and to the company standards.

When you take that responsibility on, you also take the responsibility for vetting that users' work until it passes code reviews and unit tests on its own. So by that metric, you're taking on a huge responsibility to protect "society" from the inaction or poor action of the newbie programmer. And that's part of your job. If it's not, then don't do it. But if it is, then suck it up and do the best job you can, and at the end of the day you'll have a quality software project AND an employee who can help deliver more of them.

Try this... (2, Informative)

owlman17 (871857) | more than 8 years ago | (#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.

Re:Try this... (1)

allanbjork (658532) | more than 7 years ago | (#15026017)

This is one of the times I wish I had moderator points to award, as I would mark this insightful. Paired programmers of differing ability is one of the problems Extreme Programming addresses.

lol that would suck (-1, Redundant)

RLiegh (247921) | more than 8 years ago | (#15023021)

I'd hate to be suck with a bitchy know-it-all or a moronic and clueless n00b; I feel sorry for you guys!

Be a Mentor (1)

saden1 (581102) | more than 8 years ago | (#15023049)

Take the time to help your partner get grounded but don't do all the work and be firm about it. In the future don't partner with friends. There is always an expectation that friends are suppose to "help" each other get good grades, which is . I partnered with 3 friends for a semester long project and it was terrible idea. I ended up doing all the work, and the got nothing out of the class.

If the quality of the work is so poor, though, you may not have any choice but to "takeover" the project.

Re:Be a Mentor (1)

fyrie (604735) | more than 7 years ago | (#15030639)

I'd do what it takes to make sure your grade doesn't suffer, but I will stress that this is your opportunity to learn some mentoring skills which are sorely needed by most programmers.

Some Pointers (3, Insightful)

miyako (632510) | more than 8 years ago | (#15023053)

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.

Mod parent up! (1)

TigerNut (718742) | more than 7 years ago | (#15030737)

From the poster:
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?
Equating "talent" with "experience" is going to get him into trouble... anyone that lacks talent (at whatever task) will have a tough time either understanding what a more experienced mentor is trying to get across, or they'll have a problem adopting a suggestion from a brilliant protege.

break the task down (1)

mslinux (570958) | more than 8 years ago | (#15023063)

I would try to break the task down into smaller tasks so each of you can contribute. For example... have you partner write code that interacts with the DB while you write code to manipulate that data once *he* has retrieved it. While you are working with the data, have your partner write something that will address data presentation, report generation, stats, etc.
 
Just break things down into smaller things and you'll both do fine :)

Isn't this the point? (4, Insightful)

gstoddart (321705) | more than 8 years ago | (#15023147)

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

Re:Isn't this the point? (2, Informative)

chromatic (9471) | more than 8 years ago | (#15024262)

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.

Re:Isn't this the point? (1, Insightful)

Anonymous Coward | more than 7 years ago | (#15029511)


EVERY good programmer works best alone. Entering the programming frame of mind is fundamentally not a social practice. Pair programming is even worse than bringing things to the lowest common denominator. Even slower.

In the ideal, you'd love to be able to take the best of what two people have to offer, and implement it. It just doesn't work out that way horribly often.

"Let's re-factor it in pairs!!!"

Re:Isn't this the point? (1)

chromatic (9471) | more than 7 years ago | (#15030171)

EVERY good programmer works best alone.

I'm pretty sure you haven't asked EVERY good programmer whether he or she works best alone, if only because I know at least a few who claim otherwise.

Knowledge is... (1)

dalroth5 (63007) | more than 8 years ago | (#15025288)

...absolutely the only commodity anywhere in the world which you can give away freely to everybody you meet--and still yourself possess.

Re:Knowledge is... (2, Funny)

Fahrenheit 450 (765492) | more than 7 years ago | (#15025961)

Well... knowledge and herpes.

Unit Testing (1)

SeanDuggan (732224) | more than 7 years ago | (#15025815)

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 know. We're getting off of the topic of pair programming, but I've got my stump when it comes to unit testing. Unit testing is handy but it is far from a panacea and it can lead to serious problems if you're not careful. First of all, unit testing will only test what you tell it to test. If it's not covered in your tests, it's obviously not being tested. Secondly, it's tempting to run tests and then fill in the "correct" answers for the tests, but if your initial code is wrong, all of your subsequent code will be tested for the wrong values. Anyhow, useful tool, but be careful.

Re:Unit Testing (1)

gstoddart (321705) | more than 7 years ago | (#15026325)

I know. We're getting off of the topic of pair programming, but I've got my stump when it comes to unit testing. Unit testing is handy but it is far from a panacea and it can lead to serious problems if you're not careful. First of all, unit testing will only test what you tell it to test. If it's not covered in your tests, it's obviously not being tested. Secondly, it's tempting to run tests and then fill in the "correct" answers for the tests, but if your initial code is wrong, all of your subsequent code will be tested for the wrong values. Anyhow, useful tool, but be careful.

All very good points. I would certainly never claim unit testing solves all problems. It's just one more tool in the set as it were. But it certainly can have a lot of uses. The good thing about it is, if you discover bugs or untested conditions, you can always add new tests to exercise those. Then in the future, they're just automatically tested for.

Certainly, over time, unit testing can become a useful tool in sorting out some of your cases. The more tests you have, the more coverage you have. The more known boundary cases you're explicitly bashing against, the higher the likelihood you'll find the defects. I find the tests which are designed to fail (ie. they work if the API returns an error) as useful as the ones that are designed to work -- because you can verify all of your error-checking works.

One thing it can do, is if you re-do a lower level function, and break it, hopefully the unit tests will find that as soon as possible. The devil is in the details, and I'd rather have as many of the details handled automagically than have to meticulously go after everything all the time.

It's not perfect, but it can certainly help.

Cheers

It depends on your methodology (1)

Aurisor (932566) | more than 8 years ago | (#15023196)

It depends on your methodology and goals.

If you're just trying to ensure a smooth project... ...and dealing with strict OO code, I would write the class structures and high-level organizational code yourself with input from your partner. Then divvy up the implementation, taking the lion's share on yourself. ...and a writing web-based application, I would talk over the application together, write the "heavy duty" database / backend code myself, and then leave him to do the presentation.

On the other hand, if you really want your partner to get as much out of it as possible...

I would take some of the suggestions other people around here have offered. Write some tests or interfaces for the difficult code, and give him as much or little guidance as you deem helpful.

In any situation, though, I think the most important thing is that your partner has the ability to see criteria for success and test against them. If he doesn't know what he's trying to produce, he's not going to be productive. If you want to be a nice guy and expose him to the actual parameters and concepts of the assignment, good for you, but that means understanding the project fully enough to explain it simply in ADDITION to doing the gruntwork that he won't have time to do. If you just want to get this thing done as fast as possible, give him a lot of methods to implement ( foo(x,y) //takes two strings and xors x against y ) and some test data.

I was always cynical about my CS education and basically threw as much grunt work at my partners as possible and then blew through the other 80% of the project the night before just to make them nervous. YMMV depending on whether or not you are a disillusioned 18-year-old me who had no idea why he was blowing through his parents money at some academic institution when he was ready for a Real Job before he started high school.

Help them understand what they're doing (1)

Trails (629752) | more than 8 years ago | (#15023197)

When you guys design it, assign specific parts to him.

When he gets something wrong, don't redo it, don't tell him "No, do it like this", ask him why he chose that, and did he consider such and such.

Same stuff with coding; why did you do this in this fashion? Did you consider xyz? Which do you think is better? why? And don't just do it with stuff he gets worng, do it with stuff he gets right.

And, if after all that he chooses one way and you would have chosen another, let him "win".

An opinion (1, Interesting)

Anonymous Coward | more than 8 years ago | (#15023264)

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

Make him the technical writer (1)

mnmn (145599) | more than 8 years ago | (#15023306)

Document my code.

or

Just build all the required functions and classes, and let him connect the dots.

or

Let him use all kinds of compiler optimizations and build the makefiles.

or finally

Let him attempt to build the whole program first. Then 'tweak' it to make it work.

Experience in school (1)

Spy der Mann (805235) | more than 8 years ago | (#15023343)

I was the only good programmer in my team for a little electronic robot for a class.

I concentrated in doing the program.
Another guy concentrated in doing the electronics.
Another guy on assembling the robot.
And another guy on doing the interface.

Our teacher wasn't pleased, since teams were supposed to be of 3, and we were four (or something, I don't remember very well). So he asked us if someone was in charge of bringing the sodas :P

In any case, I'd suggest you to assign him dedicated, controlled stuff. Like "master-slave", where you're the master and he's the slave :P. In other words, make him do the routines. Tell him "i need a function that does this and that". So he'll keep being busy, while you can concentrate on doing the more intelligent stuff.

These responses are great! (2, Insightful)

bblazer (757395) | more than 8 years ago | (#15023346)

But not for the face value reasons. It is very refreshing to hear all of this positive feedback from the responders. Too often in our field we leave newbies out in the cold with an elitist mentality about our trade. There are people who rather than help, sit back and snicker an make fun of the mistakes the new guy makes, or of his lack of experience. All of that is certainly not helpful, and can hurt an aspiring coder. From what I read here, I would be happy to work with any of these posters.

It sucks (3, Insightful)

thegrassyknowl (762218) | more than 8 years ago | (#15023347)

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.

Re:It sucks (2, Interesting)

artlogic (819675) | more than 8 years ago | (#15023664)

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.

Re:It sucks (1)

Reemi (142518) | more than 8 years ago | (#15024636)

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.

Not completely in my opinion. By re-implementing the code, they have only 1 function call in the main part of the code. This results in cleaner and easier to read code.

Of course, the re-implementation can/should be the test you describe followed by the function call to the library routine.

This is often the most difficult thing to explain: 2 function calls just behind each other seems inefficient, but for readable code it is a must.

But... I'm not always accepting blind function calls to libraries. Our solution needs to scale, and then I mean really scale. If we don't know the internals, then we might have a problem and re-implementing is easier then extensive testing. furthermore, a function might scale in the current version, but the updated version might have a complete different behaviour.

Re:It sucks (0)

Anonymous Coward | more than 8 years ago | (#15025243)

You have the right idea, but I wouldn't use libc as an example, and my mind boggles to think of why a newbie would ever reimplement anything in libm, other than something like fabs(). (Bessel functions? Huh-what?)

Frankly, a lot of the standard ISO C library is legacy crap. If you're programming to a Unix environment, then libc also usually has tons of useful system calls, but for application-level stuff, the kind of "useful" stuff that libc contains is basically memcpy() and stdio; most of the rest is useless str*() functions that give you a buffer overflow if you look at them funny, and a few symbolic constants and types which are important for portable programming, but don't buy you anything for a typical educational assignment.

The stuff in ctype.h you mentioned is moderately useful, but I pretty much consider relying on any of the i18n/l10n support in C to be a crapshoot, as it's rarely used. This stuff is much better handled in an external library, or a completely different language altogether.

qsort() and bsearch() are interesting, but generally hard to use, as they require their inputs to be in a very specific format, which requires that you translate your data structures into something they can handle (arrays of pointers), and then translate the result back.

The C++ STL is considerably more useful for everyday programming tasks, and I find myself using the container templates very regularly. The C math library is also quite useful. Still, there are plenty of situations where you might want to replace these with better libraries, so it helps to abstract away even the standard libraries behind your own higher-level, more application-specific interfaces. As they say in the introductory CS course, you want to write your application code to provide a language appropriate to the problem.

Re:It sucks (1)

Y.T.G. (964304) | more than 7 years ago | (#15027066)

You know how some people are real jackar$es? ... Well...

Re:It sucks (1)

thegrassyknowl (762218) | more than 7 years ago | (#15030165)

Well you can imply that if you want. It is also my experience that people who resort to name calling generally have no good foundation for a counter-argument and just want to have a say.

Now, where did I say I was a jackarse? I pointed out the fact that working with new coders is painful because they spend a lot of time reinventing the wheel instead of picking up a good reference and seeing if the wheel already exists. That means that I have to educate them on the fact that there is already a wheel and there's no point making your own.

Want to argue that having to do that ad-nauseum isn't painful then feel free to come up with a well constructed argument.

Want to (by implication) call me another offensive name? Don't bother!

Pair Programming... (2, Interesting)

ndykman (659315) | more than 8 years ago | (#15023537)

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.

Re:Pair Programming... (1)

ZorroXXX (610877) | more than 7 years ago | (#15025922)

I think there is a really excellent chapter in the following book Pair Programming Illuminated which discusses this.

Indeed. From the table of contents:
Chapter 22: "My Partner a Total Loser" and Other Excess Ego Problems
Chapter 23: "My Partner Is SO Smart" and Other Too Little Ego Problems

Write the code top-down (1)

Shishberg (819760) | more than 8 years ago | (#15023557)

Part of me wants to say something about proper modular design, object-orientedness, thoroughly designing interfaces then splitting up the work, blah blah blah. However, the reality is that most programming assignments are too small for full-on thorough design to be anything but an obstacle, particularly for a one (and to a lesser extent, two) person team. So, realistically, here's how I'd do it. Note that this is not an ideal, this is what I think would actually happen if I was in your situation. You start coding first. Write the whole thing top-down, and stay at as high a level as you can while keeping it logically coherent. When you get to a lower-level chunk that you don't want to think about right now, write a stub or a FIXME, and get the other guy (I'll assume male for now) to write a function to do that. Then just keep writing, on the assumption that you will be able to plug his function in eventually. How big or small you should make the tasks depends on what you think he can do. Don't just say "here, do this" and then ignore him; give him an idea of how this task fits into the program (if it isn't obvious), let him ask you for ideas about how to do it, and be willing to claim bits back if they're too tough. On the other hand, be prepared to hand off bigger chunks if he's knocking over the stuff you gave him easily. This is based on a few assumptions about the situation - that the project, or decent-sized chunks of it, can sensibly be written top-down; that your partner will be able to handle what you give him; and that he won't argue too much about the architecture. But with some minor tweaking it can probably work. Oh, one more thing - use version control.

Sounds like... (1, Insightful)

Anonymous Coward | more than 8 years ago | (#15023572)

mentoring to me! Damnit, this is why mentoring was invented; you get the benefits of experience and uneducated (read; non-cynical) enthusiasm rolled into one team.

Personally, I have always found a good mentoring experience* to be uplifting, enlightening and beneficial. And that's working on both sides of the mentoring experience!

* a good mentoring experience is defined as being one where both parties are well-matched in competency, diligence and intelligence. The only gap should be experience, although minor gaps in competency and intelligence can be tolerated.

you talk .. (1)

josepha48 (13953) | more than 8 years ago | (#15023583)

.. they type, you teach... unless this person is a complete idiot, I am sure they will have something to add. noone thinks of everything. I've found that I am really good at something and become the 'knowledgable' one when pair programming and it comes to these things, but sometimes the solution requires more than just the knowledge about the topic it sometimes requires a lack of knowledge about a topic to think about it differently and solve the issue.

He might as well get used to the real world (4, Funny)

nizo (81281) | more than 8 years ago | (#15023681)

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.

Re:He might as well get used to the real world (2, Insightful)

The Fun Guy (21791) | more than 7 years ago | (#15025766)

No kidding. In the Real World, you will constantly be told to work with somebody on this or that project. The boss knows damn well this is a terrible mismatch. Since you are a hard working, knowledgeable, productive employee and Bob is either lazy, stupid, incompetent or all three, the boss' idea is that, through some miracle of "setting a good example" or "crosstraining" or "peer-peer development", your good qualities will rub off on him, making him a better worker.

In fact, what will happen is that Bob will blather for a while during the planning meetings, offering obvious and/or stupid suggestions that you have already thought of and/or dismissed, and making grandiose claims of how much great work you'll do together. When the time comes to actually do something, though, he will either be nowhere to be found, or he will be so "busy" with other things that he will be of no use.

You will be left to do the work of two people by yourself.

When it comes time to turn the work in, though, he will not only request, but will *demand* an equal share in the credit, since everything that was accomplished "was his idea".

These people are leeches, fleas, ticks, surviving from day to day by being carried along, sucking the lifeblood of the actual workers.

You can either accept that ticks are a part of the ecology, and everybody has to put up with them, or undertake a huge effort to rid yourself of the tick. Either way, don't expect anything useful to come from the tick - all it wants is a free ride.

Re:He might as well get used to the real world (1)

nizo (81281) | more than 7 years ago | (#15026186)

Wow, and I thought I was jaded when it came to programming... :-)

Re:He might as well get used to the real world (1)

pthisis (27352) | more than 7 years ago | (#15030604)

No kidding. In the Real World, you will constantly be told to work with somebody on this or that project. The boss knows damn well this is a terrible mismatch. Since you are a hard working, knowledgeable, productive employee and Bob is either lazy, stupid, incompetent or all three, the boss' idea is that, through some miracle of "setting a good example" or "crosstraining" or "peer-peer development", your good qualities will rub off on him, making him a better worker

In the real world, you'll pretty much never have (or get) to do hands-on pairs programming stuff with another worker, since there's generally too much work to be done even without pairing up. Pair programming is limited to hard debugging tasks or delicate core-system improvements or data transformations that really _need_ an extra set of eyeballs and can justify the costs, for most other stuff periodic consults as needed and code reviews try to take the place of pair programming.

Unlike in school, you won't be personally graded as a team either--even average non-techie bosses can tell who's working and who's slacking. And you'll never get in the situation of being tethered to an incompetent partner for a full semester--incompetents are generally let go fairly swiftly, especially because having incompetents under his command makes your boss look weak and ineffective.

Now, your group/division may be graded as a team, so the major thing to watch out for is terrible bosses. They are, thankfully, somewhat rare and usually easily replaced except in unusual situations (government or behemoth corporate jobs or extreme nepotism), and normally they can be recognized quickly enough that you can start plotting your exit strategy with plenty of time. Major warning signs are reluctance to fire bad workers, inability to cope with shifting specs and understand that timetables change when specs change, lack of some (formal or informal) employee review process, failure to reward good workers, and excessive or nonexistant meetings.

The exception is incompetent corporate leadership, in particular flawed business plans, which can be less easy to recognize (especially if you're gambling on startups or "idea" companies) and can crash down quickly.

write the tests (4, Insightful)

clambake (37702) | more than 8 years ago | (#15023759)

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.

Slow down (1)

illuminatedwax (537131) | more than 8 years ago | (#15023812)

Don't let them get behind in the project at all. You've got to keep them updated on what code you've done, how it works, etc. Let them ask questions and get up to speed before you move on, and maybe copious amounts of correct comments and documentation wouldn't hurt either.

I did a very difficult programming assignment during my undergrad days, and my parter didn't pull their weight in the slightest. The only part of the project that was broke was the small part my partner did by themselves. And my partner wasn't even worse of a coder than I was - he simply got behind and spent all his time reading the code that I had written instead of writing it himself.

Secondly, practice good programming and make sure you both have a very good image of the design of your project. If you have that to a fine enough degree (though you don't need to get as ridiculous as NASA), it will make it easier for you to spot mistakes that your partner has made (and ones that you have).

Talent != Experience (2, Insightful)

akratic (770961) | more than 8 years ago | (#15023967)

You say that you have several years more experience than your partner, but you describe the situation as a "wide gap in talent." Remember that talent and experience are not the same.

I'm not a professional programmer, so I can't speak from experience about this kind of work. But I'd think, in general, that the way to work well with a talented but inexperienced partner is very different from the way you'd want to work with an experienced but less talented partner. If lack of experience is the reason your partner can't work as effectively as you can, it's natural and in no way insulting to your partner for you to take on a mentorship role. If you and your partner are equally experienced but have a "wide gap in talent," the situation is much more delicate.

On the plus side... (2, Funny)

EZLeeAmused (869996) | more than 8 years ago | (#15024070)

this sound like it is an excellent way to prepare yourself for a career in the real world.

Be Humble (2, Insightful)

euxneks (516538) | more than 8 years ago | (#15024152)

No matter how often I've coded with people with differing levels of experience (sometimes I've been more experienced, sometimes the other way around) I find that being humble, while not entirely pleasing, gives a good experience for both parties involved no matter how l33t you are...

...becuase you'll always forget a semicolon.

I did this in Grad School for a AI class once. (5, Interesting)

Anonymous Coward | more than 8 years ago | (#15024342)

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

I don't believe in talent! (1)

systems (764012) | more than 8 years ago | (#15024403)

I hate it when people attribute gap in productivity to talent!
I think we use the word talent to refer to our missunderstanding why someone is better than someone else in doing something.
Ohhh, he is more talented!

I am not into poetry or painting, so I can't be judge of why some people paint better than other.
But programming, is something I dig into, and I wouldn't compare it to painting, ever.
To a good programmer, in my opinion, require some skills/discipline, and some education.

I believe it's the skills/discipline part that many people confuse with the so called talent.
To be a good progammer you need to be patient, you don't learn patience, but you are trained to be patient.

We went to school, and by going to school daily, even thought it sucked and we didn't learn much, we were trained the skill or discipline, and being on time, every day.
So after finishing school, going to work, even if it sucks isn't such a big deal, cause you been trained.

This is just my attempt to justify gap in productivity amongst programmer, of course there other factors, like how honest and sincere you are in general, how serious about work are you, how much do you love what you do, etc ...
I just don't like the word talent, you can't measure talent, and what you can't, measure you can't improve, if you believe it is so, then, logically you are saying that there is no hope for bad programmer, which is probably true, but for different reasons, for example, its so hard to train people some skills after they reach a certain age, etc ...

My advice for the guy asking the question here, is be a good manager, educate and motivate, and educate, and motivate ...
Lack of education might push ppl to not try their best, so by educating them, teaching your partner what you know and he don't, you will motivate him to do better, put more effort.
And I think what you want from your partner isn't really output, as much as it is effort, if talent exist, it won't affect how much effort he pus, it will affect the quality of the output.

So that's it this is what I thnk!

Coaching (0)

Anonymous Coward | more than 8 years ago | (#15024557)

A lot depends on the partner and how they want to work. I did well in one assignment starting out giving new staff skeleton code to fill in. They had the pre-commented class and method signatures and just needed to provide the implementations. As they advanced they were just given the public interface to the component as a whole and were free to implement that interface on their own. Do that with a couple of components and developers and watch with glee as the componetns come together at the end and work. You need a system that can be componentised though.

Problems come if you get a partner that resists. Coming to a team as the new one for example, even if asked by management to lead. You have to gain credibility, during which time a lot of bad code can be written. It's a fine balance.

All the work? (1)

plumby (179557) | more than 8 years ago | (#15024679)

and I do not want to do all the work

If you're doing pair programming properly, one person can't end up doing all the work. Both people are working simultaneously - usually one is coding, focussed in on the details of the specific function and the language that you're developing in, while the other is both checking what that person is doing and keeping an eye on the bigger picture (what is the actual purpose of this function, what is the overall problem that we're trying to solve etc). If anything, you would want the less experienced person spending more time (but certainly not all of the time) actually doing the coding initially as you can then be guiding him when he's going wrong, making sure that he's coding the right unit tests etc.

experience is talent? (1)

StrawberryFrog (67065) | more than 8 years ago | (#15024734)

.. more experience than my partner ... a wide gap in talent

Make up your mind: is it a talent gap or an experience gap? They're not the same thing.

I'd try pairing with the other guy, see what your individual strengths are, and play to them.

Been there... (1)

fuzzybunny (112938) | more than 8 years ago | (#15024843)

I've been in this situation, but on the clueless end (I still can't program my way out of a paper bag.) I thankfully had a pretty smart partner who just "got it", and who was willing to take the lead with the problem solving.

We did our work sitting together at his PC; he made sure to constantly ask me if I understood what he was doing, to give me smaller chunks of the problem, and to try to lead me along.

I don't know how you define "doing all the work", but he was certainly the active party. I learned a lot from our assignments, and was extremely grateful to him for leading me out of dead ends, correcting my stupid mistakes, and generally coaching me.

If your instructor frowns on this sort of thing, I question his academic seriousness; it's always been my impression that assignments and tests are as much learning experiences as lectures or studying.

I know this is sort of a blue-eyed optimal scenario, but if your partner is willing to work with you and take an active role, it's really cool for him to have someone with clue to guide him along, and would probably be good experience for you in terms of coaching and tutoring.

Split it up? (1)

jgoemat (565882) | more than 8 years ago | (#15024904)

Is there some way you can split it up into two parts, one being easier than the other? I had the same issue in a class in college. I ended up writing an assembler and virtual machine for a fictional assembly language and my partner wrote some simple programs in the fictional assembly language. We got A's...

Pile it on (0)

Anonymous Coward | more than 8 years ago | (#15025024)

There's a difference between ability and experience that most of you are missing.

I've been in this situation often:

If the other person is good , i.e. smart and well trained, you can safely get them to do 90% of the work with the odd nudge in the right direction.
Just keep pushing things at them until they choke, walk them through the hard bits and repeat. You'll be amazed how productive it can be with you providing the experience and the confidence and the "junior" doing most of the coding.

Not only that, by the time this project has finished, they'll be a lot better and capable of doing smaller projects (and maintenance of this one) on their own.
You also win, because this gives you a chance to do the architectural stuff that normally gets skipped through lack of time, quality generally improves significantly.

It's a different strategy for "placeholders" - but I'm assuming that if you are using pair programming someone probably has a clue from day one.

Cheers
BTDT.

Rather sure of yourself, are you? (1)

hey! (33014) | more than 7 years ago | (#15025617)

That's OK. It's nothing to be ashamed of.

I often say the reason I sometimes mutter to myself is that when you find yourself in a tough spot, it's comforting to tell your problems to the smartest person around.

You must both _talk_ all the way. (2, Insightful)

dalroth5 (63007) | more than 7 years ago | (#15025643)

The design should be done together. The coding should be done together. The testing should be done together.
_Not_ one guy doing a rough design and then the other guy reviewing it (and maybe rewriting it).

The essence of this is _talking_. Talk about what you intend to do before you touch the keyboard. Listen to and assess your partner's replies. Answer your partner's questions. When you reach something approaching consensus, _then_ hit the keys and write some tests. Then implement. Then test. Then review. Then move to the next bit and lather, rinse and repeat.

This will take longer--maybe much longer at first--than working alone; but the code will be vastly better and you'll be producing better code faster as you get used to the technique.

When your partner is doing the talking, follow him/her step by step and pipe up _immediately_ if you've an objection. Don't sit silently analysing one point while your partner runs on. Nobody can listen to one thing and think about another at the same time.

You might want to stay silent because you're afraid you haven't thought it through and have made a mistake. Instead, be completely open, allow yourself to make mistakes, even big ones; even often. It's OK to make a mistake; and mistakes _teach_ you things. Never forget that. Forget your pride instead. You'll become a better programmer.

If you throw yourself into this freely it might just make you into a better person as well; more open, looser, more laid back, more confident, more light-hearted. These are good things. (And guys: women are attracted to these qualities in a man. They've told me so. :)

If something occurs to you while you're typing, stop typing and talk about it. Maybe you've remembered a better way. Maybe you've thought of something new. Maybe it's just an old blind alley. Talk about it and you'll (both) find out. Pair programming is about bringing another mind into your normally internal mental conversation by vocalising.

Although pair programming is a relatively new concept it has many similarities to a development process much favoured in the Eighties: formal code inspections a la Jackson methodology.

For those who don't know: in that process a programmer, having come up with a design, called an inspection meeting _before_ touching the keyboard. (yes, I know about meetings too, but these had a purpose and _worked_). At the meeting were the programmer, a requirements analyst, a DBA, a representative of Ops and a fifth, uninvolved person who did nothing but take notes. The programmer chaired.

The programmer was required to present verbally his or her design and planned implementation. Each of the others was there to offer the view of the design from the POV of their own discipline.

No meeting was allowed to last longer than 20 minutes because being humans, none of the participants could fully focus for longer than that, and _full_ focus was required of everybody present. The last 5 minutes of every meeting was for developing a complete, written task list--for all participants--resulting from the discussion. All tasks on the list had to be at least addressed, if not completed, within a day. Any issues still outstanding at the end required a second, still more focused meeting. There could not be more than 2 meetings. There was no coffee and no doughnuts. There was no time for that.

Like all of my colleagues, I loathed the idea of formal inspections before I did one; and I still loathed them after I'd done a few. The reason? Those guys were picking holes in MY DESIGN! That was my BABY they were criticising. I hated the process; I hated them. And then later, when I saw how much better my baby became, I loved the process; I loved them. IT WORKED. Better code. MUCH better code. Code that would work in the DB. Code which met the requirements. Code that would run silently and sweetly in Ops. Code which scaled well. Code which was efficient and flexible and agile and reuseable. Code which was fast. Code which any programmer would be proud of. From that day on I adored the Jackson methodology.

IMO pair programming is like a modern day equivalent of that: and that's probably because developers today are already used to wearing multiple hats themselves: DBA, Ops, RA and so on. Pair programming also brings into play the master/apprentice scenario where the apprentice learns from the master's experience while the master learns from the apprentice's fresh and open perspective. It's a win-win if you do it right; and talking all the way is the key to it.

Thanks for your time.

Share and , um, Enjoy (1)

hey! (33014) | more than 7 years ago | (#15025645)

I'd say dive right in, don't hog the keyboard and make the other guy sit at your shoulder. Let him/make him do his share, and if you disagree, let him make you explain yourself. Restrain your impulse to lay down the law, and practice listening. You might find you get a lot more out of this assignment.

Nothing is more instructive than helping somebody else, unless it is lettting others help us.

The truth is, few of us is as good as we think we are. Or at least few of us are so good that having our ideas challenged now and then isn't healthy. Many a time I've got up with the intent of showing something to somebody else, and the very prospect of doing so gives me a new perspective.

It can work.. (1)

nege (263655) | more than 7 years ago | (#15026002)

That is how I learned to program. I learned OOP concepts (high level) and learned how to program PHP by pair programming with a friend that was far more experienced than myself. It mostly consisted of him programming and me watching. He would explain each chunk of code and why it was there and how it worked. A lot of those first sessions went right over my head, I just kept up with as much as I could. Slowly I would take over in certain sections (he could sandbox out a part of the code that was relativley easy in comparison with the project).

It can be a good way to learn, but make no mistake you will have to do most of the work. I spent a lot of time with this friend (we would stay up to 3 am consistently) but in a couple weeks I was doing a lot of routine PHP work with no problem. (Granted PHP is easy compared to, oh say Java, but since I knew NOTHING about programming prior to that it was a good leap for me).

In any project you have your three constraints: time, budget, scope. If you have less "resources" you will probably see a relative increase in time to compensate for that.

I did this 4 months ago... (1)

Tigereye81 (939199) | more than 7 years ago | (#15026598)

I had a very similar assignment, and identical concerns with my final project at school. I've programmed for years and my friend/partner didn't have as much experience as me.

We tried to split up everything evenly. We broke down the application in to "actions" and drew use case diagrams for everything so we knew everything that the app needed to do from front to back.

After diagramming that, we turned those into class diagrams and a database diagram (which he knew how to do well).

From there we split into what we knew best. He designed the entire UI and I architected the solution and created blank projects with blank method headers. This made it really easy for him to start filling in the code.

All he needed to do was look at the method signature, read the comments, and write code to accomplish that atomic class. Rince, lather, repeat.

We ended up getting an A+ in the course and he learned a lot about coding.

--TE

translation scripts are the key (2, Informative)

Rudi Cilibrasi (853775) | more than 7 years ago | (#15026948)

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]

Easy! (1)

Slime-dogg (120473) | more than 7 years ago | (#15027465)

Since your partner doesn't have as much experience, let them be on top for the first few times...

Oh. Wait.

When I first started coding, in a serious manner, I had a guy work with me on a few projects. What would end up happening is that he'd do the main design, the control classes, and the manipulation of the data structures. I got to do the more tedious details, where a mistake wasn't the end of the world... since it wasn't too involved in the actual logic of the program.

In the end, we came out alright, because my less experienced self did the majority of the harsh time-consuming things (in my case, it was the formatting of the data output), while he did the more "interesting" things, but the more experience necessary things too. What he wrote leveraged what I wrote, and glued it all together.

but job reviews are a zero sum game (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#15028899)

i don't think anyone has mentioned that job reviews are a zero sum game now at a lot of companies. Not everyone can get a great job review on a team, and the managers are under pressure to curve their reviews. when you team program, this puts performance reviews and the secret pressure managers have to not grant a great review at odds with this utopia of team programming people imagine. All of these "team" ideas are great, but companies secretly have it set up to where if your team member succeeds it DOES mean there is less for you: less raise money, less of a chance to get a great review, because one has already been handed out.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...