|
Jeremy Falcon wrote: Wouldn't this also be annoying if the 2nd guy was a total n00b like most in the industry?
If you do this in a short session it is a great way to transfer knowledge. The idea is the least qualified implements, so the "n00b" sits at the keyboard and you, as the expert, guide them. Because they are actually doing the work and pressing the buttons they pick up the information faster than if you just sat in a meeting room and explained it for the same length of time.
At least that's how I see it working well - as a teaching/learning tool.
Jeremy Falcon wrote: Or, even if they had a clue, with constant second-guessing I don't see how this is will increase productivity
If you are both equal then I don't see it working very well. There has to be some tutor/student relationship going on with the student at the keyboard. If you are both equal in terms of overall competance, then maybe you are unequal in terms of domain knowledge.
But, like I said, this is how I see it working well because it was scenarios like that where it has worked well for me.
|
|
|
|
|
Colin Angus Mackay wrote: There has to be some tutor/student relationship going on with the student at the keyboard. If you are both equal in terms of overall competance, then maybe you are unequal in terms of domain knowledge.
Even if they are "equal" it still does not mean they can not learn from each other. IMHO, the learning aspect of the pair programming diminishes if there are always the same people working in the same pairs - it is important to "shuffle" the players once in a while 
|
|
|
|
|
Nemanja Trifunovic wrote: the learning aspect of the pair programming diminishes if there are always the same people working in the same pairs - it is important to "shuffle" the players once in a while
That's also true.
|
|
|
|
|
I and my teammate (who is my equal or maybe I'm his) commonly do this. We have too much work to do it all the time, but if one of us hits a particular problem, the other set of eyes comes in handy. Additionally, some of the tasks really can use two sets of expertise looking at them because no two people have the exact same skills. We tend to have the person whose task it is doing the work while the other looks over and provides suggestions. Once in a while, a suggestion isn't relayable, so we'll switch roles and the guy with the idea enters it in, explaining as he goes and tweaking what the other person notices along the way.
I've done this in two different situations now and both were very successful. the key is, we don't let egos get in the way. If both developers respect their counterpart and make it clear to the higher ups (in both cases, that was the company owner) that it was most definitely a team effort, it can be very successful.
I have tried this with others who wanted to either take all the credit or didn't bring any significant skills/perspectives to the table. Some success can be had with the mismatched skill sets in the teaching arena, but it actually slows down the development efforts that could have been accomplished by the senior person alone, and the egotists who want all the credit just can't be worked with as they want you to do the work yet them to get the credit.
In short (too late), equally skilled can be very successful if they are friends (or at least respect each other) first.
|
|
|
|
|
Draugnar wrote: but if one of us hits a particular problem, the other set of eyes comes in handy.
I've done that a few times myself, and it went ok. For me, I was under the impression "pair programming" was a constant thing rather the "at-times" thing to do. 40 hours a week of someone right there over my shoulder would be torture. 
|
|
|
|
|
Colin Angus Mackay wrote: as a teaching/learning tool.
In case it may be a very good idea. I was thinking along the lines of day-to-day activity.
|
|
|
|
|
No, it's not a problem unless your n00b partner doesn't know they suck and tries to lead the coding down a path you know to be wrong, without heeding your criticisms.
Back when I worked in a company in 2006 which (at the time) did TDD and almost exclusively pair-programmed, one of the other guys was a complete n00b with Java, not to mention J2EE, servlets and the frameworks we were using. It was okay because most of us were interns and decent coders to boot. Whenever I was paired with him, I encouraged him to pipe up and ask whenever he was confused, which he soon learned to do. After a few weeks, he was doing pretty well.
Apart from that, when working with the more experienced coders, it was always helpful as when one of us was tired/hungover or just not firing on all cylinders, as your partner would drag you onto your feet and catch some of your mistakes and poor design decisions. And vice versa. Also, knowledge transfer was quite effective, especially when we ventured into unknown territory.
|
|
|
|
|
I'm forced to implement this relationship on a moderately regular basis, but that is because most of the people I work with are 45+ year old engineers who are trying to do something painful like perform a sophisticated analysis with excel using macros out the ying yang. They come to me and I stand over their shoulder for hours at a time until finally I snap and take over the keyboard because they were typing at about 1/5th the speed I type when I'm simultaneously sick and have sliced up fingers that hurt to type with. After that, theirs eyes just glaze over as I end up rewriting all of their code and at the same time muttering that they should have just used a real language.
|
|
|
|
|
. . . if she were very cute, unattached, and frisky.
I would, of course, need to observe her, at first.
After the initial period we would, of course, alternate as to who was supporting who.
They should have thought of this years ago.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"How do you find out if you're unwanted if everyone you try to ask tells you to go away?" - Balboos HaGadol
|
|
|
|
|
And I'd feel sorry for any female coder that got assigned as your pair. 
|
|
|
|
|
I understand your concern - but not to worry - I'm sure we'd find someone for you, too.
On one point, however, needs to be unabigiously clarified. Only one of us is "Nature's Gift to Women" - and much as it may disappoint, it is a title you may covet - but you must content yourself with that.
"THERE CAN BE ONLY ONE!"
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"How do you find out if you're unwanted if everyone you try to ask tells you to go away?" - Balboos HaGadol
|
|
|
|
|
Balboos wrote: "THERE CAN BE ONLY ONE!"
She should be actually deciding that. Isn't it?
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
A pessimist sees only the dark side of the clouds, and mopes; a philosopher sees both sides, and shrugs; an optimist doesn't see the clouds at all - he's walking on them. --Leonard Louis Levinson
|
|
|
|
|
Were we discussing anyone other than myself, I'd agree with you 100%.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"How do you find out if you're unwanted if everyone you try to ask tells you to go away?" - Balboos HaGadol
|
|
|
|
|
... but still it never became accepted at any organization I worked at. My guess is - people want to be left alone and do the work at their own pace.
I must say however, that the benefits are huge - productivity goes up, the clarity and robustness of the code is improved as well, and transfer of knowledge comes for free.
|
|
|
|
|
This works well - you have a SQL expert and a .NET expert working together or a UI expert and a threading expert or a business expert and a techie.
Where the two employees are matched in core competence you are spending money needlessly.
Where the pair is one senior and one very junior developer you would do better to invest in training for the junior member that didn't seriously impact the productivity of the senior member.
And - there is no silver bullet - you still need to work damned hard to produce good quality software.
|
|
|
|
|
Duncan Edwards Jones wrote: Where the two employees are matched in core competence you are spending money needlessly.
In worst cases, this might lead to a bit of ego problem. You also need to see it from Human Resources perspective. This typically happens in small-sized teams.
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
A pessimist sees only the dark side of the clouds, and mopes; a philosopher sees both sides, and shrugs; an optimist doesn't see the clouds at all - he's walking on them. --Leonard Louis Levinson
|
|
|
|
|
Duncan Edwards Jones wrote: Where the pair is one senior and one very junior developer you would do better to invest in training for the junior member that didn't seriously impact the productivity of the senior member.
Exactly.
|
|
|
|
|
> Where the two employees are matched in core competence you are spending money needlessly.
I can't agree here. The benefits of pair programming are certainly not limited to disjoint competencies. Really, this was a relatively minor, albeit still very beneficial, side-effect in my experience. The major gains were the constant reality checking and constructive criticism given by your partner. Much less "am I going down the right road here?" insecurities, since you grow to trust that your partner will jump in if they disagree with your choice, or at least give helpful input when you ask. And when taking the back-seat, it's equally comforting to watch your partner proceed along a path you agree with, ready to step in when your don't understand or disagree.
I'd recommend trying a week or two (along with some ego-restraint workshops, perhaps )
|
|
|
|
|
In a dreamworld, I'm sure all the companies most of us work for would happily understand the logic of having 2 developers working on each (or at least some) coding session.
In the realworld, unfortunately, I find very few employers responsive to these kind of suggestions.
I changed job recently, and I'm finding the culture here a big improvement - iterative, agile development methods, emphasis on TDD and refactoring, with a close feedback loop with users as opposed (in my last position) to large, unfeasible upfront "design" documents (generally more a contract than a design spec). Even here, though, I see little chance of getting pair programming embraced.
The closest we got was when a new developer started and through some f*** up hadn't been assigned a machine or software licenses to use Visual Studio, so for a few days he got to look over someone's shoulder.
|
|
|
|
|
Pair programming is good for sharing knowledge and producing better design and code, but it is not so popular, IMO, due to the cost of paying two developers to do a single task!
Make it simple, as simple as possible, but not simpler.
|
|
|
|
|
I would say that development would be more than double the cost. I mean I certainly would not generate anywhere near the amount of code I do each day if I had someone sitting next to me asking me what I am thinking. And if they did not know what I was thinking it would be difficult to follow especially when I bounce back and forth between source and header files in a project that has 5,000 source files.
John
|
|
|
|
|
Pair programming is good to start with...and in some cases might help out juniors...
but building a solid company culture and knowledge base can turn out to be more efficient
Bugs are something to live with....for a while
|
|
|
|
|
Hey guyz,
I m not a professional and am still learning.. but I have tried Pair Programming and I can say.. its Fun and Productive.
This is because.. two minds are working at the same time and we both share our differnt perspective and adopt the one which is better.. and we can help each other when we are stuck in some problem.
Try it yourself 
Goodluck.
------------------------------------------------------------------
Life would have been much easier if I had the source-code!!
|
|
|
|
|
It works for short periods. It is quite an intense experience. I wouldn't want to do it every day.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
