Slashdot Mirror
Pair-Programming with a Wide Gap in Talent?
efp asks: "I'm a graduate student and have a programming assignment coming up. We're encouraged to work in pairs and I've agreed to work with a friend. However, while I'm far from l33t, I've several years more experience than my partner. Are there effective techniques for pair programming with a wide gap in talent? I want us both to get a lot out of the assignment, and I do not want to do all the work (which has been specifically identified and disallowed by the instructor anyway). Navigator/driver scenarios? Index-card design techniques?"
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.
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....
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
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.
Register the editry.
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
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!
- http://www.milkme.co.uk
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.First find an old monk and a young monk...
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.
[i have an opinion and i am not afraid to use it]
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.
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)
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)
{ return OldAdd( a, (-1)*b ); }
Extreme Programming. http://www.extremeprogramming.org/
One of its basic tenets is pair-programming: http://www.extremeprogramming.org/rules/pair.html
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.
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.
Famous Last Words: "hmm...wikipedia says it's edible"
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
Lost at C:>. Found at C.
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.
"The hottest places in Hell are reserved for those who, in times of moral crisis, preserved their neutrality." -Dante
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.
My
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.
I drink to make other people interesting!
I think there is a really excellent chapter in the following book Pair Programming Illuminated 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.
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.
I Am My Own Worst Enemy
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.
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.
this sound like it is an excellent way to prepare yourself for a career in the real world.
Some see the vessel as half full; others see it as half-empty; We pour it out on the floor and laugh
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.
in girum imus nocte et consumimur igni
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.
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.
;)
:D
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.
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.
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 woul
"We reject kings, presidents and voting. We believe in rough consensus and running code." Dave Clark, IETF
Well... knowledge and herpes.
-30-
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?
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.
Mit der Dummheit kämpfen Götter selbst vergebens.
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 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:
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