Pair-Programming with a Wide Gap in Talent? 121
efp asks: "I'm a graduate student and have a programming assignment coming up. We're encouraged to work in pairs and I've agreed to work with a friend. However, while I'm far from l33t, I've several years more experience than my partner. Are there effective techniques for pair programming with a wide gap in talent? I want us both to get a lot out of the assignment, and I do not want to do all the work (which has been specifically identified and disallowed by the instructor anyway). Navigator/driver scenarios? Index-card design techniques?"
Observations (Score:5, Insightful)
It sounds like you might have to suck it up and let this be a learning experience for your partner. However, don't be closeminded. People who are less-experienced can sometimes introduce a new way of thinking or a different viewpoint that those of us who are set in our programming ways may not have thought of.
Re:Observations (Score:5, Insightful)
My suggestion would be rather obvious, but is there anything that they are better at than you, or something you are weak on? For example, you could give your partner the GUI and you do all the back end stuff (which may be much more complex). They do programing, they help you out, they learn about the system, and you don't do it all.
There are other things you can do too. Much like my parent post suggested, after you design some of the classes, skeleton them out and have your partner fill them in. Then you guys can go in and fix the bugs or improve performance as needed (there are always bugs after all). While there are always things that are going to be very tricky in the system, there are also things that are going to be relatively simple and just take time. You can give him these and work his way up from there.
Besides that, there are other things that can be done depending on what you are doing. For example, I'm not a GUI person. I can do it, but I don't like it (and my GUIs aren't that good). In my situation, I would have my partner not only design the GUI (I'd help, obviously) but implement it as much as possible. In a PHP application they can make all the pages in Dreamweaver or something I can add in the back end code (with their help). They could use a tool like X-Code, Visual Studio, or a Java tool to make the UI which you then attach the code to. They are doing difficult and very important work that way.
My parent's second point is quite important too. Let them take a crack at the design before you say "this is how you do it" because sometimes people will come up with ingenious solutions you never would have thought of.
You say this person is a good friend, and if true that's good. I assume they agree with you on the programming aspect (after all, if they think they are a better programmer then you could be in trouble). But if you two get along then you should be able to work out problems and figure this out in a reasonably balanced manner.
Misses the point... (Score:2, Interesting)
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.
Splitting Pair Programming (Score:2)
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
Re:Observations (Score:2)
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
Re:Observations (Score:2)
Re:Observations (Score:2)
Re:Observations (Score:2)
Re:Observations (Score:3, Interesting)
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
Re:Observations (Score:2)
Re:Observations (Score:2)
Re:Observations (Score:4, Insightful)
If they develop use cases, I'd suggest leading the novice through a story or two to show him or her how it's done. Then, split off the simplest use case, and let the novice tackle it on his or her own, while the expert works on another story. (During design, it helps if the expert arranges for a couple of simple use cases for this purpose, when possible.) The expert always needs to be there for the novice, but with any motiviation the novice will pick it up.
Ownership of the code is a good motivator for some people. To that end, I'd recommend against blanket refactoring, if possible. If the code passes unit tests, (and the original design work was solid) there would be no reason unless the novice specifically said something like "I know this code isn't great, is there a better way to do this?" Then, refactoring becomes a powerful teaching tool. But if the novice doesn't ask, there's probably no harm in leaving his or her sub-optimal code in place. Let them feel the pride of accomplishment, rather than slap them down with a refactoring. To a novice, an unasked-for refactoring may seem like programmereese for "nice try rookie, but a REAL programmer does it like this."
Re:Observations (Score:2)
- Oisin
Re:Observations (Score:3, Interesting)
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
Did the same thing in college (Score:3, Interesting)
Re:Did the same thing in college (Score:5, Insightful)
My personal experience. Code sharing. It's complicated as usual. There are lots of collisions. But it really helps.
It helps less experienced to learn 'how' things need to be done properly - and most importantly 'why' they are done so. (Experience is the answers to the question 'why' not 'how' as many wrongly think). Port of working code to another platform is good example of the task that could be given to newcomer. That teaches reviewing and analyzing code, and also automaticaly rookie starts picking up details of several platforms.
Also, that helps the leading programmer. Newbies - when put to task properly - start asking stupid questions. (It's very important to tell people how to ask proper questions - e.g. http://www.catb.org/~esr/faqs/smart-questions.htm
If process is set properly, newbie can enrich experienced team with modern approaches/thinking, while newbie himself can learn from team how and why things are done. If process is set wrongly - there would be always collisions - and collisions are always the sign that the process and communication in team is poor.
As a rule of thumb, put newbies to solve new problems. That's easiest and simpliest approach. When faced with new problem - newbies and pros are somewhat equal.
A good opportunity (Score:2, Insightful)
navigator/driver, all the way (Score:5, Insightful)
i'm not a skilled coder at all, but i really enjoy coding with a friend of mine who is very highly skilled. when we've worked on projects together before, we use a navigator/drive method
the less-skilled team member can do the bulk of the typing, which is much more effective for learning than *watching* a more skilled perosn work; the more skilled person can be giving instructions, or working on problems that will come up later in the code
another way to say this is that the more skilled person specs the project out while the less skilled person implements it, and it all happens at about the same time
it's worked for me, but i think the dynamic that already exists between the two parties is a huge part of how well this works
did not work for me (Score:1)
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
"much more better" (Score:1)
all work and no coffe makes muzzle unaware of the grammar
Re:"much more better" (Score:1)
Then you didn't navigate (Score:1)
So it would have been you that should have kept her clear of the design holes you got.
If you just lets a novice program alone, expect that you have to rewrite it.
Nav/driver vs Driver/nav (Score:2)
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
Re:navigator/driver, all the way (Score:2)
peer programming (Score:2, Informative)
New eyes! (Score:4, Insightful)
s/he comes with a new pair of eyes, wide and amazed by all that stands before them. Make sure you dont "ignore" them and they will work hard for you. Just because they are less experinced doesn't mean they will work any less hard. Hell, they will hopefully work harder because they know they have a chance of producing a better project due to having someone with better skills.
I know im currently looking to do a java project, outside of uni, with a small team, so hopefully i can actually produce something which works. Currently i produce stuff that doesn't work, because for uni i can still pass with just that!
Swap out (Score:5, Insightful)
The lesser-skilled one will learn from many things:
- how you approach difficult problems
- how to write tests that effectively target behaviour
- how and when to refactor effectively
- and plus you get to give feedback on his code directly - as long as you're constructive with it, it'll be a good experience.
Plus, you both will get about equal keyboard-time.Re:Swap out (Score:3, Informative)
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)
So you write something like
int Add(int a, int b)
{ return a-b; }
int Test()
{ return Add(1,2) == 3; }
And then your partner can make the test pass by writing:
int Add(int a, int b)
{ return 3; }
or if they are clever,
int Test()
{ return 1; }
Or with a little refactoring,
int OldAdd(int a, int b)
{ return a-b; }
int Add(int a, int b)
{ return OldAdd( a, (-1)*b ); }
Re:Like this? (Score:1, Funny)
Old procedure: (Score:2, Funny)
just let it flow (Score:4, Insightful)
still i quickly noticed how my code got better whenever i at least tried to keep a pace at which the other guy could understand most of what i did, so in the end i got into that teaching role (that always teaches yourself a lot too) without deliberately forcing me there and the other guy got more than we initially expected.
if you now deliberately let the other guy solve some of the easier problems himself (which is not "alone") then the learning result might even be close to optimal, because doing little things right will teach you more than barely finding something that might pass as a solution to a bigger problem if that means employing bad practices.
Sorry (Score:3, Insightful)
That said, pair programming with other people at your level can be quite good, as having two people working together keeps one or the other from getting distracted.
If you want your friend to learn something from the experience, have him do it all by himself, and then when you're done, show him the right way to do it. Or, hell, he might surprise you and you'll learn a new approach yourself. But the total man hours will be less than doing one project together.
Re:Sorry (Score:2)
Sorry again, but... (Score:1)
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
Re:Sorry again, but... (Score:2)
Re:Sorry again, but... (Score:2)
Think: Apprenticeship (Score:3, Insightful)
What better way than to round out a new / young programmer's
knowledge than to work with a more experienced colleague?
Compare & contrast notes & techniques as you go... & learn.
I don't mean to accept all that's put on the table (screen),
but to have the author right there to ask the odd question -
now & then - has to be an improvement on having the source.
Yep, as we read in a recent article on OpenBSD's attempts to
get (typically: non-Asian) hardware makers to release source
and/or info needed to write drivers, having the source alone
may not be enough for understanding, at least in such cases.
Go for it & get what you can from the experience.
PS What we need is more Pair Teaching (not only the less exp'd
teacher would gain, but so would students... more than one
perspective on the subject matter has to be a win for them)
Re: Think: Apprenticeship Leech (Score:2, Insightful)
How about the young programmer read source code from a variety of projects. Why should I bother to teach someone who can't be bothered to make that effort, or who remains fundamentally ignorant about not what to learn, but how to learn ?
How about the novice actually crack open some difficult textbooks and sandbox programming environments and really study the fundamentals. Why on ea
Re: Think: Apprenticeship Leech (Score:2)
That begs the question of whether or not they know how to learn or not.
Re: Think: Apprenticeship Leech (Score:1)
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
Re: Think: Apprenticeship Leech (Score:4, Insightful)
What, you have no unit testing? No QA? That's your failure, not the novice's.
You develop freaking SOFTWARE. No more, no less.
Personally, I'd rather develop software, AND people, but maybe that's just me.
Re: Think: Apprenticeship Leech (Score:3, Insightful)
To bring this back to the original poster, by the way, remember that it was a grad school programming project. If not that sort of project, then what? If not there, then where?
Try this... (Score:2, Informative)
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.
Re:Try this... (Score:1)
Be a Mentor (Score:2)
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)
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.
Mod parent up! (Score:2)
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.
break the task down (Score:2)
Just break things down into smaller things and you'll both do fine
Isn't this the point? (Score:5, Insightful)
I'm not a huge proponent of all of the XP stuff, but the built-in test cases has always seemed a good idea. I've found things like Junit to be hugely helpful -- it's really nice to have code check your code. A co-worker just started using it because he found a real need to have his code verified after new changes/refactorings so unexpected things didn't break -- he was making changes that he didn't realize would impact other things and needed a sanity check.
I always thought the whole point of pair programming was to bring newbies up to speed with stuff, while hopefully bringing a fresh perspective to the code. The newbie is supposed to ask questions that makes the senior coder explain, define, and defend why something is the way it is -- the best case scenario is you document some of the stuff that comes up. Ideally, the pair programming should both improve the code, and increase the sum-total of knowledge of the code in the organization.
Unless your friend is a total newb who doesn't know anything, the process should probably be beneficial to both of you.
One thing I think that XP and pair programming is to codify and entrench a culture of sharing knowledge and technologies. In my experience, those coders who want to keep their stuff l337 and 4rc4ne are crappy team players. If you're not willing to spend an hour explaining how things work to your co-workers or your QA staff/junior programmers, you're probably a liability.
I like to think that our QA staff can know that any question they have about the software is valid -- the more they understand how it was intended to work, the better they can test, and they'll never have to ask again; same for our support staff. I find it gratifying to hear them explain to someone else how it works, because it means I've done my job in educating them. I find it makes for a better QA staff, as well as better software -- and I pride myself on the fact that I've never had to explain the same thing twice. (I've had to clarify, but that was because something was complex, or I didn't fully explain it the first time.)
Same deal for newer programmers -- bring 'em up to speed, educate them, and don't treat your knowledge as something to be closely guarded, and the whole team works better. I can absolutely see how pair programming would achieve that.
What you know is the sum total of what you've seen and been told; if you think sharing with someone diminishes your value, you've totally missed the point.
So, in short, try it. If you're in a personal project, you get to teach, and improve your pet project. If you're in a professional setting, you get to teach and improve the quality of the code -- this makes you more valuable and integral to the orgnization. If what you know needs to be closely guarded to keep your edge, you probably shouldn't be doing it in the first place.
Really, what do you have to lose by trying to impart a little knowledge to someone? Even if you decide that not all tasks can be done in pairs, fine, set limits. Do it yourself, but before you commit the changes to your SCC, review them in peers and justify the changes. Pick and choose the rules of XP; they're designed to be flexible, and they already account for that.
Cheers
Re:Isn't this the point? (Score:2, Informative)
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.
Re:Isn't this the point? (Score:2, Insightful)
Au contraire. You show me a programmer who says he works best in pairs, and I will show you a crappy slow programmer. Real programmers hole themselves up and pull all-nighters, with a twelve pack of Mountain Dew and a steady flow of M&Ms. Socially outcast, until they emerge with a finished product. The degree of abstract thought required to do good program
Knowledge is... (Score:1)
Re:Knowledge is... (Score:3, Funny)
Unit Testing (Score:2)
I know. We're getting off of the topic of pair
Re:Unit Testing (Score:2)
It depends on your methodology (Score:1)
If you're just trying to ensure a smooth project...
On the other hand, if
Help them understand what they're doing (Score:1)
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)
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
Make him the technical writer (Score:2)
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.
Experience in school (Score:2)
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
In any case, I'd suggest you to assign him dedicated, controlled stuff. Like
These responses are great! (Score:3, Insightful)
It sucks (Score:4, Insightful)
That unwillingness to reuse becomes painful becase you can see the project isn't getting anywhere. Meanwhile your partner has written hundreds of lines of code to solve menial problems that libc.a or libm.a already could have solved and not actually touched on the real problem you have to solve. Of course, they think they're making splendid progress because of all this code they've written.
A lot of the unwillingness to reuse comes from being scared of something they can't see the innards to. I often heard "but the document's don't describe $OBSCURE_CASE, I'd better write my own version that handles that case too" even though they could have just tested for $OBSCURE_CASE before the function call if they thought that it might occur.
Anyway. Good luck on your project, and try as best you can to get your partner to actually work on your project, instead of reinventing the wheel. Sit down and plan the whole thing out. Break it up into manageable chunks and agree how the chunks will talk. Hand out the chunks and start coding. Keep an eye on your partner and if you see them going off on a tangent pull them back into line and show them simeple ways to do things.
Re:It sucks (Score:2, Interesting)
"I need to check if the user entered a number... o
Re:It sucks (Score:1)
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
Please reply / Maybe slightly OT for the news item (Score:2)
Learn another language (Score:2)
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
Re:It sucks (Score:2)
Now, where did I say I was a jackarse? I pointed out the fact that working with new coders is painful because they spend a lot of time reinventing the wheel instead of picking up a good reference and seeing if the wheel already exists. That means that I have to educate them on the fact that there is already a wheel and th
Re:It sucks (Score:2, Insightful)
First of all, the person in the original post CHOSE to work with a friend, but he didn't have to. So, you, as I am sure, would not pick to work with someone. Secondly, have you worked with someone who had a greater skill level than you? And did they act like it was a drag to educate you on, what they thought was the basics?
I think people who think that they are such advanced coders and cannot be
Re:It sucks (Score:2)
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?
When I was learning I picked up what I could from the books I could grab from the library. When I got a bit more advanced and started to work with other coders most of them just threw
Pair Programming... (Score:3, Interesting)
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.
Re:Pair Programming... (Score:1)
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
Write the code top-down (Score:1)
Sounds like... (Score:1, Insightful)
Personally, I have always found a good mentoring experience* to be uplifting, enlightening and beneficial. And that's working on both sides of the mentoring experience!
* a good mentoring experience is defined as being one where both parties are well-matched in competency, diligence and intelligence. The only gap should be experience, although mino
you talk .. (Score:2)
He might as well get used to the real world (Score:5, Funny)
Re:He might as well get used to the real world (Score:3, Insightful)
In fact, what will happen is that Bob wil
Re:He might as well get used to the real world (Score:2)
Re:He might as well get used to the real world (Score:2)
In the real world, you'll pretty much neve
write the tests (Score:5, Insightful)
Slow down (Score:2)
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
Talent != Experience (Score:2, Insightful)
I'm not a professional programmer, so I can't speak from experience about this kind of work. But I'd think, in general, that the way to work well with a talented but inexperienced partner is very different from the way you'd want to work with an experienced but less talented partner. If lack of experience is the reason your p
On the plus side... (Score:2, Funny)
Be Humble (Score:3, Insightful)
I did this in Grad School for a AI class once. (Score:5, Interesting)
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.
I don't believe in talent! (Score:1)
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
Re:I don't believe in talent! (Score:2)
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
All the work? (Score:2)
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
experience is talent? (Score:2)
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.
Been there... (Score:2)
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
Split it up? (Score:2)
Rather sure of yourself, are you? (Score:2)
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.
You must both _talk_ all the way. (Score:2, Insightful)
_Not_ one guy doing a rough design and then the other guy reviewing it (and maybe rewriting it).
The essence of this is _talking_. Talk about what you intend to do before you touch the keyboard. Listen to and assess your partner's replies. Answer your partner's questions. When you reach something approaching consensus, _then_ hit the keys and write some tests. Then implement. Then test. Then review. Th
Share and , um, Enjoy (Score:2)
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
It can work.. (Score:2)
I did this 4 months ago... (Score:1)
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
translation scripts are the key (Score:2, Informative)
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
Easy! (Score:2)
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
welcome to the real world (Score:2)
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.
80's Experience (Score:2)