This post is a bit of a troll but here goes. I do not see the benefits of pair programming. You have one person programming and the other just watches. Sorry, the other person interjects every now and then to make some comment and try to change the programmer''s mind. Now it may seem all hunky-dory in the ivory towers that XP was concocted in, but watching someone else program has to be the single most boring thing ever. I fall asleep frequently when I''m not programming. It is a waste of a person. I''m an intern and it pisses me off to no end to pair with someone. Why? Because I''m expected to yield the computer to the ''real'' programmer and then I just watch as they have crap like 5 classes in one source file, methods that need refactoring badly, inconsistant naming conventions, and to be asked for advice that they don''t take anyway. Its about as useless as some UML diagrams, thats for sure.

quote:Original post by antareus
This post is a bit of a troll but here goes.

a bit ?

I''ve done some pair programming with a classmate and at work. In both cases, it worked out very well. Having said that, some of the things I''ve noticed are:
- both programmers need to be approximately the same skill level otherwise someone gets bored
- pair programming for routine coding (setting up GUIs, etc) is a waste of one person''s time (at least)
- debugging as a pair seems to work REALLY well
- the quality of the programming is heavily affected by both people''s moods during any given session
- coding style needs to be similar

The biggest downside I see to pair programming is that it doesn''t double productivity so you end up taking more time than using an "interactive" programming session where the coders work side-by-side on their own work, but exchange ideas and feedback frequently. Again, this technique is entirely dependent on coder-personality and, in general, doesn''t work if any of the coders involved have more than a minimal ego.

All in all, I don''t believe many people are going to have good experiences with pair programming because most times, the pairing isn''t a good match. I keep hearing stories about junior programmers pairing with senior programmers. That''s not pair programming, that''s mentoring and to try and pass it off as pair programming just gives the whole thing a bad name. Of course, I''ve also found that most "senior" programmers (at least in mid-to-large corporations) have become complacant with their positions and have lost their edge...


Open your eyes and free your mind
That you may see the subtle wonder
Of the worlds we live in...

quote:Interesting concept, but just not practical at all.

Yes, but its the latest fad that we all have to be in on! We''re going extreme man!

quote:pair programming for routine coding (setting up GUIs, etc) is a waste of one person''s time (at least)

Thats the problem: it is not really tricky work at all, and there is no design involved.

quote:doesn''t work if any of the coders involved have more than a minimal ego

Exactly, I have a big ego.

quote:Having an intern sit around watching someone else program is not XP. It''s Fubar.

Or bullshit, call it what you want.

Sorry, my internship seems to have turned sour on me.

I''m not a professional so I don''t have much experience programming with others, but I think it works best if each person works on their own file. The file can be reviewed by others with updates/fixes made by them, but primarily a common interface is drafted together and then each person writes their own file geared towards implementing some part of it.

~CGameProgrammer( );

You can''t pair-program an intern with a developer - you''d have to pair program two interns or two developers. I wouldn''t listen to anything an intern had to say either .

Compare the time wasted during code reviews to the time wasted during pair programming. The idea is you don''t need a formal code review, nothing gets done during them, and everyone sits there and nit-picks. Then afterwards, someone has to take their notes and go fix stuff – rather inefficient. With pair-programming you’re suppose to can the formal code reviews, and the back-seat-programmer does the review online, in real-time. It takes two developers not the whole team, and problems are fixed when they are discovered.

We follow the laissez-faire policy where I work, where each developer can do just about whatever they want on their projects. Occasionally a couple of us write code together, which usually consist of me bitching about how crude someone else''s code is. We have impromptu design meetings frequently and team debug sessions once-in-a-while.

My boss considers pair-programming as a policy to be a tremendous waste of resources, though he''s not at all opposed to us working together on particular problems.

I can not work like this, every time someone looks at my back or my hands when i''m doing something, i always, i say alway mess up