Live data from Hacker News

On Pair Programming

martinfowler.com

61–70 of 121 posts

Re: On Pair Programming

#61
I have somewhere between moderate and severe social anxiety. Was on a team earlier this year that did 100% pair programming. Was the worst 6 months of my career. I had weekly breakdowns, my mental health got much worse ect. Once I was moved to a different team, my mental health quickly recovered.

Re: On Pair Programming

#62

the thought of pair programming nearly gives me an anxiety attack. the second it’s mentioned in the interview process, it’s an automatic no from me. what other industry or domain does this? none that i know of. first of all, working in pairs creates a problem when there’s disagreement. you need a group of three to five to find agreement in those cases. working in pairs also requires a very tight alignment of style in…

> what other industry or domain does this? none that i know of.

Aviation, some surgeries.

You know, low-stakes stuff.

Re: On Pair Programming

#63
post #48

I have never once been able to look at this and think it was a good idea outside of specific training sessions with specific coworkers for specific purposes. I think programmers should be considered professionals who can do their own work quite well on their own, and held to that standard.

What about pairing strikes you as not considering programmers to be professionals?

I've done a lot of pairing and never felt that I was somehow being slighted or considered incapable. I've felt slighted in cases when I wasn't pairing, though.

Re: On Pair Programming

#64

So while pair programming what happens with the never ending string of distracting Slack messages and diversions? It just seems completely impractical for the environments I’ve had experienced.

I've seen a few patterns at Pivotal. In Pivotal Labs and some R&D projects the team is fully colocated, so Slack isn't necessary for the day-to-day.

To maintain accessibility by remote teams and individuals, most teams will assign an "interrupt pair", who are designated to deal with Slack, walk-by questions and the like.

I have mixed feelings about Slack. It's too addictive. I've enjoyed jousting and joking and forth, but I don't always come out the other side with concrete outcomes.

Re: On Pair Programming

#65
Pair programming is a nightmare for introverted people. Part of the appeal of coding is the relative solitude of the work. I think any company that mandates it is just a place I won't work.

Re: On Pair Programming

#66

Anyone know of a good, open source, cross-platform video conferencing application?

Jitsi looks interesting: https://jitsi.org I've never tried it out, but I am very tempted. Looks pretty clean and modern, with a pure JavaScript WebRTC client, in addition to the usual native apps.

Re: On Pair Programming

#67
My experience of pair programming, which spanned about 4.5-5 years of working for Pivotal Labs and in Pivotal R&D, was pretty much universally positive.

But it's a complex skillset in its own right, hard to learn from a book. And in turn it requires a degree of corporate sanity and cultural safety that is quite rare. It's also a very humbling experience.

Lots of people have had bad experiences, or believe that they would have a bad experience. I just like to place on the record that my experience of pair programming has been amazing and I look forward to the day when I can return to it.

Re: On Pair Programming

#68

the thought of pair programming nearly gives me an anxiety attack. the second it’s mentioned in the interview process, it’s an automatic no from me. what other industry or domain does this? none that i know of. first of all, working in pairs creates a problem when there’s disagreement. you need a group of three to five to find agreement in those cases. working in pairs also requires a very tight alignment of style in…

> what other industry or domain does this? none that i know of. Aviation, some surgeries. You know, low-stakes stuff.

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!). There is always time to correct your mistakes.

Re: On Pair Programming

#69
post #41

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've done fulltime pair programming with dozens of people and not found this to be the case.

Pairing is a skill. Practiced regularly it becomes easier and smoother, like any other skill.

Re: On Pair Programming

#70
post #68

Earlier quoted context omitted.

> what other industry or domain does this? none that i know of. Aviation, some surgeries. You know, low-stakes stuff.

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.

Post reply on HN