Live data from Hacker News

Pair Programming Antipatterns

tuple.app

121–130 of 136 posts

Re: Pair Programming Antipatterns

#121
post #117

Earlier quoted context omitted.

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

If you don't have time to review, would you have time to pair? I think time constraints are a deeper problem

Re: Pair Programming Antipatterns

#122

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.

I don't believe pair programming is the only way to develop great code--not by a long shot--but there are certainly examples.

Early Google's success came from substantial pair programming by Jeff Dean and Sanjay Ghemawat.

Some say Google wouldn't have been successful without this pair working together how they did.

https://www.newyorker.com/magazine/2018/12/10/the-friendship...

Re: Pair Programming Antipatterns

#123

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.

Some projects at Google such as MapReduce, Google File System and TensorFlow were written by Jeff Dean and Sanjay Ghemawat while pair programming.

More details, in the form of a long form article, here: https://www.newyorker.com/magazine/2018/12/10/the-friendship...

Re: Pair Programming Antipatterns

#124

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.

I don't believe pair programming is the only way to develop great code--not by a long shot--but there are certainly examples. Early Google's success came from substantial pair programming by Jeff Dean and Sanjay Ghemawat. Some say Google wouldn't have been successful without this pair working together how they did. https://www.newyorker.com/magazine/2018/12/10/the-friendship...

The article paints them like a married couple doing a mind meld. That's impossible to duplicate by making programmers work as a pair. I'd expect the opposite to happen much more often; two programmers forced to share the same monitor and keyboard would start to dislike each other intensely.

Re: Pair Programming Antipatterns

#125

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

Con: almost no one likes doing this and you'll bleed talent

Con: you're spending literally double on engineers for the same amount of work done

Re: Pair Programming Antipatterns

#126
I haven't physically paired in years. Even before the pandemic I'd often be screen sharing with someone across the table from me. We'd just be positioned where we could see each others' faces and our own screens.

These days it's all fully remote. And that's worked out incredibly well since my team has gotten more and more geographically dispersed. The few that were before are now always in the loop.

I haven't done it full time in a while because my responsibilities other than implementation take too much time.

I'm old in my team and when I can, it works well for me. I share my experience, keep software focused, etc. The younger, high performers teach me new tools and tech. The fresh folks learn more how to think and do work from us. Stuff like that it's not just about making something work, but making something maintainable. I probably teach as much backspacing through a "clever" idea I had, than by writing anything. That and how to break a problem into chunks. Then reevaluate that and make it clean.

Pairing is also great for the more ops side of things. I think in a lot of ways you get even more bang out of it there than programming. Have 1 person do the work and a newer person improve the docs as they go. Then flip for the next iteration, with the new person driving and the experienced one helping and tweaking docs. Call out places where automation could replace procedure and get them in the backlog to be prioritized later. The same pair can pick up those stories when they come back around.

I have experienced some of the pains of this list. I worked with a guy who I joked "painted" code. Lines just growing and shrinking like a horizontal EQ. It was dizzying and unpleasant. I often just checked out and pointed out missing braces every once in a while.

Same guy brings up an issue not mentioned here for physical pairing: make sure you bathe. Ugh.

Also, make sure you're rotating teammates. Sticking in 1 pair can be nice if you like the person... for a while. But it can ruin a friendship if you do that for months.

I think the real keys to success there are in luck and management's hands. Make sure you have a mix of maturity and skill sets, and have engaged curious people. Slackers and, uh, "dim" people drag everyone's morale down more in an environment like that. I've lost those teammates and seen team productivity grow. At the same time, it's hard for a team full of people with little to learn from each other to stick with it. It's more engaging when you're teaching or learning or ideally both.

Re: Pair Programming Antipatterns

#127
post #36
post #32

Earlier quoted context omitted.

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.

And I would be 120 % with you if you said

> 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 requires a second pair of eyes e.g. through code review or pairing to produce quality work.

But that's not what the comment I responded to said!

Re: Pair Programming Antipatterns

#128

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 know it's anecdotal but this doesn't happen in my team. Our pairing culture isn't oriented at producing more but higher quality code, and it generally tends to achieve both.

Or, to turn it around, rushing tasks doesn't seem to be an issue of solo vs pair or mob programming.

Re: Pair Programming Antipatterns

#129
post #4

We tried out Live Share (collaborative editing) during pair and mob programming sessions. I enjoyed it a lot - made it feel like a multi-player game. Sometimes it did allow for the equivalent of a pair programmer taking over the keyboard rather than explaining how to solve a problem. I’m curious if anyone has any Live Share patterns / anti-patterns.

I used to do a fair amount over LiveShare and we would adapt depending on the relationship we had. It got more interesting the more level we were.

One of the more successful patterns that came out was to: talk about the goal, write out the code that acted as interfaces between the two of us, and then split up and tackle two things at once. That might have been code vs tests, backend vs frontend, migration vs adapting existing code. We would often then swap and discuss what we'd done (and we might be asking little questions as we go to help refine each other's approach), add improvements or plug gaps and then finally give it a good end-to-end run through with some exploration.

We were working together on the problem, asynchronously, and you'd be surprised how little there were occasions where a big assumption at the beginning was missed and made us go off in different directions. This was nearly always caught early as we talked whilst we worked on our separate areas and had a quick glance at what the other person was writing. I'm convinced that we caught them faster than if I was alone as we had the opportunity to think about the problem from multiple perspectives at once.

Re: Pair Programming Antipatterns

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

Mindblown... I do this all the time... wow never thought about sharing a keyboard with somebody else. Blindspot.
Post reply on HN