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

151–160 of 308 posts

Re: The mortifying ordeal of pairing all day

#151

Post by MockObject »

g051051 wrote: post #133
dkersten wrote: post #98

Earlier quoted context omitted.

I don't agree. I wrote a top-level comment about my (positive) experience pairing, but I'll state it again here because its relevant to your comment: I was on a team with one other guy working on a complex distributed-systems project. We were both principle engineers at the company. We delivered the project in under a year and as far as I'm aware from talking with former colleagues, the code is still in production wi…

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…

All those benefits he listed there can, and often do, offset what seems like a waste of an extra programmer.

Re: The mortifying ordeal of pairing all day

#152

Post by ballenf »

kstenerud wrote: post #68

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…

I think it's also fair to apply that tolerance to the team level: letting teams exist that require pairing. And teams that never pair. And everything in between.

That is, the parent point, should not be used as an argument against there existing teams with team-level pairing standards or expectations.

If we get to the point where it is hard to find a non-pairing team, then maybe we revisit this. But given the diversity of people on this topic, that seems extremely unlikely.

The justification on teams that require pairing should be a non-judgmental "that's just how we do it here. For now." And people who have strong preferences should be able to ask about it interviews.

Re: The mortifying ordeal of pairing all day

#153

Post by g051051 »

MockObject wrote: post #151
g051051 wrote: post #133

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…

All those benefits he listed there can, and often do, offset what seems like a waste of an extra programmer.

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.

Re: The mortifying ordeal of pairing all day

#154

Post by bluk »

commandlinefan wrote: post #141
kstenerud wrote: post #68

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…

I've pair programmed using a shared server for a couple years. Both of us ssh'ed into a server and used a shared tmux session and primarily used vim to edit code. Having a chat program on the side to share links or other info we wanted to keep allowed us to browse things like documentation at our own pace. An audio/video session if working remotely.

If terminal based pair programming doesn't work, Visual Studio Code has an interesting "Live Share" feature which works similarly. You keep some of your extensions (and don't even need all of the same extensions installed to make things work depending on who shares).

Re: The mortifying ordeal of pairing all day

#155

Post by chrisBob »

I can't imagine pairing full time, but I did it for brief stints as a customer of Menlo Innovations. All customer code must be written by pairs, but one option to reduce costs is to have the customer supply half of the pair team, so I did this for a few half days one one project.

This is obviously scary at first because someone is going to watch me code! It turns out that it is perfectly normal to use google/stackoverflow to write programs, and I actually found the experience reassuring once I got past the shock of having someone look over my shoulder.

My team does not do pair programming, but I understand why Menlo does it, it it works great for them. Some benefits I saw were:

1) It is great for junior developers. It's like turning mentoring up to 11. This means that it is much easier to hire people because you can fill seats and actually train people.

2) They have a special kind of family friendly culture where people have their infants in the office. One half of a pair can be holding their 3 month old and still contribute as half of the pair. I think they get slightly less keyboard time, but it still works.

3) Developers changed projects a lot. Splitting the day between two projects seemed normal, and 3-4 different projects in a week was standard. The pairs provide some continuity during these transitions.

Major down sides include the fact that you can't visit HN during work time. That means that the opinions here are likely to be skewed.

There are places and situations where pair programming isn't a good fit, but after seeing it in practice, I think there are also places where it is a good fit.

Re: The mortifying ordeal of pairing all day

#156

Post by eloisant »

kstenerud wrote: post #68

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…

I've had great pair programming sessions in the past.

But it was always occasional, and short. Sometimes longer or more often if it's someone I really like to work with, but there have been only a handful in about 20 years of career.

I think that the biggest mistake about pair programming is about forcing it, especially when do it all day. I could never do that!

Re: The mortifying ordeal of pairing all day

#157

Post by house9-2 »

FriedrichN wrote: post #30
throwawayboise wrote: post #12

Earlier quoted context omitted.

I quit my job when pairing was introduced. I was open to the idea when I read about it but hated the reality. Everything from working 12 inches from people who refused to use deodorant to having to explain what I was thinking instead of just doing it. Also all my tools, preferences, keyboard shortcuts, etc. were mine, committed to muscle memory over years, and nobody else's setup was the same. Didn't work for me.

>people who refused to use deodorant What is it with people in our field that this is so commonplace? There are few things worse than a room full of IT people with the windows closed. "It's the smell" as Agent Smith said.

There is no deodorant that can suppress my BO, I just end up smelling like BO with a hint of deodorant.

Luckily for my coworkers I am usually remote.

Re: The mortifying ordeal of pairing all day

#158

Post by pizzeriafrida »

I had a great time pairing with a few individuals from my past, and I'd describe the sessions as playing a coop game with friends. It was fun to team up and figure out a problem and build something; the shared joy of overcoming some hurdle.

Similarly had good experiences 'mob' programming, 7 of us in a conference room focused on building out some new thing. But again, it felt more like hanging out with friends and playing a coop game together.

Re: The mortifying ordeal of pairing all day

#159

Post by brightball »

kstenerud wrote: post #68

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…

I’ve always encourage pair programming solely as a team cross training exercise and only for short stints.

Aka - Bob built a system using tooling that is new to our team and unknown to anyone else. Bob needs to pair with Fred for a couple of hours so more than just Bob will have hands on experience with the tech.

That’s my only requirement because in my experience it’s better than documentation and it’s a requirement to make sure Bob can take vacations.

Everybody will be able to figure it out eventually, but if something is urgent we don’t have until eventually.

Re: The mortifying ordeal of pairing all day

#160

Post by bigmanwalter »

g051051 wrote: post #153
MockObject wrote: post #151

Earlier quoted context omitted.

All those benefits he listed there can, and often do, offset what seems like a waste of an extra programmer.

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".
Post reply on HN