|
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.
|
|
|
|
|
|
Colin Angus Mackay wrote: I wouldn't want to do it every day.
I'd feel the same way. I could do it every now and then, but I know myself, it would soon get annoying. 
|
|
|
|
|
I have used it on occasion but said no as it was just for training or idea exchange.
|
|
|
|
|
Both the persons sitting at the system console should go in very amicable terms instead of resorting to debate frequently. Only then, I feel, this approach would be profitable with an optimal use of billing hours.
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
|
|
|
|
|
Vasudevan Deepak K wrote: Both the persons sitting at the system console should go in very amicable terms instead of resorting to debate frequently
It can be well laid down in an engineering book, but not among humans 
"Silence will create respect and dignity; justice and fair play will bring more friends;
benevolence and charity will enhance prestige and position; courtesy will draw benevolence;
service of mankind will secure leadership and good words will overcome powerful enemies"
Ali (Peace be upon him)
|
|
|
|
|
I found it very difficult to look for a pair on some of my hobby projects. They are the ones I enjoy but I feel quite lonely doing that with only myself.
Mind sharing suggestions on how to look for a code buddy?
|
|
|
|
|
No, never formally under this name, with all the attached rules.
Informally, often enough.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
