Live data from Hacker News

The mortifying ordeal of pairing all day

simplermachines.com

141–150 of 308 posts

Re: The mortifying ordeal of pairing all day

#141

Pair programming generates visceral responses due to it being introduced as if it were fact, which for me always triggers my spidey senses. People who didn't like it were told "you're doing it wrong" or "you didn't give it a proper chance". Dismissing criticisms out of hand only furthers distrust, regardless of the actual value of the idea. I played along and paired for awhile, but now steadfastly refuse to pair, eve…

> but rest assured that there are those who aren't built that way

Yeah, the title suggests an anti-pair-programming rant, but the author seems to have stockholm-syndrome'd himself into accepting it. I tried pair programming once, a long time ago, when it first "came out". We immediately ran into all sorts of practical issues like, how do you check your e-mail? (Back then, you had to read e-mail in a dedicated e-mail client like Outlook). What if there's documentation that needs to be read? Take turns reading a page? I can't even conjure up a world where pair programming is effective in my imagination.

Re: The mortifying ordeal of pairing all day

#142
[Edit: Article is spot on]

In my experience, pairing works really well to deal with ambiguity, as in problem solving.

In my experience, management often mistakes ambiguity with uncertainty when allocating resources to a project or engagement. This results in terrible pairing experiences where you've been allocated to a project where your normal tech. stack simply doesn't apply. You're suddenly in the weeds learning a new language / framework / deployment-environment playing catch-up with your pair, while your pair is trying to burn-down the actual task/story at hand.

Yes, Software engineers should be willing to learn new things. But, No, I'm not willing to sacrifice the primary psychological safety of knowing "I'm qualified to do my job" just to keep a cadence.

Re: The mortifying ordeal of pairing all day

#143
Agree with many sentiments described here. I was one of the early pioneers in this area, starting with XP in 1998. At the time, it was cool because it was counter culture, rather than cargo culture. I remember having to get approval from the president of our 500 person company to come in on our own time on a Saturday to take down a cubicle wall, so that we could have a larger collective space.

Some pairings were a delight to participate in; others more strained. But when it worked, it was super cool. It was like that dribble attack on the goal where you just read each other's minds.

One thing we learned early on though, was that any real debugging didn't work well this way. We even codified it as "debugging break" where we would split apart and sort of mumble aloud the different things we were seeing as we pursued our various intuitions and hunches.

Now days, I rarely pair anymore. The skill gap in my current team is pretty varied. The sense of self is strong, which generally goes against the "us before I" gestalt of pair programming. I do find when I need to answer questions or demonstrate, I tend to put myself in the passenger chair and turn it into a pairing experience for the other.

Re: The mortifying ordeal of pairing all day

#144
I've worked on teams historically that did pairing (even pairing all day), and mobbing all day, and I don't get the hate.

If the main issue is burnout, then what's up? Even working solo you can burn out, so I don't think that's a valid argument unless someone can convince me that specifically pairing is causing the burn out.

The biggest thing is you need a team that can trust and support each other.

Re: The mortifying ordeal of pairing all day

#145
As with almost everything, the truth is somewhere in the middle – pairing isn't universally good, nor univerally bad. It shouldn't be done all the time, neither should it never be used.

"There is no silver bullet." Fred Brooks wrote this over 30 years ago, and it still applies.

Re: The mortifying ordeal of pairing all day

#146

I've worked on teams historically that did pairing (even pairing all day), and mobbing all day, and I don't get the hate. If the main issue is burnout, then what's up? Even working solo you can burn out, so I don't think that's a valid argument unless someone can convince me that specifically pairing is causing the burn out. The biggest thing is you need a team that can trust and support each other.

> unless someone can convince me that specifically pairing is causing the burn out

If someone tells you something is causing them anxiety and stress can't you just accept that rather than requiring to be 'convinced'?

You say you want a team that supports and trusts... yet you don't believe people when they say something's causing them pain.

Re: The mortifying ordeal of pairing all day

#147

I've worked on teams historically that did pairing (even pairing all day), and mobbing all day, and I don't get the hate. If the main issue is burnout, then what's up? Even working solo you can burn out, so I don't think that's a valid argument unless someone can convince me that specifically pairing is causing the burn out. The biggest thing is you need a team that can trust and support each other.

> unless someone can convince me that specifically pairing is causing the burn out.

For many people, socialising is energy-draining. Thus pair programming is extra tiring. While I do enjoy pair programming in some circumstances - for particularly tricky problems, or for mentoring - I would struggle (to the point that I would no longer like or be effective at my job) if I had to do it all-day every day. I can believe that some people can be productive with the distraction of someone else constantly there, but I'm nowhere near as productive as I am working on my own.

Re: The mortifying ordeal of pairing all day

#148
When I started my first job programming job out of university, I spent a lot of time pairing with one of my teammates (online) at the beginning. Not necessarily because it was enforced, but I think we figured it would just be a good way to learn. This went on for a few months, over time I'd take shots at doing tasks for myself, some with more or less success.

Then eventually that teammate moved to a different team, and suddenly I was doing a lot more stuff on my own and... I learned WAY faster. I suddenly realized how dependant I was being when we were pairing all the time. Call it a self-discipline issue maybe, but if I ran into a roadblock I'd just ask him for the solution cause otherwise it felt like I was wasting time to not figure things out for myself. But once that crutch wasn't there, I had to think about things for myself more, and it was like a couple week before I was feeling way more confident in my skillset.

Re: The mortifying ordeal of pairing all day

#149
post #90

Earlier quoted context omitted.

I'm actually here because my colleagues keep coming up with things posted here and on other sources and I was intrigued as to the consensus behind them. I'm pleasantly surprised to read that there is a nice critical balance of discussion. The worry for me is that there is almost always an obvious detachment from the steps carried out to the benefit which is the precise definition of a cargo cult. A lot of people can'…

I agree with your criticism against pair programming. I also agree that it's helpful with an extra pair of eyes on anything you write, which is why I'm strongly in favour of code reviews.

...although some people might argue that you could get the same value from a rubber duck ( https://en.wikipedia.org/wiki/Rubber_duck_debugging )

Re: The mortifying ordeal of pairing all day

#150

Pair programming generates visceral responses due to it being introduced as if it were fact, which for me always triggers my spidey senses. People who didn't like it were told "you're doing it wrong" or "you didn't give it a proper chance". Dismissing criticisms out of hand only furthers distrust, regardless of the actual value of the idea. I played along and paired for awhile, but now steadfastly refuse to pair, eve…

How do you teach other people? In our team we sometimes have people working on systems that they are unfamiliar with, either because they are new to the team or new to the feature/system, and we've found that it saves a huge amount of time to have someone who is familiar with the system pair with them to get up to speed.

Sure, once the person is comfortable (and the "expert" is comfortable that they aren't going to do anything that they'll have to undo later) we typically go off and work on our own, but I just don't see how you can train others efficiently without pairing.

Post reply on HN