Pair-Programming with a Wide Gap in Talent? 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?"
Observations (Score:5, Insightful)
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.
A good opportunity (Score:2, Insightful)
navigator/driver, all the way (Score:5, Insightful)
i'm not a skilled coder at all, but i really enjoy coding with a friend of mine who is very highly skilled. when we've worked on projects together before, we use a navigator/drive method
the less-skilled team member can do the bulk of the typing, which is much more effective for learning than *watching* a more skilled perosn work; the more skilled person can be giving instructions, or working on problems that will come up later in the code
another way to say this is that the more skilled person specs the project out while the less skilled person implements it, and it all happens at about the same time
it's worked for me, but i think the dynamic that already exists between the two parties is a huge part of how well this works
New eyes! (Score:4, Insightful)
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 (Score:5, Insightful)
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:Observations (Score:5, Insightful)
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.
just let it flow (Score:4, Insightful)
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 (Score:3, Insightful)
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.
Think: Apprenticeship (Score:3, Insightful)
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)
Some Pointers (Score:4, Insightful)
Another thing, as other posters have mentioned, is that a lot of code that would be boring broiler plate stuff to you may still be an interesting challenge to your friend. Consider the 90/10 rule (10% of the code takes 90% of the time) and use it to your advantage here. As the more experienced programmer, take on the "10%" (I use quotes because it will probably vary depending on the project anywhere from 1% to 30% of the actual code) and let your friend work on the "90%". Also remember that you and your friend probably have different areas of expertise, so something that may seem difficult to you could seem obvious to her/him.
In the end, play to your respective strengths. Respect eachothers knowledge and opinions, and don't forget the insite that can come from fresh eyes. Keep things light and fun, and try to learn from eachother.
Isn't this the point? (Score:5, Insightful)
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: Think: Apprenticeship Leech (Score:2, Insightful)
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.
These responses are great! (Score:3, Insightful)
It sucks (Score:4, Insightful)
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.
Sounds like... (Score:1, Insightful)
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.
Re:Observations (Score:4, Insightful)
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."
write the tests (Score:5, Insightful)
Talent != Experience (Score:2, Insightful)
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.
Be Humble (Score:3, Insightful)
Re: Think: Apprenticeship Leech (Score:4, Insightful)
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:Did the same thing in college (Score:5, Insightful)
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.htm
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.
You must both _talk_ all the way. (Score:2, Insightful)
_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
Re:He might as well get used to the real world (Score:3, Insightful)
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: Think: Apprenticeship Leech (Score:3, Insightful)
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.
Re:Isn't this the point? (Score:1, Insightful)
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:It sucks (Score:2, Insightful)
First of all, the person in the original post CHOSE to work with a friend, but he didn't have to. So, you, as I am sure, would not pick to work with someone. Secondly, have you worked with someone who had a greater skill level than you? And did they act like it was a drag to educate you on, what they thought was the basics?
I think people who think that they are such advanced coders and cannot be bothered to be nice and explain things they know to someone who's looking for their help, are jackarses.
But, we all were there, the newbie level. We all started out someplace. It is help and encouragement and positive attitude from people around you that helps you going forward.
And thirdly, it is not know, from original post, whether the "newbie" is at the level where they don't know the basics. Considering that the person who posted is in grad school, and they are taking the same class, I would assume that the other person is also in grad school. So, the problem was the difference between the skill level, not i-am-working-for-google and you-are-just-picking-up-java-for-dummies-book
So, at that level, it is safe to say that the "newbie" person knows enough basics to not start to reinvent the wheel, as you say.
And I apologize for calling you a jackarse, it was uncalled for, even if I still think that you are.
Re:Isn't this the point? (Score:2, Insightful)
Au contraire. You show me a programmer who says he works best in pairs, and I will show you a crappy slow programmer. Real programmers hole themselves up and pull all-nighters, with a twelve pack of Mountain Dew and a steady flow of M&Ms. Socially outcast, until they emerge with a finished product. The degree of abstract thought required to do good programming is anti-social in every sense.
That's why I said every "good" programmer. Lots of dime-a-dozen code slingers may like programming in pairs. Good ones will only enter the XP program under extreme duress, and often end of scarred for life.