Live data from Hacker News

The mortifying ordeal of pairing all day

simplermachines.com

261–270 of 308 posts

Re: The mortifying ordeal of pairing all day

#261

Earlier quoted context omitted.

> 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.…

I’m not the person you’re responding to, but I find it striking that you’re making very emphatic, very confident statements about things they have experienced and you have not. It’s quite rude.

FWIW, I do have experience with pairing, and my experience is the same as theirs: the person not typing does a lot of design thinking. It leaves the person who is typing free to power ahead at full speed, without having to pause for thought.

Re: The mortifying ordeal of pairing all day

#262
post #136

Earlier quoted context omitted.

Programming is neither design nor implementation; it's a skill and a tool that isn't owned by a particular process. I am quite happy to sketch in code; I won't work with my hands tied behind my back. Concretely, what "incredible waste" are you projecting here? Neither myself nor the ancestor even laid out a process to criticize.

"Design" can mean a lot of different things. UI? Data structures and algorithms? API? Database schema? Whichever of these we're discussing, and whatever process we're talking about, I find it much faster to think and sketch and describe in words before writing code.

No one said these things were mutually exclusive. Unless you're telling me that your sketches map exactly into the code you've written every time, then there is design emerging during the coding process.

Re: The mortifying ordeal of pairing all day

#263

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…

As an introvert myself, strong disagree. I (and introverts in general, to my knowledge) don’t have any trouble interacting with people in small group settings when those interactions are focused on ideas. The problems come with large group settings and small talk. Pairing is in the first category, not the second.

Re: The mortifying ordeal of pairing all day

#264
post #253

Is it really true that Pivotal had only n/2 workstations for the n devs? That seems to be an extreme arrangement (pardon the pun). I can see the benefit of pairing when (a) the problem is somewhat well-defined, and there is a natural 'end' to the exercise. For example, a P0 bug that needs fixing immediately, and there's not much time for additional code-review. In this situation, pairing with the person who knows the…

> Is it really true that Pivotal had only n/2 workstations for the n devs?

By and large yes this is true. There were some teams that experimented with odd numbered sizes and others that were split remotely that required more to facilitate all pairing rotations.

> How does such a wonky culture take root in a fairly large organization anyway?

I suppose wonkiness is in the eye of the beholder. The company was simply built around XP, with pairing being a core part of that. I went to Pivotal (2015-2019) because I wanted among other things, to try pair programming from some of the most committed to it. In that way, it's self-selecting. It was baked in throughout the interview process. Sure, there are a lot of senior engineers who will never get on board with pairing, but there also are far fewer companies that commit to it in the same way.

Re: The mortifying ordeal of pairing all day

#265

Earlier quoted context omitted.

> 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.…

I’m not the person you’re responding to, but I find it striking that you’re making very emphatic, very confident statements about things they have experienced and you have not. It’s quite rude. FWIW, I do have experience with pairing, and my experience is the same as theirs: the person not typing does a lot of design thinking. It leaves the person who is typing free to power ahead at full speed, without having to pau…

> I find it striking that you’re making very emphatic, very confident statements about things they have experienced and you have not.

You're free to whatever interpretation you wish. I'm glad it worked out for them (and you).

> It leaves the person who is typing free to power ahead at full speed, without having to pause for thought.

I hope you can look back at that statement and see how ludicrous it sounds.

Re: The mortifying ordeal of pairing all day

#266

Earlier quoted context omitted.

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.

In fluid pairing the driver and navigator are constantly switching roles and bouncing off each other. Based on another message above where you said: > No, one person is doing things, and another is watching and talking while the other person is doing things. I just don't think you're fully understanding the process, which I'm not surprised (and don't hold it against you) about because it's very nuanced. In the piano…

> In fluid pairing the driver and navigator are constantly switching roles and bouncing off each other.

Apparently, pair programming places no value on flow.

> I just don't think you're fully understanding the process, which I'm not surprised (and don't hold it against you) about because it's very nuanced.

Yeah, pretty sure I do understand it. I just don't see how it's effective unless the people involved are either both very junior, or it's a training scenario of some kind.

Re: The mortifying ordeal of pairing all day

#267
post #19

I worked for a shop that adopted the Pivotal model and I can say that it was hell on Earth. If you check the research data it is obvious that pairing is only effective in some very special cases like: knowledge transfer for new teammates, onboarding people, getting juniors up to speed, solving __very__ complex problems. For your everyday work it is not only draining, but also a waste of both of your time. What makes…

Can you share this research data?

Re: The mortifying ordeal of pairing all day

#268

Earlier quoted context omitted.

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

If you couldn’t figure out how to check your email or read documentation, it sounds like you were looking for reasons to fail. Pairing doesn’t mean you’re literally joined at the hip. You’re allowed to exercise judgment.

Well, no, in our case it literally did mean we were "joined at the hip" - we shared one computer.

Re: The mortifying ordeal of pairing all day

#269

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…

As an introvert myself, strong disagree. I (and introverts in general, to my knowledge) don’t have any trouble interacting with people in small group settings when those interactions are focused on ideas. The problems come with large group settings and small talk. Pairing is in the first category, not the second.

Your description of introversion fits with mine, but pairing with someone _all day_ would completely drain me of any energy.

Re: The mortifying ordeal of pairing all day

#270

Earlier quoted context omitted.

> 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.…

I think you are deeply misinformed about pair programming and have some ingrained misconceptions. I don't think I can persuade you otherwise though.
Post reply on HN