|
I fly solo, no excess baggage required.
Two heads are better than one.
|
|
|
|
|
What if u working with this hot smokin' programmer chick?  Distracted or Determine to complete the project?? 
Sir.Dre
|
|
|
|
|
Andre' Gardiner wrote: What if u working with this hot smokin' programmer chick?
Does any such thing really exist? I would love to work with one, but I have never neither seen nor heard of any... 
|
|
|
|
|
|
|
I will accept someone next to me only in game, there is a spare joystick for him. Ready 
|
|
|
|
|
Player 2: Insert coin.
"I love deadlines. I like the whooshing sound they make as they fly by." (DNA)
|
|
|
|
|
That's the worst, myself being the native C++ developer constantly cracks jokes about the managed programmer. and the managed programmer saying "it just works, just set the binding context for it!"
|
|
|
|
|
Nathan Going wrote: That's the worst, myself being the native C++ developer constantly cracks jokes about the managed programmer. and the managed programmer saying "it just works, just set the binding context for it!"
|
|
|
|
|
For me, there are two scenarios where it has worked really well in the past.
First scenario is to bring a junior developer up to speed. We got a hire fresh out of college, greener than green. Within a month or so of me and another dev pairing with him, he was up to speed and contributing nearly as much as the rest of the more senior devs. Now he's a couple years in and at a level I know I wasn't that far in, and on par with most of the devs several years his senior.
Second scenario is during a knowledge transfer when ending a contract. You can document until you're blue in the face, but until someone is digging around through the code itself they don't really know it. Pairing up really helps with this.
Outside of that, it's been less than useful. Personally, if I'm at the keyboard I'm flustered and making typos like crazy. If I'm not at the keyboard, I'm about 3 steps ahead of the person I'm working with and annoyed that it's not going faster - not that I'm better or faster than the other guy, but my mind is free to take the next steps since I'm not at the keyboard.
-----
In the land of the blind, the one eyed man is king.
|
|
|
|
|
When I have worked in or ask my team to work in pairs, code has been completed quicker, with less bugs, and it works so much better than when one person is working (and getting distracted) by themselves. It really does help focus the two people on the matter of coding and I find that the one typing can focus on the syntax and implementation details while the one viewing can focus on the overall design and direction of the code.
A couple words of caution. Both parties need to check their egos at the door. There needs to be constant switching (max 2 hours) between typing and viewing. And the typer needs to realize that the other person IS going to sound like they are overwhelming the typer with information. Once both parties realize that the typer is always going to be the slow person in the pair (not the "stupid one") then the results are amazing.
However, with smaller development teams these days, it may be difficult to get enough people on one project (or in one office) at a time to effectively utilize pair programming.
I just think that a lot of people need to open their minds to it - I have seen the benefits of it and ask my teams to form pairs when starting projects all the time (and often pair diverse people together).
Cheers
|
|
|
|
|
No means I do not do it not that I am against it.
Lack of opportunity does not mean lack of willingness.
|
|
|
|
|
Dude22 wrote: Both parties need to check their egos at the door.
You make it sound more like social engineering rather than software engineering.
The best developers do have big egos and big, inventive ideas. This system restricts it and the best developers leave to find alternative employment.
And yes, I have seen it happen. These guys like ownership of their projects. They don't want to be part of the collective. It's not farming (or the Borg).
Anyway, with more developers working from home and team sizes being restricted, I doubt that this concept will progress much further than large corporations and public services.
Hope this has gone some way to reducing your amazement.
|
|
|
|
|
sirius-black wrote: The best developers do have big egos
Bull.
Jeremy Falcon
|
|
|
|
|
It's not that we are not aware of the benefits. Most of the time I work alone. If I have a C++ problem I can ask the others, but there are things only I can do (Ada wrappers, Fortran repair, etc). When we find an area where we overlap, we can program in twos or threes and it really is so much better, quicker and more fun.
------------------<;,><-------------------
|
|
|
|
|
How many programmers does it take to program a pear. 
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
|
|
|
|
|
Bah! When I was a kid we had to make clockwork oranges!
|
|
|
|
|
Rotten oldtimer... When I was a kid, it was my job around the house to wind those damned clockwork oranges every morning before breakfast.
Will Rogers never met me.
|
|
|
|
|
I shall warn that the term is kind of confusing for non native English speakers like me specially if they aren't familiar with development methodologies. It sounds like working with someone else on a project. I doubt that, without description, results of this survey are accurate.
Anyway, to me pair programming is not worth distractions specially when interrupted at the middle of implementing an algorithm in mind.
"I hope you live a life you're proud of. If you find that you're not, I hope you have the strength to start all over again." - I wish I knew who is this quote from
modified on Monday, September 27, 2010 2:59 PM
|
|
|
|
|
Um, you are NOT confused, and you are correct in your assumption... IT DOES mean working with someone else on a project.
Hamed Mosavi wrote: is not worth distractions specially when interrupted at the middle of implementing an algorithm in mind
In reality the idea is that it is NOT considered an interruption but a collaboration where the two people work together at the same time to achieve a goal. One codes, the other helps think, design, and provide feedback.
I have done it, and at times it works well, at times it does not.
As with most 'methodologies' I don't think there is ONE answer to all problems.
If there were, we would not have as many choices as we do right now 
|
|
|
|
|
Ray Cassick wrote: IT DOES mean working with someone else on a project
Obviously I was unable to express myself clearly. Sorry. My bad. Need to work more on my speaking skills.
Normally in our team, we co-work on two different machines. We have the same source repository but we think separately. The very first time I heard the term Pair Programming, I thought it's about this type of coding in contrast to developing a whole software alone; a standalone developer. Here comes the ambiguity for some of us.
I like what is said here[^].
I've done it for one such scenario and I think it works. So yes you are absolutely correct that at times it works well. Also correct that I don't think there is ONE answer to all problems.
But honestly I think everyone does it automatically in such situations. What I am referring to as horrible is when I code and someone not understanding what I'm doing yelling at me why I'm doing it.
I agree that in a team collaboration is very important, but I believe it's better to be done at design time not coding time. Anyway it's just my opinion and your mileage might vary.
"I hope you live a life you're proud of. If you find that you're not, I hope you have the strength to start all over again."
- I wish I knew who is this quote from
|
|
|
|
|
No! Not that!
You fool! The loops DECRIMENTING! Rename that variable!
Much more fun. 
Panic, Chaos, Destruction.
My work here is done.
or "Drink. Get drunk. Fall over." - P O'H
|
|
|
|
|
... with mixed results.
Some people just can't work if someone is sitting behind them and others enjoy working together with others. If you can pair two people from the latter category, the benefits are obvious: exchange of knowledge, more focus (less time spent on CodeProject  ), no need for code reviews. Than again, most programmers fall into the former category, and forcing them to work with others will lead nowhere.
As Jim Morrison used to sing: People are Strange[^]
|
|
|
|
|
Nemanja Trifunovic wrote: Some people just can't work if someone is sitting behind them
I can not type when someone is standing next to me. Well I have way more mistakes.
John
|
|
|
|
|
John M. Drescher wrote: I can not type when someone is standing next to me. Well I have way more mistakes.
One of the brightest junior developers I ever hired was like that. I gave him a task and sat with him to help him find his way around in the code base, and he started making typos and became visibly nervous. Then I left him alone and told him to just ask if he needs any help from me, and everything went fine from that point on.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
Sound tiring just to write the sentence. 
