Pair programming - how wide spread is it?

[nomadd]

The point of pair programming is that two people working together is supposed to produce more than two people working seperately.

And that that work will be of higher quality (the two heads are better than one syndrome.)

Pair-programming also, if you rotate the pairs, leads to a spread of knowledge throughout the whole team. This is a much better approach than having insular, myopic programmers each "sit under their own bush" for 6 months without any team interaction - something programmers are notoriously good at and with notoriously disastrous consequences.

I mean, look at some of the alarming responses on this thread to the actual suggestion of having to sit down and work alongside a fellow human-being!

[kingcook]

And that that work will be of higher quality (the two heads are better than one syndrome.)

Pair-programming also, if you rotate the pairs, leads to a spread of knowledge throughout the whole team. This is a much better approach than having insular, myopic programmers each "sit under their own bush" for 6 months without any team interaction - something programmers are notoriously good at and with notoriously disastrous consequences.

I mean, look at some of the alarming responses on this thread to the actual suggestion of having to sit down and working alongside a fellow human-being!

You know... programming computers is like, making love to a beautiful woman

[Wils]

And that that work will be of higher quality (the two heads are better than one syndrome.)

Pair-programming also, if you rotate the pairs, leads to a spread of knowledge throughout the whole team. This is a much better approach than having insular, myopic programmers each "sit under their own bush" for 6 months without any team interaction - something programmers are notoriously good at and with notoriously disastrous consequences.

I mean, look at some of the alarming responses on this thread to the actual suggestion of having to sit down and work alongside a fellow human-being!

I think this response might explain the differences of opinion. Some people like it because they like interacting with other developers and discussing things. As studies often contradict the arguments for pair-programming's supposed benefits IEEE Xplore - Abstract Page , the arguments for pair programming may just be justifications for developers who enjoy and want to spend more time in the company of other developers.

I think we would all agree that the stereotype of the socially awkward computer programmer is not too far off the mark, and as a result I don't think software engineers make the best company. I don't mind my job, but having to do it in constant interaction with most other developers I have met fills me with dread. As JP Sartre said, "Hell is other people". That's why I asked the question in the OP. I wanted to know how long I have until I would find it difficult to avoid PP as I would need to change my job.

[VectraMan]

Pair-programming also, if you rotate the pairs, leads to a spread of knowledge throughout the whole team. This is a much better approach than having insular, myopic programmers each "sit under their own bush" for 6 months without any team interaction - something programmers are notoriously good at and with notoriously disastrous consequences.

You don't have to work in pairs to avoid the situation where one person hordes knowledge. You could encourage developers to talk to each other; I've always found the daily standup meeting quite effective. I hate the idea of having to share a computer with someone through the day, but that doesn't mean that I want to become an office hermit, communicating in grunts and being unfireable because I'm the only one that knows how the photocopier works.

[nomadd]

You don't have to work in pairs to avoid the situation where one person hordes knowledge. You could encourage developers to talk to each other; I've always found the daily standup meeting quite effective. I hate the idea of having to share a computer with someone through the day, but that doesn't mean that I want to become an office hermit, communicating in grunts and being unfireable because I'm the only one that knows how the photocopier works.

Exactly. The idea is to be flexible. I've worked in plenty of "paired" environments where we don't share the same PC all the time. Maybe touch-base around a single PC a few times a day is enough; split up the work, use different PCs, then pull the pieces together a few hours later.

But, when the need arises, it may require both of you sat at the same PC (or terminal screen) for several hours (days) on end (tricky debugging or testing sessions spring to mind here.) Just whatever gets the job done quickest and to the best quality levels - and that's rarely one guy/girl sat there on their own believing they are the best in the world and don't need to share their thoughts/work with anyone else. People who think like that are usually completely incompetent, and refuse to share anything for fear of being found out, IMHO (and experience.)

[nomadd]

<modded>[/URL]

And probably best left for General.

<mod>Quite</mod>

[oliverson]

It's when the interview process involves pair-programming you have to worry. Interviews at stressful at the best of times but when you have somebody there next to you who has the responsibility of hiring you and they've seen the test scenario before a million times but you come in cold, then there's far more resting on this pairing than your normal day it's a bit too much.

I think the problem with pairing is there's a natural tendancy for people to show off their knowledge or to dive into coding a solution without actually thinking through the problem. People think at different rates and have different approaches. Most roll their sleaves up and start hacking away. I prefer to digest the problem, come up with a solution and 'then' start coding. I think my approach ultimately leads to better code than the hack and slash approach. In short I think pair programming sucks.

[MyUserName]

I think the problem with pairing is there's a natural tendancy for people to show off their knowledge or to dive into coding a solution without actually thinking through the problem. People think at different rates and have different approaches. Most roll their sleaves up and start hacking away. I prefer to digest the problem, come up with a solution and 'then' start coding. I think my approach ultimately leads to better code than the hack and slash approach. In short I think pair programming sucks.

You have, however, given a very good reason as to why pair programming is good.

People who roll up their sleeves and hack away have someone sitting next to them to keep them in check. For generating a design you have someone sitting there to bounce ideas of who is thinking at a different rate and possibly different way to you, therefore the design gets the benefit of both as you will be discussing these issues as you format things.

Do not forget that, like Agile, Pair Programming assumes that both programmers have the project's best interests at heart (well, it assumes that the programmers are professional enough to at least act that way at work!!!).

[d000hg]

You don't have to work in pairs to avoid the situation where one person hordes knowledge. You could encourage developers to talk to each other; I've always found the daily standup meeting quite effective.

I've never seen information transfer happen in these meetings. For one thing 30-60s is only enough to cover the main area someone is working on, not anything useful about the tech/code. For another, everybody just sits looking bored waiting/dreading their turn to speak and then turns off until they can go do some real work.

I suppose some places it's not like that, maybe places where the devs choose to do this rather than have it foisted upon them by managers who read about it in a blog.

[oliverson]

You have, however, given a very good reason as to why pair programming is good.

People who roll up their sleeves and hack away have someone sitting next to them to keep them in check. For generating a design you have someone sitting there to bounce ideas of who is thinking at a different rate and possibly different way to you, therefore the design gets the benefit of both as you will be discussing these issues as you format things.

Do not forget that, like Agile, Pair Programming assumes that both programmers have the project's best interests at heart (well, it assumes that the programmers are professional enough to at least act that way at work!!!).

Unless both coders are hackers!