|
I only do it if I don't remember how I do it lol
|
|
|
|
|
Someone is pair programming at work when answering this survey. Shouldn't they be allowed to vote twice?
|
|
|
|
|
but sometimes a classmate of mine, he doesn't code himself, sometimes watches over my shoulder and i explain him what i (try to) do.
he's interested but when i ask em why he doesn't give it a shot he's unresponsive.
saru mo ki kara ochiru (even monkeys fall from trees)
Usualy i'm that monkey.
If you want an intelligent answer, Don't ask me.
To understand Recursion, you must first understand Recursion.
|
|
|
|
|
Pair Programming is boon if you are into new technology. When, I started programming I did. For by fellow junior developers I'm doing it. Since, they can get into the technology pretty fast. I do advice organizations to do it for training new members. That, will help them learn the best practices in the very early stages. It will also, helps them to avoid unhealthy practices and they don't need to re-invent the wheels. But, it will be over head if you are doing it in regular process.
|
|
|
|
|
Where to vote for this survey? or is it closed? I'm pretty new here
|
|
|
|
|
|
Thanks
|
|
|
|
|
I do this once in a while when a co-worker needs assistance or brings up a code question during a meeting. In general I find the 90% of time twiddling my thumbs while the person on the keyboard is cranking out boilerplate more frustrating than the 10% that's an actual exchange of knowledge, and these are in scenarios where someone is explicitly seeking assistance, I can only imagine that the ratio would be worse in everyday coding.
3x12=36
2x12=24
1x12=12
0x12=18
|
|
|
|
|
Does any one do Explicit Hyperdiactic programming?
|
|
|
|
|
Nope - I always keep my clothes on when coding.
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
Nothing against the method, I work best alone. Luckily my employer doesn't require it (so far).
|
|
|
|
|
If I am new to domain at that time I do peer programming with other SMEs & learn about what to do. When any new programmer joins, I do peer programming to give him knowledge about the technology, domain or structure. It is very rare and depends on the requirement.
What about you?
|
|
|
|
|
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.
|
|
|
|