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

Against Pair Programming

matt-rickard.com

Post reply on HN
Print view View original

61–70 of 180 posts

Re: Against Pair Programming

#61

Post by pyjarrett »

I use pair programming from time to time when there's a subject matter expert who can provide assistance or clarification on something.

However, I'm a super introvert and pair programming is absolutely exhausting for me. The notion that this should be done continuously doesn't account for the human factors involved. It's hard to communicate this to other people, but if I had to do this for 8 hours a day, 5 days a week, the stress would burn me out incredibly quick. I'd walk out the minute any company tried to impose this on me for even a couple days a week.

Re: Against Pair Programming

#62

Post by ehnto »

lkois wrote: post #30

I recently took a junior role working on a decades old legacy codebase, in which all developers and almost everyone who had touched the code had quit in the previous year. The week I joined, the most experienced remaining developer put in his 2 weeks notice, after a 9 month tenure. The next most experienced had only been there a month or two. We then spent every day of the next 2 weeks on near 8 hour videocalls devel…

Transferring arcane project knowledge is the best use case of pair programming I think. That and bugsquashing a complex codebase. I could never imagine developing features with pair programming, but the prior two situations really do benefit from a bit of a mind melding.

Re: Against Pair Programming

#63

Post by Veuxdo »

gherkinnn wrote: post #58
Veuxdo wrote: post #34

Do other professionals do pair _______? Pair writing? Pair hairdressing? Like standups and pointing, it feels like a patronizing exercise we only force on devs.

Absolutely. Penn and Teller develop their tricks together. Two-seater attack aircraft are a thing. Rally drivers have a driver and a navigator. Apprentices are taught in part through pairing. > Like standups and pointing, it feels like a patronizing exercise we only force on devs. There's truth in that. On one hand, many of our practices is formalised problem solving under the (non-)constraints of software. Others ar…

I think the difference is that the other activities you mentioned were execution/performance, while software development is a combination of engineering and creativity.

Re: Against Pair Programming

#64

Post by shultays »

In my experience putting two programmers on same task can even lead to less than 1x the output of a single person. People often argue about relatively pointless things while neither decision is not wrong. A single programmer would just go ahead and pick their own way and second one wouldn't consider it as important to raise during a review.

Pair programming is great for new employees. But I am not sure either how much value they add over properly done design or code reviews when it comes to stability and putting two capable programmer on the same task sure sounds a waste of time.

I think people that pairs up on same tasks/epics should try to work on different parts on parallel and try to sync up on what and roughly how they want to do stuff.

Re: Against Pair Programming

#65

Post by IanCal »

stevage wrote: post #35

Ha. I dislike pair programming as much as anyone, but this argument is really weak. It doesn't sound like he has actually had much experience of it, and is just judging it from the outside. But let's go through some points: >Since we are employing two programmers to do work on the same keyboard at the same time, the output of pair programming must be greater than 2x the output of a single programmer to make sense. In…

Yeah it would be weird to me if programming is some unique task where two people solving a complex problem together is a bad thing.

I'd not done it much in the past but recently seen it done more and participated more - each time it's been useful. I paired to deploy some work, and having both of us work together was really helpful as we could talk through issues we were seeing as we went and it taught me more about infra & them more about the project.

Re: Against Pair Programming

#66

Post by ehnto »

rr808 wrote: post #41
lkois wrote: post #30

I recently took a junior role working on a decades old legacy codebase, in which all developers and almost everyone who had touched the code had quit in the previous year. The week I joined, the most experienced remaining developer put in his 2 weeks notice, after a 9 month tenure. The next most experienced had only been there a month or two. We then spent every day of the next 2 weeks on near 8 hour videocalls devel…

Nice. How do you sustain this for 8 hours a day though? After 45 minutes my brain starts to sag.

Yeah I could never be on a video call for that long. There is a subprocess in my brain that starts running at 95% when I'm on a video call, like a kind of performance anxiety. I can deal with longer voice calls, but I can't really work during a call so it's only useful for syncing up. A call longer than an hour has probably become inefficient in some dimension.

Re: Against Pair Programming

#67

Post by mhitza »

mihaaly wrote: post #29
mjw_byrne wrote: post #15

Pair programming easily achieves the >2x speed boost though. The driver focuses on the technical details of writing high-quality code, implementation, proper variable naming and so on whilst the navigator keeps track of the overall task, provides extra short-term memory, spots silly mistakes/typos, focuses on business logic etc. So instead of one programmer juggling too much and stalling, getting bored/frustrated, lo…

Developers being unable maintaining both business logic and technical details in head at the same time are usually not hired. Actually this is their stated job description most of the time, translate logic into implementation. If this gives frustration probably better to look for some other occupation. Myself I actually enjoy this quite a bit. For avoiding and catching mistakes is useful but not a guarantee at all es…

> Developers being unable maintaining both business logic and technical details in head at the same time are usually not hired. Actually this is their stated job description most of the time, translate logic into implementation. If this gives frustration probably better to look for some other occupation.

Feels like a reductionist statement. When working on a large codebase (call it legacy even, as everything devolves into legacy code given enough years), it's impossible to keep all the details in your head. Code review can provide the additional context missing to the developer implementing a task, but I'm sure you've been in the same situation before; where a feature change, even small in scope would crisscross multiple files, and without testing it out you're unable to review conformance.

As an example. When I was team lead on a large and legacy SaaS project in the past, I pretty often would pair with other developers on the team, and their input as well as my input had us catch situations that while developing in isolation we could have missed. Even in a standard code review. Because during development we were deeply entrenched in the code and able to often try out multiple approaches for a problem.

Re: Against Pair Programming

#68

Post by sdiupIGPWEfh »

I personally do not enjoy pair programming as a regular practice, but the focus here on performance is misplaced while the pedagogical benefits are swept under the rug. In exchange for some performance, I'd expect gains in team robustness. There are things you learn while participating in solving the problem that you'd never encounter during a design meeting or while doing code review. Subtler design problems and technical dead ends can be caught earlier and save substantial time over the typically async rejection process, leading to more productivity over a longer measure of time.

Re: Against Pair Programming

#69

Post by ehnto »

Stratoscope wrote: post #48
nicodjimenez wrote: post #22

Pair programming can be powerful with the right people and the right problem. It's a situational tool that can speed up progress in certain cases. Sometimes diving deeply into code is scary and having someone else right there can provide a feeling of safety that's conducive to making real progress. Also, sometimes programmers can have complimentary skills that can help them solve hard problems together on the spot. P…

20 years ago I worked for Adobe on the Acrobat team. They brought me in because they needed some Windows expertise to help a team of talented developers who had mostly coded on the Mac. I don't think the term "pair programming" had been invented yet - at least I'd never heard of it - but when I was in the office I often spent a few hours a day on "house calls". People would ping me and I made the rounds advising them…

I had a role as a mentor/go-to-guy for a complicated codebase and had a similar experience. I really enjoyed helping people out and loved the positive interaction, I would never have called it pair-programming and funnily enough we did have some kind of pair programming initiative at the time.

If I were to give any advice to dev leads/teams/management that wants to introduce pair programming, it's good to put people of differing capabilities and expertise together. That way there's some value being added, and you're spreading around the arcane knowledge of your platform.

Re: Against Pair Programming

#70

Post by davidthewatson »

jasode wrote: post #16

When I read a New Yorker article about Google, I was surprised to learn that Jeff Dean and Sanjay Ghemawat do a lot of pair-programming. Excerpt from: https://www.newyorker.com/magazine/2018/12/10/the-friendship... >“I don’t know why more people don’t do it,” Sanjay said, of programming with a partner. >“You need to find someone that you’re gonna pair-program with who’s compatible with your way of thinking, so that t…

Having shared _exactly_ this kind of working relationship with several co-workers over the years, most of whom work at Google now, I'd argue that the problem comes down to counting things that don't count and the difficulty in counting things that actually do count, like execution, flow, shared mental model, vision, and ideation. There is a rhythm that arises from pairs work that I find much more peaceful than my own type-furiously-and-swear-vigorously personal style.

I can work alone effectively being an introvert, but there is no question that the results and impact improve with a pair of talented co-workers who are mutually inclined toward pairs work. I don't think it has to be every time for everything, but when there is consensus on the approach, I see no reason to disallow it because some of the greatest achievements in science have come through this kind of collaboration. If it doesn't work for you, there's no reason to make individual, pairs, or mob programming the only way of working. It's a spectrum of work styles and that's OK.

Post reply on HN