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

21–30 of 136 posts

Re: Pair Programming Antipatterns

#21

Post by kqr »

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.

Are you against co-pilots in aircraft for the same reason?

Re: Pair Programming Antipatterns

#22

Post by sgillen »

kqr wrote: post #21
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. Are you against co-pilots in aircraft for the same reason?

I think this is a false equivalence. If a programmer has a medical emergency during their working hours that’s terrible but doesn’t put others in danger.

Re: Pair Programming Antipatterns

#23

Post by gregkerzhner »

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 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 produce their best work when they can focus, alone.

If pairing works for you, then that’s great, but it needs to be consensual and optional.

The problem with pairing is that it tends to be championed and enforced by more social workers (especially managers), and forced on the less social ones, who are often not in a position to refuse.

Re: Pair Programming Antipatterns

#25

Post by soneca »

jatins wrote: post #15
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…

Google's Jeff and Sanjay are famous for pairing together, and most would think they are fairly competent people. Pairing brings a new perspective to the problem and, for me, the social element is also valuable in that you also build relationships by pairing. Though it's completely possible what you and I think when we say "pairing" might be different. For example, the ability to not check Twitter feed would only be a…

If they are pairing to do high level design, then you are not disagreeing with GP

Re: Pair Programming Antipatterns

#26

Post by ryanbrunner »

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 well designed product.

You could use the same argument you're using to say we shouldn't do code reviews, because we should trust that every developer is competent.

Also, at least in my experience, design isn't primarily or even mostly confined to an initial design phase. Most of the 'design' of a problem occurs when you're actually coding.

Re: Pair Programming Antipatterns

#27

Post by codeflo »

“Allowing unproductive distractions” is one of the major reason why I think home office is fundamentally less productive, no matter how much people have come to like it. Pair programming through screen sharing works fine on a technical level, but you can’t turn off children.

Re: Pair Programming Antipatterns

#28

Post by jenscow »

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…

That's your problem with pairing - you're able to think deeply, so pairing is a hindrance to you.

The majority of developers, in enterprise at least, tend to write the first piece of code that enters their head, and they only consider the immediate problem. The code Just Works, so pairing is sufficient for them.

Whenever I've driven a pair session, I tend to go back and finish it - fill in the blanks: handle edge cases, tests, security, a11y, etc.

Pairing is a good tool for creating prototypes or combining ideas, and in imbalanced situations like you say. But for long-term stable production, code reviews are generally more suitable.

Re: Pair Programming Antipatterns

#29

Post by Abroszka »

I'm not sure about pair programming. I never really understood why we stop at two people. Why not have 3 or 5 people working together? And indeed that's what we do when for example doing system design and it's incredibly useful.

Writing mundane code in pairs sounds like a brute force solution that should be solved by training, higher quality code scanners or other code quality tools.

Re: Pair Programming Antipatterns

#30

Post by tialaramex »

BoardsOfCanada wrote: post #11
pooya72 wrote: post #6

I've never pair programmed before, so if anyone has any advice like this that they're willing to share it would be helpful.

As someone who has programmed for a very long time but only done pair-programming a lot last few years, the big things in my opinion is: - If you're the driver (handles the typing), don't allow yourself to be stressed and just type things someone else tells you to type. - Language is really bad at comunicating where to make a change on a gigantic screen of text, expect yourself and others to become a bit frustrated a…

I would guess that Keep Talking And Nobody Explodes would be a good exercise to learn what the problem is without getting into domain specific skills.

https://keeptalkinggame.com/ (ideally play this with the defusal in VR)

KTANE even has (to a greater extent, and for humour) the ambiguities that can trouble talking to somebody about programming, like offering "YES", "AND", "&" and "NO" as options somebody needs to pick quickly.

Post reply on HN