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

111–120 of 121 posts

Re: On Pair Programming

#111

Post by nikofeyn »

jacques_chester wrote: post #93
nikofeyn wrote: post #80

Earlier quoted context omitted.

those aren't analogous, like at all. or actually, they are analogous, just not in the sense you mean, as they don't serve as examples of "pair ". for both pilots and surgeons, no one is doing the same job at the same time. pilots and surgeons, when performing on the same flight or surgery, have different roles, and it's actually extremely important that they stick to and abide by those roles. you know, because it's h…

> for both pilots and surgeons, no one is doing the same job at the same time. Do you think pair programmers are literally bashing the keyboard simultaneously? Your point, as I read it, wasn't that "only programmers do pair programming". That's as trite as "only surgeons do pair surgery" or "only aviators do pair aviation", because it includes the profession. It's that only programmers doing any kind of assigning two…

> Do you think pair programmers are literally bashing the keyboard simultaneously?

that's how the article and other articles define it: two people sitting at the same machine writing code. what is your definition?

my point was indeed: what other industry practices "pair " on the same task?

and why would it be the second? we're literally talking about pair programming here, not just cooperative work.

Re: On Pair Programming

#112

Post by nikofeyn »

jacques_chester wrote: post #91
nikofeyn wrote: post #81

Earlier quoted context omitted.

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

My experience is that it does catch mistakes early. And it's not mutually exclusive of other ways of spotting errors, it's reinforcing.

with pair programming, you have two people supposedly in the same head space, if it's working as sold, writing code. the benefit of tests and code reviews is that they come from a different head space than what the code was written in.

Re: On Pair Programming

#113

Post by rabidrat »

nikofeyn wrote: post #111
jacques_chester wrote: post #93

Earlier quoted context omitted.

> for both pilots and surgeons, no one is doing the same job at the same time. Do you think pair programmers are literally bashing the keyboard simultaneously? Your point, as I read it, wasn't that "only programmers do pair programming". That's as trite as "only surgeons do pair surgery" or "only aviators do pair aviation", because it includes the profession. It's that only programmers doing any kind of assigning two…

> Do you think pair programmers are literally bashing the keyboard simultaneously? that's how the article and other articles define it: two people sitting at the same machine writing code. what is your definition? my point was indeed: what other industry practices "pair " on the same task? and why would it be the second? we're literally talking about pair programming here, not just cooperative work.

One person is sitting at the machine, the other is sitting beside them. Like how one person is flying the plane, the other is sitting beside them. Pilot/navigator is a common role division. In pair programming, the person at the keyboard is doing the minutiae of the immediate task at hand (the pilot), while the other person is thinking through the next steps or how it fits into the whole (the navigator). They are not actually typing at the same time.

Re: On Pair Programming

#114

Post by Tainnor »

Pair programming is by no means "crucial".

It is an approach that probably works quite well in some contexts and some teams. In other team, different approaches work.

In the end what matters is that the team is highly motivated, has a strong sense of ownership and takes appropriate measures to reduce defects. How it achieves that doesn't really matter from a business POV and is more a subjective preference. In my team, we mostly achieve this through extremely thorough code reviews that dig into a lot of details and that works well for us.

edit: another thing that we do is careful discussion and planning of features (where we will sit together in a small group and discuss approaches) and, for more complex things, architecture decision records (similar to RFCs) that get reviewed before they are implemented.

Re: On Pair Programming

#115

Post by Mike12398 »

jacques_chester wrote: post #96
Mike12398 wrote: post #78

Earlier quoted context omitted.

Coding is NOT a real-time procedural performance activity, and thus can not be compared to aviation or surgery. Code reviews, collaboration on architectural decisions, and QA catch mistakes as early as necessary.

All these professions require a mix of procedural and declarative skill. Pilots and surgeons aren't professional athletes, they rely on enormous amounts of declarative knowledge. The easiest time to catch a mistake is when it's made, which is as true of surgery or flight as of software development. That's why I rely on type systems, tests and whenever I can, someone next to me asking "why?".

Read again: Coding is NOT a real time performance activity, thus can not be compared with aviation and surgery in that way. Pairing is a requirement to do aviation and surgery reliably and accurately, but is completely optional for coding well, and arguably reduces quality of code in many cases.

Re: On Pair Programming

#116

Post by mnm1 »

chownie wrote: post #86
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…

> Pairing causes the social part of my brain to activate which is fine, but I cannot also think analytically in real time while speaking.

This happens to me in whiteboard interviews and other high anxiety situations. There is no need to be atypical or suffer any disorder to feel this. Undoubtedly, this likely happens to a big chunk of the population given the disgust most people have for whiteboard interviews and other anxiety inducing situations.

Re: On Pair Programming

#117

Post by iudqnolq »

iudqnolq wrote: post #53
22c wrote: post #47

Earlier quoted context omitted.

Not exactly what you asked for, but I have had success with pair programming using VS Code Live Share[1] and Mumble for VoIP[2]. I don't think video is particularly important when you're both seeing the same screen and able to talk about it. [1] https://docs.microsoft.com/en-us/visualstudio/liveshare/use/... [2] https://www.mumble.info

I've been trying this recently, but find it hard to debug issues because I can't see the output of the program being run or use a debugger on it. We got to the point of sending Dropbox links to screenshots of chrome with the devtools console open, which seems absurd. Maybe chrome remote debugging could help? Maybe I'm just not good at writing code correctly the first time, but when I program I usually fix at least on…

Edit: Completely missed that VS Live Share has a solution for this. Amending my complaint to be about the discoverability of the UX

Re: On Pair Programming

#118

Post by downerending »

cgarvis wrote: post #39
downerending wrote: post #27

Earlier quoted context omitted.

Possibly, but the time and energy it would take to do that would be far better spent brushing up on new and not-recently-used technologies. Ability to produce quality code is far down the list of my weaknesses, and life is short.

Goal of pair programming isn’t better quality code, that is a side effect, but better quality solutions. It’s one of those 1+1=3 types of things. It is also a great training tool. Can’t tell you how many times I’ve had junior engineers ask me about something that I thought was common knowledge or wouldn’t have thought to mention cause I thought it was trivial. It’s a tool in your toolbox. Don’t use it on every proble…

I'm happy to discuss things at the water cooler or in front of a whiteboard, and this seems to be an efficient way to discuss design or help junior people. But sitting next to someone at length is rarely helpful, to me.

Re: On Pair Programming

#119

Post by ken »

jacques_chester wrote: post #62
nikofeyn wrote: post #57

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.

And yet in software, the people in high-stakes domains who really care about quality (like the Lockheed shuttle group) don't use pair programming. Has any team using pair programming ever had a defect rate as low as 1 bug per half million lines of code? Or even within an order of magnitude of that?

For real quality, you need detailed specifications before code is written, an independent verification team, and root cause analysis on every bug. Otherwise, you're still down at CMM level 1 or 2 ("chaos, and slightly better than chaos").

Pair programming is putting a second pair of eyes on chaos to try to emulate an actual process. It's the Hyper-Threading of development processes. We're too cheap to implement what we all know we really need, so here's something that's better than nothing, for a small fraction of the cost, because it repurposes what we have on hand.

Re: On Pair Programming

#120

Post by cgrealy »

jacques_chester wrote: post #89
cgrealy wrote: post #83

Earlier quoted context omitted.

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

> When do they occur? When the code is run, not when it’s written.

> I'd argue that it is a good way, based on my experience of both methods.

And with similar experience, I’d disagree. Paired programmers are focused on writing the code not reviewing. The whole point of code reviews is to let someone divorced from the problem solving process objectively the code.

Post reply on HN