Pairing With Interns

Is it feasible to practice PairingWithInterns?

I don't know, but I think it'll be a net gain. I made the suggestion to the dev lead in my shop, who was interested enough to take it to the execs. Could this be considered a SpikeSolution to demonstrate PairProgramming to them?

(As background, we're a four-programmer department for a startup, and we're trying to transition to XP.)

My guess is:

We'll lose both pair members having experience with the codebase and problem domain. That's at least halfway an illusion anyhow.
We'll lose spreading project knowledge among the permanent employees, at least as a first-order effect.
We'll gain focus of developer attention.
We'll gain quality of code.
We'll gain experience pairing.

Still, I haven't seen any information on this practice around the wiki, and a quick Googling produced nothing substantial.

Our HR department got the position description to start shopping around the local universities today...

how did your experience turn out?

This is brand-new, in late Apr 02, so I don't know, yet. I'll report as I learn!

There is some info in the wiki and elsewhere suggesting that pairing works best with people of similar ability levels. If levels are too different, then the more-talented person tends to take over, and the less-talented person is reluctant to suggest improvements or to point out mistakes. One solution to this is to let the less-talented person "drive", while the more-talented person simply asks questions and provides hints.

See also SurprisingReverse

I don't think you're going to get very far if you assume all interns are novices. Where I worked, an intern (not me, before you quip) was given idiot tasks for three months, and he was thwarted from doing anything until he transferred to another division. In friendlier territory, he rewrote the company's core engine in two months making it smaller, faster, and more correct in the process. He's now the boss of his former boss. The word you are looking for is "novice." --anon. to protect the guilty

I'm certainly not assuming they're novices, but if they know our codebase, then we have some important security problems. If they know the real-estate business, so much the better, but we're not requiring it. --JasonCole

Even expert programmers would have to become familiar with your domain before they could begin. True. What does this have to do with interns? They're temporary, so the ramp-up time needs to pay off more quickly. There may be other implications I don't see yet.

Maybe, but XP is stable with even moderately temporary employees (say, on the scale of interns).

The biggest risk is that interns have a very high probability of being novices. Compounding this problem is that they don't have enough previous work experience to demonstrate their competence to either you (when hiring) or themselves (when estimating their own competence).

If most of your problem is domain analysis, it's not even likely that you'll need complicated computer sciency solutions either. So their lack of training maybe isn't such a hindrance.

But, high risk isn't a given. Almost everyone is valuable in some way if you treat them as valuable. Even novices can help by asking difficult questions.

The difficulty is attitude. But don't forget the PygmalionEffect. I could tell you another company where they hermetically sealed away the students they hired, who then revolted.

"Intern" is similar to "Junior Programmer," except the latter is a paid position: they are both "novice" programmers. This is not necessarily because they don't know how to program, they just may not know how to program for a given situation. I now work on a website with JasonCole. Two prior positions were very different for me. One was in accounting, where my work had better be precise. The other was manufacturing, where it had better not break. In this new situation--especially with the newer XP approach--is very different for me, so I feel somewhat like a "novice," given that I have never done this before.

Any programmer in an unfamiliar situation has something great to learn to be effective, no matter how many "CD-Order" or "books/titles/authors" apps he has had the tedium of writing. -- Graeme Martin

I'm confused. You claim any programmer may be a novice; so how does this differentiate them from interns? How does an intern differ from a junior programmer? Maybe: You don't expect they'll do any work, so you don't pay your interns. Or, you don't pay your interns, so you don't expect they'll do any work. Interns expect to be paid in knowledge. Junior programmers expect to be paid in cash. Both may or may not be "novices"

It sounds to me like you think *I* think it won't work. I think it could work real well, heck, it's my suggestion. I'm trying to tap others' experiences to compensate for the fact that *I* am the novice here at XP and pair programming. Already the SurprisingReverse and PygmalionEffect comments have kicked my head onto new paths--this helps.

Am I misunderstanding you, or is there something I said that I could try to clarify?

A more direct answer to your question 'jr programmer and intern differ how?' is:

Only two ways that I see right now. First, scope is just a couple of months. Second, their monetary profit motive is out, so their motive is probably knowledge/experience. If we don't give them knowledge/experience in a short time frame, it's a bad deal. Two months in a closet proofreading a spreadsheet is contraindicated. I think pairing may give them the most value possible.

Then again, I may be seeing what I want to, here. -- JasonCole

I think there's ViolentAgreement except over the terminology.

My point is that while students are usually novices, they aren't always. You can only find out how novice someone is after you give them a chance; you can't even ask a novice because they are novices, and thus incapable of judging themselves no matter what they say. (The arrogance of ignorance.) The trouble is that someone with ten years of experience may only have acquired the same year ten times; grey hair doesn't make an expert. You will have to apply the same techniques listed here for them as well.

Further, assuming your students are only useful as a foil for your own masterful acts of programming may indicate unconciously how you treat people generally. If you respect even your lowliest employees enough to understand them as unique individuals, then it's much more likely you treat all employees with respect. Respect doesn't mean deference, it merely means that you care enough to size up the individual individually.

When you created this page as PairingWithInterns, you really meant PairingWithNovices?. Whether or not an intern is a novice is a nearly orthogonal question, except that you will not be a good mentor if you can't see past the job title "Intern." In that case, you are just wasting both your time.

(P.S. I would never hire anyone for two months anyway; no sane internship program does this. College/university programs place for four to sixteen months. The two month placements are from business colleges; that means you can safely extend the internship to four months because the intern has no further scholastic obligations. Alternatively, you could extend the contract after this grace period has ended, possibly with pay.)

I didn't know that. Bad assumption there, 'interns, summer, a couple of months'. --jc

I concluded that an intern would be a great addition to the office, after the following story:

I wrote the BouncingBallApp to test out some graphics libraries in Ruby. Mine had faces drawn on the balls. My girlfriend thought the balls should have pig snouts instead of mouthes. I convinced her to pair with me to make the change.

There were some transformations that calculated the position of the facial features in relation to the position and radius of the face. To explain this code to her, I had to refactor the transformations into a more understandable form. Instead of just drawing the mouth, I split the mouth drawing code into a Mouth object. Once the code was well factored, a. she understood what it did and b. it was easier for me to make the change. Even though she had no programming experience, the process of pairing pushed me/us to write better code.

I realized a benefit of pairing:

That the "novice" person can serve as a proxy for the programmer after s/he has moved on and forgotten the code.

Since even a non programmer pushed me to write cleaner code, I concluded that an intern would provide me with at least some value that would improve my productivity. Since you are paying an intern nothing, this is a no brainer business decision. Also, if what is valuable about the intern is their lack of experience it's not a problem if they move on :-)

That sounds like what I remember from when my dad would sit and watch over my shoulder. Every few minutes I'd get "what are you trying to do?" or "why doesn't it work?" Striving to explain it really stretched me to simplify, but alas, I loved complexity too much and could usually codge it all up again in a few hours --JasonCole

Pairing with an intern/novice helps you AvoidCleverCode?. If the intern can't understand it (assuming e is fluent with the language), it's probably too clever to maintain.

'There is some info in the wiki and elsewhere suggesting that pairing works best with people of similar ability levels.'

Do you know page names or links that support the 'equal abilities pair best' idea? I confess all I've found so far is indirect "it's said" statements. Of course, how many pages on this wiki? I've read a couple hundred, so far. --jc

'When you created this page as PairingWithInterns, you really meant PairingWithNovices?.'

Actually, I did mean PairingWithInterns--that's what we'll be doing. The wiki mentions plenty about novice pairing--I haven't assimilated it all, yet, but I didn't feel a lack of info.

On the other hand, I admit I wasn't thinking much about PairingWithNovices? as a distinct question. The attributes are indeed orthogonal.

Hmm. I expect even if they're ProgrammingNovices? it won't be a large problem--I think what may be more of a hurdle for us is if they're (as seems likely) BusinessWorldProjectNovices?... There's a chasm between the classroom and the biz world, in many ways. How work arrives, how solid it is... Hmm. Expectations may trip us up, there.

This is how Monica L. got into trouble... Wasn't that CouplingWithInterns??

CategoryPairProgramming