4 ms·

Ouch. It sounds like the skill and/or knowledge discrepancy was too great. I've been in that situation before. If it doesn't get better after about 30 minutes,

by ggreer 13y ago

Ouch. It sounds like the skill and/or knowledge discrepancy was too great. I've been in that situation before. If it doesn't get better after about 30 minutes, I say something like, "I don't think this is working out. Let's split up." If possible, I try to suggest something else to work on separately. When it comes to code complexity, meta-studies argue against your claim. Pairing isn't worthwhile for simple code, but it's great for reducing defects in complex code: The benefit of pairing is greatest on tasks that the programmers do not fully understand before they begin: that is, challenging tasks that call for creativity and sophistication.[1] I and most everyone I've paired with have found this to be the case in our own work. A side note: I'm not sure what your core argument is. Most of your comments in this thread seem to be a combination of self-aggrandizement, personal opinion, and veiled insults towards those who pair. I've tried to keep my own comments civil and evidence-based, but many others in this thread are full of negativity. It makes me sad. 1. http://en.wikipedia.org/wiki/Pair_programming#Meta-analyses http://en.wikipedia.org/wiki/Pair_programming#Meta-analyses

JoeAltmaier 13y ago
Sorry if I'm being insulting. I get that way when responding in kind. There does seem to be more emotion than logic expressed here. I've meant to try to counter this with sincere expressions of my experiences. I must have gotten emotional in return. I'm at my wits end, trying to counter the simplistic claims of PP proponents that everyone else is a cowboy or just too inexperienced to 'get it'. I get it, I don't like it, I can see constant refutation of the whole idea of PP in my team.
JoeAltmaier 13y ago
Btw did you mean to use that link to support PP? It says things like "reduce development time somewhat and produces marginal positive effects on code quality"
memracom 13y ago
That sure sounds like a piece of work where a design discussion is necessary. However, I would not call a design discussion, pair programming. Find one or two others to help you hash out a design, but once you understand the problem, there is no need to pair program. Just build it, and call on the same people to do code review after you have built it. A good professional engineering environment where you start a sprint by having a design discussion with peers, and then come back to your peers on the tail end of the sprint for code review, is likely to provide all the same benefits as pair programming. After all, this is not supposed to be a software factory. Developing software is engineering work, and designing the work well, with your peers, will do just as much to strengthen the team and it will also improve the work quality. Working in pairs is useful in bringing junior people up to the next level, and in helping newcomers learn the problem domain or the platform/framework that you use, but it is not a universal good practice that you would use all the time.

by ggreer 13y ago

JoeAltmaier 13y ago

Sorry if I'm being insulting. I get that way when responding in kind. There does seem to be more emotion than logic expressed here. I've meant to try to counter this with sincere expressions of my experiences. I must have gotten emotional in return. I'm at my wits end, trying to counter the simplistic claims of PP proponents that everyone else is a cowboy or just too inexperienced to 'get it'. I get it, I don't like it, I can see constant refutation of the whole idea of PP in my team.

JoeAltmaier 13y ago

Btw did you mean to use that link to support PP? It says things like "reduce development time somewhat and produces marginal positive effects on code quality"

memracom 13y ago

That sure sounds like a piece of work where a design discussion is necessary. However, I would not call a design discussion, pair programming. Find one or two others to help you hash out a design, but once you understand the problem, there is no need to pair program. Just build it, and call on the same people to do code review after you have built it. A good professional engineering environment where you start a sprint by having a design discussion with peers, and then come back to your peers on the tail end of the sprint for code review, is likely to provide all the same benefits as pair programming. After all, this is not supposed to be a software factory. Developing software is engineering work, and designing the work well, with your peers, will do just as much to strengthen the team and it will also improve the work quality. Working in pairs is useful in bringing junior people up to the next level, and in helping newcomers learn the problem domain or the platform/framework that you use, but it is not a universal good practice that you would use all the time.