Follow Slashdot stories on Twitter


Forgot your password?

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?"
This discussion has been archived. No new comments can be posted.

Pair-Programming with a Wide Gap in Talent?

Comments Filter:
  • Observations (Score:5, Insightful)

    by kevin_conaway ( 585204 ) on Wednesday March 29, 2006 @09:29PM (#15022670) Homepage
    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.
  • A good opportunity (Score:2, Insightful)

    by wetfeetl33t ( 935949 ) on Wednesday March 29, 2006 @09:33PM (#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.
  • by conJunk ( 779958 ) on Wednesday March 29, 2006 @09:33PM (#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

  • New eyes! (Score:4, Insightful)

    by djsmiley ( 752149 ) <> on Wednesday March 29, 2006 @09:36PM (#15022707) Homepage Journal
    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 (Score:5, Insightful)

    by Vaevictis666 ( 680137 ) on Wednesday March 29, 2006 @09:40PM (#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:Observations (Score:5, Insightful)

    by MBCook ( 132727 ) <> on Wednesday March 29, 2006 @09:41PM (#15022732) Homepage
    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.

  • just let it flow (Score:4, Insightful)

    by usrusr ( 654450 ) on Wednesday March 29, 2006 @09:47PM (#15022764) Homepage Journal
    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 (Score:3, Insightful)

    by ShakaUVM ( 157947 ) on Wednesday March 29, 2006 @09:49PM (#15022775) Homepage Journal
    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.
  • by ivi ( 126837 ) on Wednesday March 29, 2006 @10:16PM (#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)
  • Some Pointers (Score:4, Insightful)

    by miyako ( 632510 ) <> on Wednesday March 29, 2006 @10:42PM (#15023053) Homepage Journal
    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.
  • by gstoddart ( 321705 ) on Wednesday March 29, 2006 @11:01PM (#15023147) Homepage
    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.


  • by iaminthetrunk ( 945825 ) on Wednesday March 29, 2006 @11:06PM (#15023174) Homepage
    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.

  • by bblazer ( 757395 ) * on Wednesday March 29, 2006 @11:35PM (#15023346) Homepage Journal
    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 (Score:4, Insightful)

    by thegrassyknowl ( 762218 ) on Wednesday March 29, 2006 @11:35PM (#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.
  • Sounds like... (Score:1, Insightful)

    by Anonymous Coward on Thursday March 30, 2006 @12:17AM (#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.
  • Re:Observations (Score:4, Insightful)

    by plover ( 150551 ) * on Thursday March 30, 2006 @12:25AM (#15023620) Homepage Journal
    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."

  • write the tests (Score:5, Insightful)

    by clambake ( 37702 ) on Thursday March 30, 2006 @12:50AM (#15023759) Homepage
    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.
  • by akratic ( 770961 ) on Thursday March 30, 2006 @01:33AM (#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.
  • Be Humble (Score:3, Insightful)

    by euxneks ( 516538 ) on Thursday March 30, 2006 @02:17AM (#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.
  • by maeglin ( 23145 ) on Thursday March 30, 2006 @02:31AM (#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.
  • by ThePhilips ( 752041 ) on Thursday March 30, 2006 @04:53AM (#15024701) Homepage Journal
    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. [] ) 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.
  • by dalroth5 ( 63007 ) on Thursday March 30, 2006 @10:01AM (#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 woul
  • by The Fun Guy ( 21791 ) on Thursday March 30, 2006 @10:24AM (#15025766) Homepage Journal
    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.
  • by rah1420 ( 234198 ) <> on Thursday March 30, 2006 @11:15AM (#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.
  • by Anonymous Coward on Thursday March 30, 2006 @04:58PM (#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:It sucks (Score:2, Insightful)

    by Y.T.G. ( 964304 ) on Friday March 31, 2006 @09:42AM (#15033293)
    Well, I called you a jackarse because you sound like it is such a drag to actually having to educate/help someone.
    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.
  • by blakestah ( 91866 ) <> on Friday March 31, 2006 @03:09PM (#15036010) Homepage
    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.

    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.

A committee takes root and grows, it flowers, wilts and dies, scattering the seed from which other committees will bloom. -- Parkinson