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

Pair Programming Antipatterns

tuple.app

Post reply on HN
Print view View original

111–120 of 136 posts

Re: Pair Programming Antipatterns

#111

Post by rajin444 »

steelframe wrote: post #110

I used to be diametrically opposed to pair programming back when I was a junior developer. These days I often find myself parachuting into troubled code bases and trying to fix technical debt while under time pressure to launch a new feature. I often see things that, I can only imagine, were written by some junior dev trying to impress their boss by just hacking something together and throwing it over the wall. More…

Code reviews prevent this as well, without all the overhead incurred by pair programming.

I think pair programming has its uses, but unless the 2 working together are on the same level it's really hard to get into "flow".

Re: Pair Programming Antipatterns

#112

Post by ParetoOptimal »

girafffe_i wrote: post #46
gregkerzhner wrote: post #7

Pairing is great for some tasks, like higher level design and whiteboarding sessions. But when it comes to implementation (coding) time I really dislike it. I think ultimately, at the end of the day, I expect and hope that every human I work with is a competent, solid individual contributor and does not require a co-driver to produce meaningful work. I definitely see the value in pairing for imbalanced situations (ju…

I've been trying to collect more sentiments on when people dislike pairing, and for what underlying reasons. Very curious to hear if you've thought about ego being apart of your position: if two minds can work through a design or implementation faster, but at the cost "I didn't get to figure this out myself" then you are prioritizing some personal puzzle solving pride over overall project efficacy. Maybe this doesn't…

> you are prioritizing some personal puzzle solving pride over overall project efficacy.

Esteem and self-actualization are a part of maslows hierarchy of needs, I don't think this case is as simple as "pride".

Re: Pair Programming Antipatterns

#113

Post by steelframe »

bartread wrote: post #105
ryanbrunner wrote: post #26

Earlier quoted context omitted.

> I think ultimately, at the end of the day, I expect and hope that every human I work with is a competent, solid individual contributor and does not require a co-driver to produce meaningful work. IMO this is a very wrong way to look at pairing. It's not about one person being incapable of delivering a solution on their own, it's that having multiple perspectives on the code will lead to a higher quality and more we…

> it's that having multiple perspectives on the code will lead to a higher quality and more well designed product. Will it though, when those multiple perspectives are enforced through pair programming? Like a lot of agile cargo-culting, pair programming often seems like software development for extroverts. Those of us who are introverts, and got into software development because it's interesting work which suits our…

> I prefer to program alone.

I think a developer has to earn that privilege. Often times developers use the "just let me do my own thing by myself" line to push code they know is crap, just because they don't get the same level of scrutiny and accountability through an asynchronous code review. Asynchronously, the code reviewer isn't easily able to see the author's thought processes as they constructed their code, so they don't really know whether the author's way of solving the problem is reasonable given the context without putting in significantly more effort into reading the entire context in which the change was written.

After having dealt with mountains and mountains of technical debt in my career, I'm firmly of the opinion that every developer should go through a period of pair programming with a more senior developer. Maybe they can do it for their first quarter with the company. At that point, if the senior developer signs off, they can acquire the right to code independently if they so desire.

Re: Pair Programming Antipatterns

#114

Post by okareaman »

Can someone point me to a great work of software that was written by two people simualtaneously collaborating like Lennon and McCarthy writing songs? I never see any evidence given that pair programming is a better way to code.

Re: Pair Programming Antipatterns

#115

Post by steelframe »

rajin444 wrote: post #111
steelframe wrote: post #110

I used to be diametrically opposed to pair programming back when I was a junior developer. These days I often find myself parachuting into troubled code bases and trying to fix technical debt while under time pressure to launch a new feature. I often see things that, I can only imagine, were written by some junior dev trying to impress their boss by just hacking something together and throwing it over the wall. More…

Code reviews prevent this as well, without all the overhead incurred by pair programming. I think pair programming has its uses, but unless the 2 working together are on the same level it's really hard to get into "flow".

> Code reviews prevent this as well, without all the overhead incurred by pair programming.

I'm a big believer in correcting errant behavior in the moment. Simply the presence of an overseer can coerce a developer to avoid taking shortcuts with the hope that it might go overlooked in an asynchronous code review.

Re: Pair Programming Antipatterns

#116

Post by ParetoOptimal »

thrower123 wrote: post #98

Forced pair programming is an antipattern. It's a recipe for burning your best workers. You had better hope that the oft-touted knowledge transfer benefits of pairing are real, because you are going to have to deal with the turnover.

> Forced pair programming is an antipattern. It's a recipe for burning your best workers.

I won't say I totally disagree, but what are your reasons for thinking this?

Re: Pair Programming Antipatterns

#117

Post by fao_ »

rajin444 wrote: post #111
steelframe wrote: post #110

I used to be diametrically opposed to pair programming back when I was a junior developer. These days I often find myself parachuting into troubled code bases and trying to fix technical debt while under time pressure to launch a new feature. I often see things that, I can only imagine, were written by some junior dev trying to impress their boss by just hacking something together and throwing it over the wall. More…

Code reviews prevent this as well, without all the overhead incurred by pair programming. I think pair programming has its uses, but unless the 2 working together are on the same level it's really hard to get into "flow".

Do they?

I am on a team of two, and yet, I rarely have time to audit code that my fellow has written, simply because the rest of the day demands other tasks to be focused upon

Re: Pair Programming Antipatterns

#118

Post by donw »

reflexco wrote: post #18
donw wrote: post #12

The entire guide just worth a read, even if you’re an experienced pair. Lots of great patterns. We do full-time pair programming in my teams, and this guide is part of our “starter pack” for documentation.

Great resource I agree. The guide is concise and could seem obvious to many peeps, but it made me reflect about my own pair programming sessions and notice I likely failed at a bunch of those points.

The same. I've been pairing for probably close to a decade now, and this guide helped me to reflect on my own style, and gave me a few points to refine as well.

As an aside, one of the things I make sure to do with new hires is to cover "beginner's mind". Just because you've got ten years on the iron doesn't mean you can't learn something new, and that something new might just be from the grass-green new guy that joined last week.

Likewise, for the new guys that think they're hot shit because they've got a degree from McSmartypants University doesn't mean you actually know anything. Don't just take things on an "I said so" basis, but also don't discount the value of experience.

When you run into a new idea: use active listening to ensure you understand it, and explore its ramifications. Poke and see where it falls down, and where it doesn't. You'll avoid a lot of bullshit this way.

Re: Pair Programming Antipatterns

#119

Post by ardit33 »

steelframe wrote: post #110

I used to be diametrically opposed to pair programming back when I was a junior developer. These days I often find myself parachuting into troubled code bases and trying to fix technical debt while under time pressure to launch a new feature. I often see things that, I can only imagine, were written by some junior dev trying to impress their boss by just hacking something together and throwing it over the wall. More…

That's what code reviews are for. You don't need pair programing for that. Places like google go even beyond by having a 'readibility' pass score for the code to be able to ship.

Pair programing is something from the early 2000s, where code review tools were non-existent (I remember, people would just email diffs to each other), back in the day.

Re: Pair Programming Antipatterns

#120

Post by Veuxdo »

steelframe wrote: post #113
bartread wrote: post #105

Earlier quoted context omitted.

> it's that having multiple perspectives on the code will lead to a higher quality and more well designed product. Will it though, when those multiple perspectives are enforced through pair programming? Like a lot of agile cargo-culting, pair programming often seems like software development for extroverts. Those of us who are introverts, and got into software development because it's interesting work which suits our…

> I prefer to program alone. I think a developer has to earn that privilege. Often times developers use the "just let me do my own thing by myself" line to push code they know is crap, just because they don't get the same level of scrutiny and accountability through an asynchronous code review. Asynchronously, the code reviewer isn't easily able to see the author's thought processes as they constructed their code, so…

Who should decide this? Is it based on level? Degree?
Post reply on HN