Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The mortifying ordeal of pairing all day

simplermachines.com

Post reply on HN
Print view View original

41–50 of 308 posts

Re: The mortifying ordeal of pairing all day

#41

Post by admissionsguy »

nikanj wrote: post #24

Sounds like the underlying reason is a link between performance and endurance. If you're achieving very high productivity, you can't do 8+ hours per day every day. I wonder if it would possible to find a balance of doing shorter days / working fewer days, and offsetting that by being more productive in the hours that you do work.

> I wonder if it would possible to find a balance of doing shorter days / working fewer days, and offsetting that by being more productive in the hours that you do work.

It might be possible, but it definitely would not be acceptable!

Re: The mortifying ordeal of pairing all day

#42

Post by furrowedbrow »

anothernewdude wrote: post #17

My experience is that it's best when it happens organically. Enforcing this sounds like a punishment.

Agreed. I think pairing basically amplifies the team chemistry, for better or worse. If you have down-to-earth developers who like to learn and teach and generally get along, pairing will be amazing, but if you have know-it-all devs desperate to be right and show how smart they are, it’s a disaster. I paired for a year in the latter environment and it was miserable.

Re: The mortifying ordeal of pairing all day

#43

Post by inreverse »

I can only pair effectively if I feel fully comfortable with the person I'm pairing with, and I would not feel uncomfortable disclosing who meets or does not meet that criteria at work.

Software engineers tend to be less comfortable socially so I imagine other people share this perspective.

Re: The mortifying ordeal of pairing all day

#44

Post by rob74 »

For people not that familiar with this particular development technique: he means pair programming. When I read "pairing", I think about Bluetooth devices first, which can be an ordeal sometimes, but hardly something that can lead to burnout...

Re: The mortifying ordeal of pairing all day

#45

Post by halayli »

How did this person link the cause and effect?

How repeatable is this pattern?

How were the other possible reasons eliminated like aging, depression, and many other factors that also are happening in parallel during the course of 5+ yrs?

Correlation does not mean causation.

Re: The mortifying ordeal of pairing all day

#46

Post by Clewza313 »

denton-scratch wrote: post #31
Clewza313 wrote: post #3

Earlier quoted context omitted.

Yes, that's how pairing works: two people, one keyboard, one workstation. Having done this for a while, I wholeheartedly agree with everything the author says. It's great for software quality and productivity (among other things, it's much harder to slack on HN), but it's also incredibly draining and definitely not for everybody.

Two people, TWO keyboards, one workstation (with a good monitor). You can't keep switching seats, or shuttling the keyboard back and forth. Remove as much unnecessary friction as possible. And assign someone on the team to be the tea-mug refiller for the day. And management have to provide a workstation for each worker; you pair at a pairing workstation, but everyone needs their own machine for stuff like email, Slac…

In my team, the rule was that one person was "driving" (hands on keyboard) and the other was "navigating" (hands off). Whether there's two physical keyboards or not is kinda of immaterial.

Re: The mortifying ordeal of pairing all day

#47

Post by incrudible »

Project management is fundamentally about managing human psychology. This is a horrifying prospect, because we do not truly understand human psychology at a mechanistic level, much less to the point where it can be applied to the individual.

Therefore, we instead seek refuge in processes and rituals that are, for practical reasons, not validated by experiment. One can hide almost any issue in a forest of obtuseness. If something doesn't work out, one can always blame it on some failure in adherence to the dogma.

Re: The mortifying ordeal of pairing all day

#48

Post by wilsonrocks »

ratww wrote: post #32

I also worked at a company where pairing was mandatory for 8 hours a day. Plan was concocted by two tech leads who, of course, didn't pair themselves. The exhaustion was visible, and productivity was very low. Since everyone vocally thought it was a "waste of time", there was a Fight-club-style "rule" where we couldn't talk about the downsides in public or even in Scrum meetings. We missed several deadlines for an MV…

This sounds awful.

It's amazing how workplaces can get in these kind of darkly comic places

Re: The mortifying ordeal of pairing all day

#49

Post by audiometry »

ratww wrote: post #32

I also worked at a company where pairing was mandatory for 8 hours a day. Plan was concocted by two tech leads who, of course, didn't pair themselves. The exhaustion was visible, and productivity was very low. Since everyone vocally thought it was a "waste of time", there was a Fight-club-style "rule" where we couldn't talk about the downsides in public or even in Scrum meetings. We missed several deadlines for an MV…

> there was a Fight-club-style "rule"

How did this rule maintain itself when essentially no one supported or agreed with it? (except the two 'leaders') Why wouldn't people take advantage of opportunities to push back against it, when for instance, the CEO asks what's the problem?

Re: The mortifying ordeal of pairing all day

#50

Post by ratww »

audiometry wrote: post #49
ratww wrote: post #32

I also worked at a company where pairing was mandatory for 8 hours a day. Plan was concocted by two tech leads who, of course, didn't pair themselves. The exhaustion was visible, and productivity was very low. Since everyone vocally thought it was a "waste of time", there was a Fight-club-style "rule" where we couldn't talk about the downsides in public or even in Scrum meetings. We missed several deadlines for an MV…

> there was a Fight-club-style "rule" How did this rule maintain itself when essentially no one supported or agreed with it? (except the two 'leaders') Why wouldn't people take advantage of opportunities to push back against it, when for instance, the CEO asks what's the problem?

Sorry if I didn't make it clear: the junior developer did take advantage of it when CEO asked.

Also it was only really enforced during Sprint Retrospectives.

Post reply on HN