Pair Programming Antipatterns • Hacker News Board

Re: Pair Programming Antipatterns

#101

Post by slaymaker1907 » Sun, Mar 06, 2022, 8:23 PM UTC

sidlls wrote: post #67

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…

"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 well designed product." That's what PRs are for. One can't use the same argument to oppose PRs, as you suggest, because of this key difference: in a PR, the person doing the review has (or ought to h…

As the design evolves, this stuff should really be communicated to the rest of the team before the PR. The purpose of PRs should be almost entirely about finding bugs and typos.

Re: Pair Programming Antipatterns

#102

Post by epgui » Sun, Mar 06, 2022, 8:48 PM UTC

meken wrote: post #35

skeletal88 wrote: post #8

I work at a place where we do exclusively pair programming (a software consultancy). A project always has at least one pair. Each workstation has a computer, 2 monitors, 2 mice and keyboards. When someone can't be at the office then we sometimes use Tuple, and it's a great tool, unfortunately still only works on Macs. Pairing works for us because it's more efficient than working alone, less bugs and better thought ou…

Which company do you work for? I researched pair programming companies a while back and didn’t find any.

CircleCI does a lot of pairing.

Re: Pair Programming Antipatterns

#103

Post by gregkerzhner » Sun, Mar 06, 2022, 9:29 PM UTC

whynotminot wrote: post #94

vidarh wrote: post #88

Earlier quoted context omitted.

> I kind of take issue with your assumption that someone with NPD can't pair program. Many can. Many can't. I did not make the assumption you're arguing against here. > If your assumption of an effective pair programmer is that they're always bubbly extroverts with politician-level shmoozing capability, I kind of doubt you've spent any length of time doing it. That was not my assumption at all. You're jumping to unwa…

> That's fine, but it does not change the fact that many people struggle with it. Including people who manage to deal with "normal" communication just fine, but who find the intensity of a pairing unbearable. I can do it, but to me it is intensely uncomfortable to the point that as I've pointed out elsewhere I refuse to be pushed into it - for me it's not a problem, as my career has afforded me the luxury of picking…

Ultimately, I file (mandatory, full time) pairing in the same category as mandatory in-office work, meant to encourage brilliance from random water cooler interactions.

In a perfect world, is a fully engaged in-office employee better than a remote one? I’d say probably yes. In the real world, is a disgruntled, commute tired employee better than a happy remote one? Unknown.

Same with paring. If your team is full of perfectly interchangeable humans drinking the same cool aid, then pairing sounds great. But real humans don’t work like that, and for every person who is boosted by pairing there may be another who is held back by it.

In the end, it’s likely best to allow employees to self select the mode of work which works best for them (location, pairing amount, computer choice) so that they are happy and productive. Any kind of top down mandatory policy on those choices will inevitably be worse than each person’s preferred choice.

Re: Pair Programming Antipatterns

#104

Post by [deleted] » Sun, Mar 06, 2022, 9:33 PM UTC

vidarh wrote: post #82

whynotminot wrote: post #78

Earlier quoted context omitted.

> Having run companies, and hired many dozens of engineers, if you do so you'll end actively discriminating against many types of neuro-divergent people. Apart from the issue of whether or not you can actually show any benefits, you'll be one little conflict away from a lawsuit. "We pair program here--that means actively working with another engineer for 8 hours a day. Is this something you're comfortable with?" "No.…

> What a world. A whole lot of unwillingness to make reasonable accommodations for people based on disabilities will open you up to lawsuits. To imply reasonable accommodations for neuro-divergent people is simply a matter of "comfort" is indeed worth a "what a world" on the same level as refusing to make reasonable accommodations for those who are blind or hard of hearing or in a wheelchair.

[deleted]

Re: Pair Programming Antipatterns

#105

Post by bartread » Sun, Mar 06, 2022, 9:49 PM UTC

ryanbrunner wrote: post #26

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 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 temperaments, don't necessarily appreciate this... at all. I'm not saying I'm unwilling to work with others, or figure out problems together - I have to do this all the time, we all do - but I prefer to program alone.

Re: Pair Programming Antipatterns

#106

Post by whynotminot » Sun, Mar 06, 2022, 10:01 PM UTC

gregkerzhner wrote: post #103

whynotminot wrote: post #94

Earlier quoted context omitted.

> That's fine, but it does not change the fact that many people struggle with it. Including people who manage to deal with "normal" communication just fine, but who find the intensity of a pairing unbearable. I can do it, but to me it is intensely uncomfortable to the point that as I've pointed out elsewhere I refuse to be pushed into it - for me it's not a problem, as my career has afforded me the luxury of picking…

Ultimately, I file (mandatory, full time) pairing in the same category as mandatory in-office work, meant to encourage brilliance from random water cooler interactions. In a perfect world, is a fully engaged in-office employee better than a remote one? I’d say probably yes. In the real world, is a disgruntled, commute tired employee better than a happy remote one? Unknown. Same with paring. If your team is full of pe…

> Ultimately, I file (mandatory, full time) pairing in the same category as mandatory in-office work

I don’t really disagree with this categorization. And there’s a lot of companies that view it as core to their success and culture to have an in person work force.

I may disagree, and I may work elsewhere that suits me better!

That’s sort of why this digression on denying a company the ability to set their own development practices is strange to me. There’s a plethora of options for the work force. Go where you’re in alignment, don’t force bad alignment on the company!

Re: Pair Programming Antipatterns

#107

Post by ParetoOptimal » Sun, Mar 06, 2022, 10:13 PM UTC

slaymaker1907 wrote: post #101

sidlls wrote: post #67

Earlier quoted context omitted.

"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 well designed product." That's what PRs are for. One can't use the same argument to oppose PRs, as you suggest, because of this key difference: in a PR, the person doing the review has (or ought to h…

As the design evolves, this stuff should really be communicated to the rest of the team before the PR. The purpose of PRs should be almost entirely about finding bugs and typos.

What are "draft PRs" for then?

Re: Pair Programming Antipatterns

#108

Post by ParetoOptimal » Sun, Mar 06, 2022, 10:19 PM UTC

eikenberry wrote: post #16

epolanski wrote: post #14

Earlier quoted context omitted.

I have recently switched teams and I'm in one where most programming but trivial tasks are done in pair. I can see lots of pros and few cons: - knowledge sharing, especially business, domain, old code, etc. The biggest stopper in writing software in large organizations is rarely technical difficulty but context - focus. If I'm alone I get distracted much more, music, youtube, socials, I know this is on me, but gettin…

> Overall I think pair programming makes in my, and most organizations produce more work than if the contributors where solo programming. I think this is the key takeaway with one missed point. IMO it definitely does produce more work vs. solo programming but that work is sub-par. The necessary time isn't spent thinking on the tasks but instead the pairing rushing things through with very little thought to design and…

> The necessary time isn't spent thinking on the tasks but instead the pairing rushing things through with very little thought to design and long term maintainability.

I feel like pairing pushes people towards this because both parties feel the need to show they aren't "wasting time" by engines reasonable definition of it.

If you swim upstream and try to work against this, it can cause some friction.

Re: Pair Programming Antipatterns

#109

Post by ParetoOptimal » Sun, Mar 06, 2022, 10:20 PM UTC

gregkerzhner wrote: post #23

eikenberry wrote: post #16

Earlier quoted context omitted.

> Overall I think pair programming makes in my, and most organizations produce more work than if the contributors where solo programming. I think this is the key takeaway with one missed point. IMO it definitely does produce more work vs. solo programming but that work is sub-par. The necessary time isn't spent thinking on the tasks but instead the pairing rushing things through with very little thought to design and…

The part of my brain which thinks deeply and produces elegant solutions simply shuts down when I constantly have to explain my thought process to someone else. I actually have the same problem in pair programming interviews - my brain tends to freeze up and comes up with strange, hacky workarounds at best. Later, when I’m alone and can focus the proper answer usually comes to me. I know there are others like me who p…

> Later, when I’m alone and can focus the proper answer usually comes to me. I know there are others like me who produce their best work when they can focus, alone.

Yeah, I've taken "thinking breaks" during pair sessions for this reason.

Re: Pair Programming Antipatterns

#110

Post by steelframe » Sun, Mar 06, 2022, 10:22 PM UTC

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 and more I wish that code had been written via pair programming, where the other (hopefully more senior and judicious) developer could have, perhaps by only their mere presence, prevented the hack dev from doing what they did.