Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Pair-Programming with a Wide Gap in Talent? 121

Posted by Cliff
from the there-is-no-"i"-in-team dept.
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 @08: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.
    • Re:Observations (Score:5, Insightful)

      by MBCook (132727) <foobarsoft@foobarsoft.com> on Wednesday March 29, 2006 @08: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.

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

        If you follow that path - each working on different areas - you are no longer practicing pair programming. You are just teammates working on different portions of the product.

        • If you follow that path - each working on different areas - you are no longer practicing pair programming. You are just teammates working on different portions of the product.

          While I think the GP missed the point, it actually does work in a way. While you wouldn't want to be working seperately, pair programming is all about one person driving (running the keyboard and generally the main algorithm) and one person watching and commenting. By having the person most experienced with an area driving, you stil

      • "My suggestion would be rather obvious, but is there anything that they are better at than you, or something you are weak on? For example, you could give your partner the GUI and you do all the back end stuff (which may be much more complex). They do programing, they help you out, they learn about the system, and you don't do it all."

        If you're a student, then I assume you're supposed to be learning. So why not both tackle the areas you are the worst at instead of each tackling your relative strengths? If
        • Usually working in a team means learning to take advantage of the strengths and weaknesses of each team member. That's as much part of the learning experience as the project itself. Each team member doing what they are worst at wouldn't make much sense and would probably result in a low score for the entire team (just like it would out here in real life).
          • It wouldn't make sense if all you're concerned about are your grades. I went to college to learn. If I wanted it to be like it is out in the real world (where my idea would truly be absurd), then I would've gotten a job out of high school. I learned everything I could in college, which often meant tackling concepts I wasn't particularly good at. In a college setting, you'll get a lot better teamwork experience if your teammates are helping each other work with concepts that they do not understand or are
      • Both of the posts above are excellent advice, but particularly the first.
      • Re:Observations (Score:3, Interesting)

        by FacePlant (19134)
        My suggestion would be rather obvious, but is there anything that they are better at than you, or something you are weak on? For example, you could give your partner the GUI and you do all the back end stuff (which may be much more complex). They do programing, they help you out, they learn about the system, and you don't do it all.

        In this case, give your partner most of the gui and you take most of the backend. That way you each learn more about the areas in which you're week.
        You'll have plenty of time du
        • I agree completely. You'd both do both parts, each would just do more of one part than the other. This would allow you to get a lot done while still learning the stuff you are weak in though helping the other person, debugging that code, adding things, etc.
    • Agreed. You do a high level design together, let him code, then walk him through some re-factoring and clean up.
      • Re:Observations (Score:4, Insightful)

        by plover (150551) * on Wednesday March 29, 2006 @11:25PM (#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."

        • I've nothing more to add than to say "well said," plover; Nerdlings (or nerds-to-be) need delicate watering or the weeds can invade...

          - Oisin
    • Re:Observations (Score:3, Interesting)

      by Baki (72515)
      Depends, if your goal is professional (I'm in a bit of the same situation, but within my company) I don't think it is a good idea. When a less experienced person has made a design, it may require complete replacement. It may be very disencouraging for the less experienced person to see his design bein diplomatically killed and completely replaced.

      Rather I would take the lead in the design, but try to leave some room for the less experienced person to contribute something. However the overall structure, I do
  • by Marxist Hacker 42 (638312) * <seebert42@gmail.com> on Wednesday March 29, 2006 @08:30PM (#15022675) Homepage Journal
    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....
    • by ThePhilips (752041) on Thursday March 30, 2006 @03: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. http://www.catb.org/~esr/faqs/smart-questions.html [catb.org] ) If newbie stumbled on problem - probably others will stumble too. That's the good time to check why the problem was hit and what/how to amend so other newcomers will not hit the same problem. (e.g. improve/reword documentation, change variable names to better reflect what they do, improve comments, etc). Sometimes it happens newbies find problems: when you devel application for N years, you have in head some well established paths thru the programme's interface and logic. Newbies don't and they hit bugs more often since they use to explorer programme in general without any preferences yet.

      If process is set properly, newbie can enrich experienced team with modern approaches/thinking, while newbie himself can learn from team how and why things are done. If process is set wrongly - there would be always collisions - and collisions are always the sign that the process and communication in team is poor.

      As a rule of thumb, put newbies to solve new problems. That's easiest and simpliest approach. When faced with new problem - newbies and pros are somewhat equal.
  • A good opportunity (Score:2, Insightful)

    by wetfeetl33t (935949)
    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 @08: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

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

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

      (I have to mention that the second time she had become much more better than she was the first, that played a role too :)
    • the less-skilled team member can do the bulk of the typing, which is much more effective for learning than *watching* a more skilled perosn work; the more skilled person can be giving instructions, or working on problems that will come up later in the code

      I always kind of preferred it the other direction with the more experienced person at the keyboard. Unless both of you are good listeners, good typers, and in general have a very tight bond (as you and your friend likely do), progress will be slowed by

    • This is exactly what we're encouraged to do during the Practical Software Development modules at the University of Leeds. Works for me.
  • peer programming (Score:2, Informative)

    by schematix (533634) *
    There are quite a bit of things that you can do in this situation, and most of it depends on the skill differential and the type of project. If your partner is not a very good programmer, expect to be their teacher. However, you can't expect to hold their hand the whole way and help yourself or them. They will have to contribute their share in one way or another. As the more experienced programmer, you should have more control over the direction the programming starts off in. Don't leave your partner out t
  • New eyes! (Score:4, Insightful)

    by djsmiley (752149) <djsmiley2k@gmail.com> on Wednesday March 29, 2006 @08: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 @08: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:Swap out (Score:3, Informative)

      by Anml4ixoye (264762)

      Exactly what I was going to recommend. By writing the tests first, you can help drive the design as the more experienced person. But by them trying things to pass it, they learn a lot too.

      The biggest challenge is to consistantly do the simplest thing possible (not the dumbest thing).

      If you run into problems, I'd highly recommend the TDD list [yahoo.com], or you can feel free to ping me offline.

    • Like this? (Score:5, Funny)

      by woolio (927141) on Wednesday March 29, 2006 @09:24PM (#15022939) Journal
      Do as the TDD folks do - you write a test that fails, your partner makes it pass.


      So you write something like

      int Add(int a, int b)
      { return a-b; }

      int Test()
      { return Add(1,2) == 3; }

      And then your partner can make the test pass by writing:

      int Add(int a, int b)
      { return 3; }

      or if they are clever,

      int Test()
      { return 1; }

      Or with a little refactoring,

      int OldAdd(int a, int b)
      { return a-b; }

      int Add(int a, int b) /* NEW */
      { return OldAdd( a, (-1)*b ); }

      • by Anonymous Coward
        He said his partner was inexperienced, not retarded.
  • First find an old monk and a young monk...
  • just let it flow (Score:4, Insightful)

    by usrusr (654450) on Wednesday March 29, 2006 @08: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 @08: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.
    • That doesn't sound like pair programming to me; more like a small team working indpeendently. If they truly are pair programming and the less experienced one is doing the typing, he will be writing what the mentor telles him to, not some crap that will have to be rewritten later.
    • ...I have to disagree. You should never let it get that far.

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

      To force the metaphor entirely beyo
      • Agreed. The best thing is to not partner with someone with a wide gap in skill. I don't want to be teaching C to someone when writing a compiler. The best thing would be to not work with the guy.
        • Very true. Anything else is a recipe for disaster. If it's on your free time and because of your good will that you're doing it, that's fine. But when it's a project that has a deadline and some sort of grade attached to it, I stay as a far away as possible from pairing with people that I know I have to hand hold. Case in point, my friend and I are taking a cryptography course and there are several non-trivial computer assignments for a large chunk of the grade. We had the opportunity to expand our group be
  • by ivi (126837) on Wednesday March 29, 2006 @09: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)
    • 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 ea

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

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

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

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

          that I'm paid to develop software that accomplishes a purpose that betters the world. If I make mistakes, or allow too many novices on board, or allow a novice on board that do not happen to have a sufficient desire to learn or to perform due diligence...someone literally suffers. Somewhere someone will recieve a poor medical outcome, or fail to get a home loan, or watch

          • by maeglin (23145) on Thursday March 30, 2006 @01: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.
          • 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 u

  • Try this... (Score:2, Informative)

    by owlman17 (871857)
    Extreme Programming. http://www.extremeprogramming.org/ [extremeprogramming.org]
    One of its basic tenets is pair-programming: http://www.extremeprogramming.org/rules/pair.html [extremeprogramming.org]

    Of course, if your partner is way below your level, every session would end up being a tutorial, very counter-productive. In which case, he should either step-up by practicing in his spare time, or worse comes to worst, get a new partner.
    • This is one of the times I wish I had moderator points to award, as I would mark this insightful. Paired programmers of differing ability is one of the problems Extreme Programming addresses.
  • Take the time to help your partner get grounded but don't do all the work and be firm about it. In the future don't partner with friends. There is always an expectation that friends are suppose to "help" each other get good grades, which is . I partnered with 3 friends for a semester long project and it was terrible idea. I ended up doing all the work, and the got nothing out of the class.

    If the quality of the work is so poor, though, you may not have any choice but to "takeover" the project.
  • Some Pointers (Score:4, Insightful)

    by miyako (632510) <.miyako. .at. .gmail.com.> on Wednesday March 29, 2006 @09: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.
    • From the poster:
      However, while I'm far from l33t, I've several years more experience than my partner. Are there effective techniques for pair programming with a wide gap in talent?
      Equating "talent" with "experience" is going to get him into trouble... anyone that lacks talent (at whatever task) will have a tough time either understanding what a more experienced mentor is trying to get across, or they'll have a problem adopting a suggestion from a brilliant protege.
  • I would try to break the task down into smaller tasks so each of you can contribute. For example... have you partner write code that interacts with the DB while you write code to manipulate that data once *he* has retrieved it. While you are working with the data, have your partner write something that will address data presentation, report generation, stats, etc.
     
    Just break things down into smaller things and you'll both do fine :)
  • by gstoddart (321705) on Wednesday March 29, 2006 @10: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.

    Cheers

    • by chromatic (9471)
      I always thought the whole point of pair programming was to bring newbies up to speed with stuff...

      That's a benefit when it occurs, yes, but the real point of pair programming is to get two people working together on a single task to stay disciplined, to implement all of the necessary features, to produce the best possible code, and to spread the knowledge of the entire system throughout the team. It supports many of the other XP practices.

    • ...absolutely the only commodity anywhere in the world which you can give away freely to everybody you meet--and still yourself possess.
    • I'm not a huge proponent of all of the XP stuff, but the built-in test cases has always seemed a good idea. I've found things like Junit to be hugely helpful -- it's really nice to have code check your code. A co-worker just started using it because he found a real need to have his code verified after new changes/refactorings so unexpected things didn't break -- he was making changes that he didn't realize would impact other things and needed a sanity check.

      I know. We're getting off of the topic of pair

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

  • It depends on your methodology and goals.

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

    On the other hand, if
  • When you guys design it, assign specific parts to him.

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

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

    And, if after all that he chooses one way and you would have chosen another, let him "win".
  • An opinion (Score:1, Interesting)

    by Anonymous Coward
    (I assume that you refer to the agile practice known as pair programming, and not coding as team of two people.)

    Unfortunately, you aren't in a corporate scenario, where each individual's contribution to the success of the project will (in theory) be judged more or less independently and rewarded accordingly. You are in a class, and the same score for your project will be assigned to you both. That being the case, try out pair programming if the disparity in skill is not too great and your partner shows wi
  • Document my code.

    or

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

    or

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

    or finally

    Let him attempt to build the whole program first. Then 'tweak' it to make it work.
  • I was the only good programmer in my team for a little electronic robot for a class.

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

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

    In any case, I'd suggest you to assign him dedicated, controlled stuff. Like
  • by bblazer (757395) * on Wednesday March 29, 2006 @10: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 @10: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.
    • Re:It sucks (Score:2, Interesting)

      by artlogic (819675)
      I must say that I've never experienced someone re-inventing the wheel knowingly - mostly I've seen this happen because newer coders tend to be unfamilar with basic library functionality. It all comes down to RTFM, which is a skill I am still trying to instill in my students. I think the biggest problem that new coders have is the tendency to rush write into a problem without doing research, and without a plan. The thought process goes something like this:

      "I need to check if the user entered a number... o
    • A lot of the unwillingness to reuse comes from being scared of something they can't see the innards to. I often heard "but the document's don't describe $OBSCURE_CASE, I'd better write my own version that handles that case too" even though they could have just tested for $OBSCURE_CASE before the function call if they thought that it might occur.

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

    • I used to program, and I consider myself fairly decent at it. Having only seen the computer game Tetris, and in 1988 using an IBM PS/2 30 (with a MCGA and no known interface to it), I managed to hack the interface in a week or so, and in a little over a weekend I programmed a tetris game using it. I also wrote my own vector drawing program, my own ASM operating system... converted Debug to a more full=fledged assembler... and I really loved having the Borland Ref. Manual to help me use all those handy li
      • Yes, I can help. Learn a different programming language!

        Seriously. You only re-use code in C when you really, really have to, because it's so intensely painful to do, and writing libraries is difficult and tiresome. Every time you want to pass a reference around, you have to decide who's going to free() it. If you want to get in the habit of reusing other people's code, learn a language with a stronger re-use culture. You should anyway; far too much new code is written in C when there are better altern
  • Pair Programming... (Score:3, Interesting)

    by ndykman (659315) on Wednesday March 29, 2006 @11:11PM (#15023537)
    Okay, firstly, in full disclosure, one of the authors of this book I am discussing (recommending, even) is my PhD advisor, and the other author was a fellow graduate student when I was working on my MS. So, with that in mind.

    I think there is a really excellent chapter in the following book Pair Programming Illuminated [amazon.com] which discusses this. Basically, this is a teacher and student relationship in a sense. As such, you need to encourage the novice to ask questions about what you are doing (when you are driving), and to encourage the student to talk out loud about what they are thinking when they are driving. Finally, you must slow down and explain when things are tricky, and never confuse head-nodding or awed silence for understanding.

    As the expert, you do need to delegate tasks. I think it is fine to send a student off on small individual assignments on the project, and then bring it back, they can explain it to you, and you provide comments on the work. Together, you can then bring the code into the codebase. This gives the novice the sense that you don't have to watching over their shoulder all the time, and ideally, moving the code into the your project is quick and simple.

    If there is an existing code base, one of those assignment could be a simple "Present it to me" task. Learn this bit of code, and explain what purpose it has in the system, and bring me a list of questions and concerns about it. Then, after that, do a pair programming task that involves that code. The novice drives, you watch.

    The list goes on and on. One other thing is to try to get the less experienced person to take on more and more tasks. In fact, you can almost challenge that person to know more about a part of the project than you do. This is good, because you don't have to be the expert on everything, which is tiring. And more you aren't the sole expert on, the better for you. You can just bring your experience to bear when it is requested, allowing you to focus on other tasks.

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

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

  • Part of me wants to say something about proper modular design, object-orientedness, thoroughly designing interfaces then splitting up the work, blah blah blah. However, the reality is that most programming assignments are too small for full-on thorough design to be anything but an obstacle, particularly for a one (and to a lesser extent, two) person team. So, realistically, here's how I'd do it. Note that this is not an ideal, this is what I think would actually happen if I was in your situation. You star
  • Sounds like... (Score:1, Insightful)

    by Anonymous Coward
    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 mino
  • .. they type, you teach... unless this person is a complete idiot, I am sure they will have something to add. noone thinks of everything. I've found that I am really good at something and become the 'knowledgable' one when pair programming and it comes to these things, but sometimes the solution requires more than just the knowledge about the topic it sometimes requires a lack of knowledge about a topic to think about it differently and solve the issue.
  • by nizo (81281) * on Wednesday March 29, 2006 @11:34PM (#15023681) Homepage Journal
    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.
    • 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 wil
      • Wow, and I thought I was jaded when it came to programming... :-)
      • No kidding. In the Real World, you will constantly be told to work with somebody on this or that project. The boss knows damn well this is a terrible mismatch. Since you are a hard working, knowledgeable, productive employee and Bob is either lazy, stupid, incompetent or all three, the boss' idea is that, through some miracle of "setting a good example" or "crosstraining" or "peer-peer development", your good qualities will rub off on him, making him a better worker

        In the real world, you'll pretty much neve
  • write the tests (Score:5, Insightful)

    by clambake (37702) on Wednesday March 29, 2006 @11:50PM (#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.
  • Don't let them get behind in the project at all. You've got to keep them updated on what code you've done, how it works, etc. Let them ask questions and get up to speed before you move on, and maybe copious amounts of correct comments and documentation wouldn't hurt either.

    I did a very difficult programming assignment during my undergrad days, and my parter didn't pull their weight in the slightest. The only part of the project that was broke was the small part my partner did by themselves. And my partner w
  • by akratic (770961)
    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 p
  • this sound like it is an excellent way to prepare yourself for a career in the real world.
  • Be Humble (Score:3, Insightful)

    by euxneks (516538) on Thursday March 30, 2006 @01: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 Anonymous Coward on Thursday March 30, 2006 @02:08AM (#15024342)
    My lab partner was a continuing education guy from IBM who had 20 years of experience ( he had white hair ) and was earning his MS. Me, I had no industry experience at all. We had to write a program for class that played a game using AI techniques. Since a lot of dynamic programming stuff was involved, I reccomended Smalltalk ( Visualworks ). He was only familiar with C, mostly in a systems programming vein. I was wary of trying to troubleshoot pointer problems, as AI code in c can get pretty hairy.

    The kicker was, we could only really meet and work together on the weekends ( unlike everyone else who lived on campus ). He had a day job. Thus we only had 6 weekends to do it ( and I would be missing a weekend because of spring break too! ).

    So we said "Whoever can get the basic search functions working first, we'll use that language." By thursday, my framework was working, he was still fighting various pointer problems.

    "I don't smalltalk" "You know programming. It's all the same. I'll teach you the language, it's dead simple."

    Smalltalk has a very small keyword set, and very simple but powerful semantics. So I explained it to him as we typed. And even with the vast gulf between C and Smalltalk, he was able to catch some common problems, and offer some design ideas.

    Working only on weekends, we were one of the few groups to finish a working program that could play the game well. In fact, we had one weekend left.

    The last weekend before it was due, we used Visualworks UI designer ( before glade even existed ) to make a gui, hooked it into the engine, and players could then play against the computer with a nice UI. It kicked butt.

    We were the only group that finished on time, with a working game engine and working GUI. All the other groups, if their project ran at all, had a command line interface. I remember chuckling to myself at the start when one group mentioned that they were going to use C++ and MFC, and they'd have it working in no time. Famous last words... ;)

    We got a 110 on the project. >:)

    So yeah, pair programming rocks. It was a educational experience for both of us. :D
  • I hate it when people attribute gap in productivity to talent!
    I think we use the word talent to refer to our missunderstanding why someone is better than someone else in doing something.
    Ohhh, he is more talented!

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

    I believe it's the sk
    • You are committing the classic 'nature/nurture' error: It isn't 'Nature' OR 'Nurture' - it is 'Nature' AND 'Nurture'. If you don't have the talent - no amount of learning will make you the "best". Conversely, no amount of talent can overcome a fundamental lack of learned skills: Having the potential to be an Olympic athlete doesn't make you an Olympic athlete. That takes training in addition to having the innate potential.

      Someone with low talent and weak learned skills isn't a programmer.

      Someone with

  • and I do not want to do all the work

    If you're doing pair programming properly, one person can't end up doing all the work. Both people are working simultaneously - usually one is coding, focussed in on the details of the specific function and the language that you're developing in, while the other is both checking what that person is doing and keeping an eye on the bigger picture (what is the actual purpose of this function, what is the overall problem that we're trying to solve etc). If anything, you wou

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

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

    I'd try pairing with the other guy, see what your individual strengths are, and play to them.
  • I've been in this situation, but on the clueless end (I still can't program my way out of a paper bag.) I thankfully had a pretty smart partner who just "got it", and who was willing to take the lead with the problem solving.

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

    I don't know how you define "doing all the work", but he was certainly the active party. I learned a l
  • Is there some way you can split it up into two parts, one being easier than the other? I had the same issue in a class in college. I ended up writing an assembler and virtual machine for a fictional assembly language and my partner wrote some simple programs in the fictional assembly language. We got A's...
  • That's OK. It's nothing to be ashamed of.

    I often say the reason I sometimes mutter to myself is that when you find yourself in a tough spot, it's comforting to tell your problems to the smartest person around.
  • 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. Th
  • I'd say dive right in, don't hog the keyboard and make the other guy sit at your shoulder. Let him/make him do his share, and if you disagree, let him make you explain yourself. Restrain your impulse to lay down the law, and practice listening. You might find you get a lot more out of this assignment.

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

    The truth is, few of us is as good as we think we are. Or at least few of us are so good that having our ideas
  • That is how I learned to program. I learned OOP concepts (high level) and learned how to program PHP by pair programming with a friend that was far more experienced than myself. It mostly consisted of him programming and me watching. He would explain each chunk of code and why it was there and how it worked. A lot of those first sessions went right over my head, I just kept up with as much as I could. Slowly I would take over in certain sections (he could sandbox out a part of the code that was relativ
  • I had a very similar assignment, and identical concerns with my final project at school. I've programmed for years and my friend/partner didn't have as much experience as me.

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

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

    From there we split into what
  • 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

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

    Oh. Wait.

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

    In the end, we came out a
  • Sounds like this will be your first experience with how pair programming often works in the real world.

    Learning how to communicate at different levels and still produce an effective pair is your learning experience you'll take away from this, while the other guy is soaking up your programming experience.

    You'll be seeing this scenario again in the job world... think about what you can learn from it to make the next time easier.
  • Back in the day I used to get the nubies as my officemates. In three months I could convert a newly minted BS into a useful and productive coder. Rather than being critical or alarmed about their obvious lack of practical skills I made each project an adventure shrouded in mystery. Over time their abllity to show initiative and apply their budding skillsets would grow. Within a day they could navigate the general codebase. Within a week thet started their first solo projects and by the end of the three

Have you reconsidered a computer career?

Working...