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…
The mortifying ordeal of pairing all day
221–230 of 308 posts
Re: The mortifying ordeal of pairing all day
#222Re: The mortifying ordeal of pairing all day
#223PS 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
#224Earlier 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 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
#225Re: The mortifying ordeal of pairing all day
#226Earlier 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".
Re: The mortifying ordeal of pairing all day
#227Earlier 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.
Re: The mortifying ordeal of pairing all day
#228This 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…
Re: The mortifying ordeal of pairing all day
#229Earlier 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...
Re: The mortifying ordeal of pairing all day
#230Earlier 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…
Is collaboration / pairing part of employee evaluation in any way?