Pair programming - how wide spread is it?

[Wils]

Never done it formally, but I liked the idea, so I had a go.

I often pull the "lets work through it together" - not just on programming - it can be anything.

I know I'm pair working, they don't, which means I can team up with someone when I need to and get them to do what I need doing much faster than if I tried to do it myself or the typical back and forth of getting them to do something I'm dependant on.

This is not quite pair-programming in my book. I would think most people sit at someone else's workstation to review or try to problem solve together quite often. But pair-programming for me is when you always work together from the moment you arrive to the moment you leave every day of the week, except meetings etc. There are teams of 6 developers here who work in 3 pairs every day of the week, morning to home time. Very stressful situation I think.

[Wils]

It is just one of those things that will work if both people are skilled and professional.

If you have lazy slackers, politicians etc then they will probably break any method you put into place other than one which takes so much time and effort it sucks the productivity out of the more efficient people.

With two skilled professionals who are working properly you can get a lot of good mileage from this method. The code and design get automatically reviewed, it helps break down large problems and spreads system and technical knowledge around.

It does not work well if you have the kind of engineer who likes to horde knowledge. To be honest, combating this tendancy is one of the objectives of pair programming as it is bad for the team.

I agree with the advantages you mention. Though I am curious about the tendency amongst it supporters to attack the personalities of those who don't like it.

[MyUserName]

I agree with the advantages you mention. Though I am curious about the tendency amongst it supporters to attack the personalities of those who don't like it.

I would guess that the perception among those who are most keen on it is it is technically superior to working alone in everyway. Therefore if you do not want to do it then it cannot be from a professional standpoint so it must be a personal one. There a probably only a few people who actually think this way but, as usual, it is the vocal minority that get noticed.

80/20 rule again.

[russell]

It's like a unicorn or a nymphomaniac you here it mentioned but never see it for yourself.

[nomadd]

It's like a unicorn or a nymphomaniac you here it mentioned but never see it for yourself.

[jmo21]

Current clientco is a bit behind the times, and some of their senior staff recently went on an agile course.

I got extended to work on a new project with some decent new cv enhancing technologies. I'm responsible for the design and I'm also the lead developer.

Then the dev manager dropped in that thy wanted to do pair programming for the first couple of sprints, with me mentoring a permie in C#, MVC and SQL.

First time it's ever been suggested for a project I've worked on.

I was dreading it but it's actually fell by he wayside as permie has been dragged back into existing projects.

He's a designer with no coding experience and also about 15 years older than me, lovely guy, but it'd have been weird.

[VectraMan]

I was dreading it but it's actually fell by he wayside as permie has been dragged back into existing projects.

I imagine that happens a lot too. If developer A is needed on something else, someone will say "well can't developer B just do it by himself?". Plus what happens when one of the pair has holiday and the other doesn't?

[MyUserName]

I imagine that happens a lot too. If developer A is needed on something else, someone will say "well can't developer B just do it by himself?". Plus what happens when one of the pair has holiday and the other doesn't?

You are not supposed to always pair with the same person. The idea is that pairs change every day and the lead developer pairs up with someone of he is needed and does other work when he is not.

[swamp]

Pair programming is as rare as rocking horse $4it. There's a very simple reason for this. The MBA-wielding managers who have to decide upon things like staffing levels etc. will never entertain this idea for the simple reason that, if they're employing (<cough>contracting</cough>) two people, they'll want 2x the output. No manager in his right mind will have two people working together to produce the same that one person can produce.

In short, don't worry about pair programming. In the real world, it's largely non-existent.

Well I must be living in the land of rocking horses. I have been contracting and doing pair programming for many years. It was very popular when Test Driven Development was a new (and rare) skill, but these days it is largely pointless. It can make some problems a bit easier in that the other person does half of your job

[NotAllThere]

Pair programming is as rare as rocking horse $4it. There's a very simple reason for this. The MBA-wielding managers who have to decide upon things like staffing levels etc. will never entertain this idea for the simple reason that, if they're employing (<cough>contracting</cough>) two people, they'll want 2x the output. No manager in his right mind will have two people working together to produce the same that one person can produce...

The point of pair programming is that two people working together is supposed to produce more than two people working seperately. When MBA wielding manages believe this, then you'll have pair programming. The evidence is that, done properly, it is indeed synergistic.