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

31–40 of 136 posts

Re: Pair Programming Antipatterns

#31

Post by pooya72 »

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…

That's helpful, thanks!

Re: Pair Programming Antipatterns

#32

Post by kqr »

sgillen wrote: post #22
kqr wrote: post #21

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

A co-pilot isn't just useful for medical emergencies. They can double-check judgments, decisions, and plans as well. Because people sometimes interpret signals incorrectly or misunderstand contexts.

That can happen to a programmer just as much as a pilot, and it can be even more destructive. You could argue software generally isn't life and death, but who knows? You might end up working on something like curl or sqlite which may well have played part in the implementation of emergency services in some country.

Re: Pair Programming Antipatterns

#33

Post by Chris_Newton »

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.

Indeed, and this is a problem that can affect other “Agile” practices too. Mandatory/permanent pairing is one example. TDD is another. Both can reflect a more general trend to try to break development down into tiny steps.

It’s not that there is no value in developers working together in real time, or in unit tests, or in incremental development and short feedback loops. All of these can be very useful. In my experience, they are often adopted spontaneously by developers even if there is no formal process in place that requires them.

But it’s also important to look at the big picture. You need a coherent vision for the product. You need a consistent domain model that is well understood and shared by both developers and non-developers. You need a reasonable software architecture that provides useful patterns and abstractions but also isn’t afraid to change them as requirements evolve.

Without these things, it’s easy to take a lot of small steps and create an illusion of progress, yet not move efficiently towards your true goal. Increasingly serious problems tend to get shoved under the carpet (sorry, “added to the backlog” or “labelled as tech debt”) until inevitably quality and productivity start to suffer.

You can’t fix those kinds of problems working in the small with only one or two participants.

Re: Pair Programming Antipatterns

#34

Post by vidarh »

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 hate it enough for day to day use that I'd leave a job over it if I was forced to.

It's fine occasionally for training, as you suggest, or for explaining a design to people, but like you I feel it's an encroachment.

Thankfully I'm experienced enough that I can afford to refuse to take jobs that impose it.

Re: Pair Programming Antipatterns

#35

Post by meken »

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.

Re: Pair Programming Antipatterns

#36

Post by jenscow »

kqr wrote: post #32
sgillen wrote: post #22

Earlier quoted context omitted.

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.

A co-pilot isn't just useful for medical emergencies. They can double-check judgments, decisions, and plans as well. Because people sometimes interpret signals incorrectly or misunderstand contexts. That can happen to a programmer just as much as a pilot, and it can be even more destructive. You could argue software generally isn't life and death, but who knows? You might end up working on something like curl or sqli…

That's what code reviews are for.

Unless you're working directly on a live server.

Re: Pair Programming Antipatterns

#37

Post by vidarh »

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…

My experience is that pairing is deeply disruptive to my exploration of a design. It forces me to slow down and verbalise something that I can clearly visualise in my mind, when the fastest way to externalise it for me is often to write the code and show it. I'm happy to walk people through a prototype afterwards and discuss it and if necessary throw the thing away and start over or significant revise it. I'm not happy to have someone disrupt my thinking about a problem while I'm trying to focus.

Fundamentally I tend to think that people who insist pairing is ok to impose on people think everyone is like them, and don't see that it's forcing out people with different ways of thinking and processing problems. Ultimately I think it's bordering on discriminatory in that it's selecting for extroverts who don't burn out by the extensive amount of interpersonal contact pairing forces rather than selecting for results.

For my part I will never work somewhere that imposes pairing. I'd rather leave software development altogether than suffer through that, because it's not worth the exhaustion and the reduction in throughput other than occasionally (e.g. while training someone or walking people through a prototype). Thankfully I have the luxury of not having to take that shit.

Re: Pair Programming Antipatterns

#38

Post by XorNot »

lenkite wrote: post #17
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…

Pair Programming always has some ramp-up "friction" time with a new partner where you get over the awkwardness and embarrassing phases (ashamed to make mistakes in front on each other). And there are some partners you will simply be unable to pair with unless both of you take the time to give each other significant space/time. (ugghh..that sounds like some corny relationship therapy). But when it's going smoothly, wo…

> It all sucks doing it remotely though and frankly not worth it.

I find this perspective wild. I cannot possibly imagine pair programming as productive, or tolerable if it was being done in person.

Whereas doing it using screen sharing tools from the comfort of my home (or private office but who's had one of those recently?) - well I've actually done this, and it worked great. No body hygiene or smell issues to get with, no one snacking or drinking near you, no crowding or extra CO2 and sweat - just a nice tight feedback loop which people can dip in and out of without disruption, join and stop easily etc.

The idea of pair programming with other people physically in the room with you...I can't think of anything more unpleasant.

Re: Pair Programming Antipatterns

#39

Post by Mountain_Skies »

I've done plenty of pair programming informally when one of us were stuck on some hairy bit of code and needed another pair of eyes and some extra brain power to get to a solution but I've never done it in an ongoing formal context. What I've always wondered is if you get the doubling of productivity required to justify having two resources working on the same bit of code? Certainly in blocking situations you can get a huge multiplier on productivity (I'm including quality and correctness in my definition of productivity) but lots of code is mundane stuff that just needs someone to push through and knock it out. Can a pair get the mundane stuff done in half the time of a solo developer?

Re: Pair Programming Antipatterns

#40

Post by samatman »

number6 wrote: post #2

Using two input devices on one PC never occurred to me. Is it just plug and play or does it require some setup ?

Users of laptops routinely plug a mouse and keyboard in, while the original trackpad and keyboard continue to work. We don't think anything of it.

It's the same thing with two 'exterior' keyboards and mice.

Post reply on HN