Live data from Hacker News

The mortifying ordeal of pairing all day

simplermachines.com

221–230 of 308 posts

Re: The mortifying ordeal of pairing all day

#221
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…

that sounds exhausting.. holy fk, i could pair maybe half of the day, and at most like 1-2 weeks at a time

Re: The mortifying ordeal of pairing all day

#222
Lots of people burn out. There's no reason presented to think the author would have had more, less, the same, or no burnout programming on their own. They happened to burn out, and they happened to be pair programming for an extended period of time. Myself and friends have also experienced burn out, and none of us pair programed any significant amount.

Re: The mortifying ordeal of pairing all day

#223
I used to work at a startup where I was the most senior engineer below one of the founders, a guy who happened to be remote, thousands of miles away, except about 2-4 times a year when he would fly in for a week or so and share my office with me. He was very enthusiastic about pair programming and we would do this for a couple of days every time he was in town, and afterwards would rave about how thrillingly productive it was. Except it wasn’t really true. I did really enjoy us putting our heads together and solving problems, and a day pairing really did feel more productive in absolute terms than what I would accomplish on my own, but more than twice as productive? Not a chance. More than twice as exhausting? Definitely. 4-8 days a year is about all I could take of that.

PS my theory about why he found it so invigorating and productive was that normally, he was too busy to ever spend an entire day writing code. He would be interrupted with meetings and questions all day. The difference when we were pairing was that he was “hiding out” for an entire day with his head in an IDE and shutting everything else out. I suspect he’d find it equally invigorating if he had the ability to do that on his own.

Re: The mortifying ordeal of pairing all day

#224

Earlier quoted context omitted.

I just can't fathom that. How could the 4 hours "pairing" negate the fact that one of you can't work for 4 hours? I can see it if those 4 hours were really design/planning time, but otherwise, I just don't see how it could work. Most of what I see people here calling "pair programming" is just normal collaboration. Bringing in someone to put a second set of eyeballs on a problem, or to discuss some design topics, or…

> How could the 4 hours "pairing" negate the fact that one of you can't work for 4 hours? This is a very common misconception. Both of you are "working", only one of you is typing. I don't know what kind of work you do, but in my ~20 years of programming, typing is a rather tiny percentage of programming work. Most of it is thinking, problem solving and designing. Both people are doing these things, except you're bot…

> I don't know what kind of work you do, but in my ~20 years of programming, typing is a rather tiny percentage of programming work. Most of it is thinking, problem solving and designing.

I spend a lot of time typing and thinking. And having to slow down and talk to another human impedes my thinking. It's much faster to just think.

> Both people are doing these things, except you're both doing them on the same task.

No, one person is doing things, and another is watching and talking while the other person is doing things.

> you get knowledge sharing for free

It's not free, it takes time to communicate, you're just doing it while trying to complete a task. The disruption to flow seems like it would be a much bigger hit than the marginal gains of trying to teach/knowledge share and work at the same time.

> How much of your programming is actually typing into a text editor?

The vast majority. It doesn't take me 80% of my time to think and plan.

> I 100% believe that this project would not have been delivered in that time frame by just two people if we hadn't pair programmed.

I can't comment on that, but I can say that I've never worked on a project that would have benefitted from the kind of pair programming you (and OP) are describing. And it's not that I don't collaborate, but when I do, it's much shorter periods, and much longer stretches of time between. I can spend an hour planning with a peer, and then we go off and do things, and just trust that they work (and we're right the vast majority of time). We have established standards, and code reviews catch edge cases.

Re: The mortifying ordeal of pairing all day

#226

Earlier quoted context omitted.

And my point is that I just can't see it. I collaborate with people, and there's benefit in those relatively short interactions, but I've never seen a situation where it made more sense to pair up like that, unless it's a training scenario.

It's like arguing if a piano sounds better when played by one or two people at the same time. It's just different. Hard to argue that the solo pianist is "better".

Except in this case, it's like one person playing while another person talks to them about what they're playing. In a purely instructional context, sure. In a performance context, it sounds crazy.

Re: The mortifying ordeal of pairing all day

#227

Earlier quoted context omitted.

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. There have definitely been experiments along those lines with successful results. I can't immediately find the original source, but I remember reading a few years ago about a business that switched to working 9-3 Monday-Friday, with resulting benefits…

Shorter days makes much more sense to me than shorter weeks. Wherever I've worked those last two hours of the day are always a waste.

I agree. If I'm working on something particularly interesting, I can code for much longer for a day or even a few days and still be making useful progress. However, for routine grunt work over the long term, I don't think I ever sustained much more than 6 hours of productive work per day when I was programming full-time. Past that, I would start to either slow right down or make mistakes that ended up taking more time to fix later. I did find that as I started taking on other responsibilities as well as the technical stuff I could make use of the extra time for that without affecting my programming much, but I suspect if I ever move to full-time on the business side the lack of variety will be a factor again.

Re: The mortifying ordeal of pairing all day

#228

This is an introvert's nightmare. The "fear of being vulnerable", or "showing my limitations as a human or engineer" are so secondary to the emotional drain of having to be that close to a person all day, every day at work, they don't even show up on the horizon of concerns. Pairing is incredibly useful and valuable, but doing it all day would be hell. If someone told me that they wanted me to pair for the majority o…

Reading about them only having workstations for every other people, I would have turned on my heels and walked out the first day!

Re: The mortifying ordeal of pairing all day

#229
post #53

Earlier quoted context omitted.

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. There have definitely been experiments along those lines with successful results. I can't immediately find the original source, but I remember reading a few years ago about a business that switched to working 9-3 Monday-Friday, with resulting benefits…

Microsoft tried the 4-day work week, for example: https://www.npr.org/2019/11/04/776163853/microsoft-japan-say...

I'm not so surprised that they got such good results in Japan, where traditionally the business culture has been extremely demanding compared to most places. It would be interesting to know whether they did ever try similar experiments in other parts of the world with more "normal" working hours, and if so, whether they managed to repeat the successful result.

Re: The mortifying ordeal of pairing all day

#230

Earlier quoted context omitted.

I've never seen or even heard of a place where pairing is optional. I've only ever seen it compulsory or forbidden.

Pairing is optional at my employer. As a manager, I'm always on the look-out for tasks where I feel pairing may provide value. These are often moderately complicated tasks where I want a more junior team-member involved. Or, doing green-field UI work, I'll suggest one of the more UX-savvy developers pair with a small group of developers. I have also managed people who just like to work together and they're free to pa…

>Pairing is optional at my employer.

Is collaboration / pairing part of employee evaluation in any way?

Post reply on HN