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

On Pair Programming

martinfowler.com

Post reply on HN
Print view View original

81–90 of 121 posts

Re: On Pair Programming

#81

Post by nikofeyn »

jacques_chester wrote: post #70
cgrealy wrote: post #68

Earlier quoted context omitted.

Fundamentally different to software development on both counts. Aviation and surgery are basically real-time activities. If you make a mistake in either, the consequences are dire. Also, in aviation, it's about redundancy... if there's an issue, it's not like you can wait while someone else steps in. Software is not like that. Your code almost never goes straight into prod (unless you have really aggressive CI/CD!).…

Software mistakes can be pretty dire and if you want to ensure quality, in practice, you will want different eyes to look at the code. Which also lends redundancy, if someone wishes to move on. The easiest time to catch mistakes is early.

> The easiest time to catch mistakes is early.

pair programming and the articles proposing it do nothing to help catch mistakes early. i would argue that they even delay catching mistakes due to what i'd call deconstructive interference during the implementation process.

there are plenty of much more systematic ways to catch mistakes earlier than just slapping pair programming onto the software process.

Re: On Pair Programming

#82

Post by kstenerud »

I'm sure pair programming is great for certain personality types, but please do not treat it as a panacea.

I've done pair programming enough now in my career to be able to say that it stifles me, interrupts my flow, kills my creativity, decreases my productivity, and leaves me exhausted at the end of the day. I don't necessarily think it's a bad idea for certain people, but I resent it when it becomes a blanket policy. In fact, I've left jobs that started requiring pair programming.

There's a reason why it's only received tepid acceptance in industry.

If it works for you, great. But don't force it on me.

Re: On Pair Programming

#83

Post by cgrealy »

jacques_chester wrote: post #70
cgrealy wrote: post #68

Earlier quoted context omitted.

Fundamentally different to software development on both counts. Aviation and surgery are basically real-time activities. If you make a mistake in either, the consequences are dire. Also, in aviation, it's about redundancy... if there's an issue, it's not like you can wait while someone else steps in. Software is not like that. Your code almost never goes straight into prod (unless you have really aggressive CI/CD!).…

Software mistakes can be pretty dire and if you want to ensure quality, in practice, you will want different eyes to look at the code. Which also lends redundancy, if someone wishes to move on. The easiest time to catch mistakes is early.

> Software mistakes can be pretty dire

Absolutely, but again, they don't happen as you're coding, unlike aviation or surgery.

> if you want to ensure quality, in practice, you will want different eyes to look at the code

Totally agree, but that's an argument for code review, not pair programming. PP is a way to do code review, but I'd argue it's not a very good way, since you're asking the authors to review the code.

> The easiest time to catch mistakes is early. TDD and CI are a more effective way of doing this.

Re: On Pair Programming

#84

Post by craig »

zrail wrote: post #42
lifeisstillgood wrote: post #31

As a "senior" the thing I find about pair programming is that it forces code review - it's waaay too easy to blip over code in a review. It really is higher quality code review but boy it smashes productivity with a frying pan and keeps hitting it. Pair programming - bad for startups that want to hammer out quick code, bad for enterprises that want to hit deadlines on stretched resources. It's a tough one to argue fo…

I’ve done ping pong / tennis programming before and it was honestly one of the most enjoyable experiences at that particular job. It helped that I was a junior developer pairing with one of the most senior developers at the company, who also happened to be very enthusiastic about what we were working on.

Yeah, I hadn't heard of that style before, it soundw really fun and seems like a good approach when you have a well defined feature you want to get done quickly.

Re: On Pair Programming

#85

Post by chownie »

blunte wrote: post #41
mr_custard wrote: post #12

I read through this quickly, but I couldn't find any mention of pair programming not being suitable for sensitive and introverted people - especially those that suffer from anxiety and other mental illnesses that can be made worse by the stress of pair programming. Whilst the article mentions that it "can be hard and stressful" there is still the assumption that most people are more or less the same in terms of menta…

It's not even an issue of "mental resilience". Pair programming, like any other close human interaction, is strongly weighted toward the most aggressive or insensitive (or autistic) personality. And in the tech world, it's very easy to encounter people more weighted toward the autistic end of the spectrum. Pair one of those with one of the HSP people, and you have a really shitty combination. The HSP will expend most…

Just a heads up, HSP is often comorbid with autism as are plenty of other atypical sensory processing manifestations.

Re: On Pair Programming

#86

Post by chownie »

mr_custard wrote: post #12

I read through this quickly, but I couldn't find any mention of pair programming not being suitable for sensitive and introverted people - especially those that suffer from anxiety and other mental illnesses that can be made worse by the stress of pair programming. Whilst the article mentions that it "can be hard and stressful" there is still the assumption that most people are more or less the same in terms of menta…

I think it's endemic of larger open plan office style organisations. They have (unintentionally?) self-selected out those with sensory processing issues plus some forms of autism just by the way the workplace is shaped. So perhaps that's why the concerns stated in the article don't take people with SPD/autism/other related issues into account.

Pairing causes the social part of my brain to activate which is fine, but I cannot also think analytically in real time while speaking. To do so is somewhat stressful and that stress just mounts up the longer the pairing session lasts.

I was diagnosed autistic at the end of the last year, because I was going to therapy to deal with suicidal ideation caused by the anxiety I was carrying around with me from work. A lot of that is from long sessions of intense pairing leaving me essentially bankrupt of energy to use in my personal life.

There's just so many different non-programming things to keep track of for me as an autistic person while pairing

• Am I giving good input as the coordinator?

• Is my language acceptable?

• Is my tone correct?

• When pairing my mind goes blank for 2-5 seconds at a time and it can strike in the middle of a line, so I forget what I was trying to do and have to re-read the previous lines to remember, does this give my co-workers the impression I'm inept?

• Social anxiety causes hand tremors which make it difficult to type. Expressing thoughts now takes an inordinate amount of time to register via keyboard. Is my coordinator getting frustrated by this? Would it be rude to ask them to take over? Should I do this or is it better to persevere?

Pairing plus frequent high population meetings equals a workplace that's nigh on inhospitable for people like me with sensory processing disorders. Even though I'm sure I'm capable of the meat of the work I cannot do it without the extra steps my company mandates, and these steps reduce my capability in the areas I do exceed!

Re: On Pair Programming

#87

Post by tsss »

blunte wrote: post #41
mr_custard wrote: post #12

I read through this quickly, but I couldn't find any mention of pair programming not being suitable for sensitive and introverted people - especially those that suffer from anxiety and other mental illnesses that can be made worse by the stress of pair programming. Whilst the article mentions that it "can be hard and stressful" there is still the assumption that most people are more or less the same in terms of menta…

It's not even an issue of "mental resilience". Pair programming, like any other close human interaction, is strongly weighted toward the most aggressive or insensitive (or autistic) personality. And in the tech world, it's very easy to encounter people more weighted toward the autistic end of the spectrum. Pair one of those with one of the HSP people, and you have a really shitty combination. The HSP will expend most…

I sure am glad I never have to do pair programming with someone like you.

Re: On Pair Programming

#89

Post by jacques_chester »

cgrealy wrote: post #83
jacques_chester wrote: post #70

Earlier quoted context omitted.

Software mistakes can be pretty dire and if you want to ensure quality, in practice, you will want different eyes to look at the code. Which also lends redundancy, if someone wishes to move on. The easiest time to catch mistakes is early.

> Software mistakes can be pretty dire Absolutely, but again, they don't happen as you're coding, unlike aviation or surgery. > if you want to ensure quality, in practice, you will want different eyes to look at the code Totally agree, but that's an argument for code review, not pair programming. PP is a way to do code review, but I'd argue it's not a very good way, since you're asking the authors to review the code.…

> Absolutely, but again, they don't happen as you're coding, unlike aviation or surgery.

When do they occur?

> PP is a way to do code review, but I'd argue it's not a very good way, since you're asking the authors to review the code.

I'd argue that it is a good way, based on my experience of both methods. Code reviews are better than winging it, but given the choice between a PR-and-review process and pair programming with trunk development, I'd take the latter every time.

I agree with the virtues of TDD and CI, I see pair programming as a useful way to help with TDD.

Re: On Pair Programming

#90

Post by jtaft »

All around pretty good article. Never thought about using the pomodor technique while pair programming.

The part about "informal hierarchies" threw me off, and comes off a bit sexist and racist to me. I read this as "hierarchies that are generally recognized/accepted by the public". I don't believe Fowler intended it to read this way. I think it's okay however to recognize people may have interpersonal issues, for a wide range of reasons.

Post reply on HN