Pair Programming Antipatterns • Hacker News Board

Re: Pair Programming Antipatterns

#11

Post by BoardsOfCanada » Sun, Mar 06, 2022, 10:46 AM UTC

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 at times, but it's at the difficulty of communicating things, not that the other person is dumb. "And change the type to bool. No not that one. Go to the end of the line, then back to the last bracket. No, the line you were at. Yes. Now go to the last bracket. Change to bool." And then take a second to understand why, asking if necessary, becuase it might get more difficult to understand later.

- It's extremely difficult not to get lost when someone else is navigating between tabs, especially if you don't know the code well (and sometimes even if you do).

Re: Pair Programming Antipatterns

#12

Post by donw » Sun, Mar 06, 2022, 10:56 AM UTC

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.

Re: Pair Programming Antipatterns

#13

Post by nmisko » Sun, Mar 06, 2022, 10:59 AM UTC

I'd be interested in such a write up for remote pair programming. Being remote the likelihood is much higher that the navigator loses focus and answers emails or slack instead. Switching roles more quickly might be the solution. We've tried tools like mob.sh, but the most efficient way seems to be using something like VSCodes liveshare. Unfortunately half of my team uses Intellij and the other half VSCode.

Re: Pair Programming Antipatterns

#14

Post by epolanski » Sun, Mar 06, 2022, 11:02 AM UTC

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 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 getting distracted while pairing is hard and rude. I'm also much more organized and a coworker is much better than a rubber duck.

cons:

- you are blocked from working if a coworkers schedule is not aligned

Overall I think pair programming makes in my, and most organizations produce more work than if the contributors where solo programming.

Re: Pair Programming Antipatterns

#15

Post by jatins » Sun, Mar 06, 2022, 11:05 AM UTC

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 an issue if you are pairing for hours at stretch. While my pairing sessions are rarely longer than an hour.

Re: Pair Programming Antipatterns

#16

Post by eikenberry » Sun, Mar 06, 2022, 11:17 AM UTC

epolanski wrote: post #14

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 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 long term maintainability.

Re: Pair Programming Antipatterns

#17

Post by lenkite » Sun, Mar 06, 2022, 11:24 AM UTC

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, wow, you can code large blocks of code in a few sessions and the structure/design of code comes out looking really good. You can refine each others ideas as you code or even arrive at something better when the flaws are pointed out in the individual approaches.

I have also tried tri-programming also where a third guy joins in for miscellaneous stuff like quick exploration, how-to-do-that's or research activity while the primary pair focuses on the main backlog. This is helpful because when you are in the groove, you really don't want to get side-tracked.

I am a social, introverted recluse and even I found pair-programming objectively useful.

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

Re: Pair Programming Antipatterns

#18

Post by reflexco » Sun, Mar 06, 2022, 11:31 AM UTC

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.

Re: Pair Programming Antipatterns

#19

Post by psysharp » Sun, Mar 06, 2022, 11:43 AM UTC

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…

When a problem is new and fresh for each participant, pairing can be a great tool to connect with both the problem and each other's innate skillset, IMO.

Re: Pair Programming Antipatterns

#20

Post by koide » Sun, Mar 06, 2022, 11:43 AM UTC

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…

I've paired remotely and haven't found it particularly problematic. Even without plugins, which tend to suck. Driver shares the screen with the ide, zooms it up, and it's good enough to be useful in my experience.