5 ms·

Though not nearly as intense as the experience related in this anecdote, it is that same compulsion to maintain focus that makes pair programming so valuable fo

by rsbrown 16y ago

Though not nearly as intense as the experience related in this anecdote, it is that same compulsion to maintain focus that makes pair programming so valuable for me ... and so difficult and uncomfortable. No doubt in my mind, though: I write much better code when I'm pairing with another developer.

briandoll 16y ago
Great point. Each pair will usually find the right balance of pairing time and breaks, but using the Pomodoro technique (http://www.pomodorotechnique.com/ http://www.pomodorotechnique.com/) is probably a good place to start. I don't think the uncomfortable aspects of pairing are unique to pairing as much as they are compressed in a much shorter space. No snarky emails during code reviews or awkward hallway conversations. It's all right there, in real time. I _really_ love hacking on code alone, but every pairing session I've had has been memorable and the code has most certainly been superior to what I would have done solo.
- happy4crazy 16y ago
  Second the pomodoro technique--it's almost weirdly effective. That said, I haven't tried it yet with anyone at work--but for solo stuff, it's been amazing.
mhd 16y ago
People are wired rather differently. Yes, you don't procrastinate to HN, Facebook, OKCupid or whatever's your online crack, but on the other hand the programming itself is an order of magnitude worse (and feels twice as bad). Maybe with a few programmers in the world I could "co-flow" enough to get up to speed, but that would still waste the other person's productivity. Considering that nice little XPers should swing a lot, this makes this probably the worst "agile" practice I know of, beyond even TDD. Like I said, some people might be wired differently. Although in this case, it's hard to imagine getting a > 200% productivity increase out of two people to make it worth it in the long run. For short code golfing sessions, sure. That's been called "could you help me with this code?" for a long time, before that nice alliteration was invented.
- rsbrown 16y ago
  "it's hard to imagine getting a > 200% productivity increase" It depends on how you measure productivity. If it's measured in LOC/hour or something, then pair programming will definitely seem like a huge productivity hit. If you measure productivity more like "features delivered per month" (and negatively adjust for bugs that make it to production) I contend that pair programming will probably yield more favorable numbers.
  - mhd 16y ago
    As with most Agile claims, I'd like to see that proven first. Even then I might wonder whether it's the right thing for me, but at least we could have some numbers how this works out in general. If you've got a high fault rate, two people working things out might improve things enough to be worth the while. Especially in a case were uncaught bugs are really band and/or your daily coding is an exercise in tedious input checking, c.f. some web sites and conventional GUIs. And even then I'd say that the occasional meeting plus a decent code review process would probably be as effective, without the hit in performance. Never mind the sheer annoyance a lot of people would feel having to "couple" all the time.
  - billmcneale 16y ago
    >If you measure productivity more like "features delivered per month" (and negatively adjust for bugs that make it to production) I contend that pair programming will probably yield more favorable numbers. There's no credible evidence to support that claim. On the other hand, pair programming generates a lot of churn (discussions about details between the pair programmers, the outcome of which bears little consequence on the solution of the problem) and that alone is guaranteed to negate whatever gain you could expect from pair programming. In my experience, asynchronous code reviews work a lot better.
    - rsbrown 16y ago
      "There's no credible evidence to support that claim." My experience supports it. Can you point to credible evidence to support your claim?

by rsbrown 16y ago

briandoll 16y ago

Great point. Each pair will usually find the right balance of pairing time and breaks, but using the Pomodoro technique (http://www.pomodorotechnique.com/ http://www.pomodorotechnique.com/) is probably a good place to start. I don't think the uncomfortable aspects of pairing are unique to pairing as much as they are compressed in a much shorter space. No snarky emails during code reviews or awkward hallway conversations. It's all right there, in real time. I _really_ love hacking on code alone, but every pairing session I've had has been memorable and the code has most certainly been superior to what I would have done solo.

happy4crazy 16y ago
Second the pomodoro technique--it's almost weirdly effective. That said, I haven't tried it yet with anyone at work--but for solo stuff, it's been amazing.

mhd 16y ago

People are wired rather differently. Yes, you don't procrastinate to HN, Facebook, OKCupid or whatever's your online crack, but on the other hand the programming itself is an order of magnitude worse (and feels twice as bad). Maybe with a few programmers in the world I could "co-flow" enough to get up to speed, but that would still waste the other person's productivity. Considering that nice little XPers should swing a lot, this makes this probably the worst "agile" practice I know of, beyond even TDD. Like I said, some people might be wired differently. Although in this case, it's hard to imagine getting a > 200% productivity increase out of two people to make it worth it in the long run. For short code golfing sessions, sure. That's been called "could you help me with this code?" for a long time, before that nice alliteration was invented.

rsbrown 16y ago
"it's hard to imagine getting a > 200% productivity increase" It depends on how you measure productivity. If it's measured in LOC/hour or something, then pair programming will definitely seem like a huge productivity hit. If you measure productivity more like "features delivered per month" (and negatively adjust for bugs that make it to production) I contend that pair programming will probably yield more favorable numbers.
- mhd 16y ago
  As with most Agile claims, I'd like to see that proven first. Even then I might wonder whether it's the right thing for me, but at least we could have some numbers how this works out in general. If you've got a high fault rate, two people working things out might improve things enough to be worth the while. Especially in a case were uncaught bugs are really band and/or your daily coding is an exercise in tedious input checking, c.f. some web sites and conventional GUIs. And even then I'd say that the occasional meeting plus a decent code review process would probably be as effective, without the hit in performance. Never mind the sheer annoyance a lot of people would feel having to "couple" all the time.
- billmcneale 16y ago
  >If you measure productivity more like "features delivered per month" (and negatively adjust for bugs that make it to production) I contend that pair programming will probably yield more favorable numbers. There's no credible evidence to support that claim. On the other hand, pair programming generates a lot of churn (discussions about details between the pair programmers, the outcome of which bears little consequence on the solution of the problem) and that alone is guaranteed to negate whatever gain you could expect from pair programming. In my experience, asynchronous code reviews work a lot better.
  - rsbrown 16y ago
    "There's no credible evidence to support that claim." My experience supports it. Can you point to credible evidence to support your claim?