The mortifying ordeal of pairing all day • Hacker News Board

Re: The mortifying ordeal of pairing all day

#181

Post by topkai22 » Mon, May 10, 2021, 3:21 PM UTC

I find pair programming a useful tool. It's great as patterns and practices are getting stood up on a team, for ramping new members, disseminating knowledge or for wrestling through novel code. As the article gets it, at can also be very emotionally draining so team members don't reach for enough on their own. As a lead, I regularly encourage or instruct my team to pair. However I also wouldn't make it an "always on" policy. It IS exhausting, and it is inefficient in many cases.

We've also adopted a few alternative practices (especially frequent "mob coding" sessions where we work through problems as an entire team rather than just pairs) that people find less draining.

Re: The mortifying ordeal of pairing all day

#182

Post by dkersten » Mon, May 10, 2021, 3:22 PM UTC

MockObject wrote: post #170

g051051 wrote: post #153

Earlier quoted context omitted.

And my point is that I just can't see it. I collaborate with people, and there's benefit in those relatively short interactions, but I've never seen a situation where it made more sense to pair up like that, unless it's a training scenario.

I suggest you try it for a week. Code as conversation.

Its important to go in with an open mind and not resist it. If you go in grudgingly thinking its not going to work and you're going to try it only to prove yourself right, then it will of course never work. I'd also read up and see how people do it rather than just having two people sit at a computer but otherwise trying to code like you usually do, otherwise you're unlikely to see any benefits.

Re: The mortifying ordeal of pairing all day

#183

Post by kstenerud » Mon, May 10, 2021, 3:23 PM UTC

Agentlien wrote: post #173

MockObject wrote: post #165

Earlier quoted context omitted.

I despise code reviews, because the criticism is shallow, and offered too late, after the work has been done. I want the review in real time, and at a greater depth of insight. This is what pairing provides.

Shallow and too late criticism sounds like a problem with how the reviews are handled. At my previous job reviews were required before you were allowed to check in, meaning if it wasn't good enough you had to rework it. This meant junior engineers were quickly brought up to speed with code convention and best practices. If you didn't adhere to them your code wasn't approved. I also found it a great way to catch subtl…

Another helpful technique to good code reviews is to keep individual PRs small. Once a PR is over a few hundred lines, my eyes start to glaze over and by the end I'm just skimming.

I've had great success with breaking larger changes into smaller PRs that get code-review-merged into an integration branch. Then the integration branch gets merged to your main branch once everything's done and verified.

Re: The mortifying ordeal of pairing all day

#184

Post by sharkbait00 » Mon, May 10, 2021, 3:25 PM UTC

UweSchmidt wrote: post #29

"We were Pivots, and one of the things that made us Pivots was that we paired." Red flag for all kinds of weirdness if you're made to take on a company-based identity.

>red flags for all kinds of weirdness

You have no idea. I. Have. Seen. Things.

Re: The mortifying ordeal of pairing all day

#185

Post by athorax » Mon, May 10, 2021, 3:27 PM UTC

kstenerud wrote: post #68

Pair programming generates visceral responses due to it being introduced as if it were fact, which for me always triggers my spidey senses. People who didn't like it were told "you're doing it wrong" or "you didn't give it a proper chance". Dismissing criticisms out of hand only furthers distrust, regardless of the actual value of the idea. I played along and paired for awhile, but now steadfastly refuse to pair, eve…

I usually come off as a bumbling idiot when I try and pair program. It completely breaks the way my brain works trying to explain something while also trying to reason about a piece of software as a whole

Re: The mortifying ordeal of pairing all day

#186

Post by sharkbait00 » Mon, May 10, 2021, 3:28 PM UTC

Pair programming was invented so consultant bodyshops can bill customers twice the price for half the mediocrity.

Re: The mortifying ordeal of pairing all day

#187

Post by MockObject » Mon, May 10, 2021, 3:28 PM UTC

dkersten wrote: post #182

MockObject wrote: post #170

Earlier quoted context omitted.

I suggest you try it for a week. Code as conversation.

Its important to go in with an open mind and not resist it. If you go in grudgingly thinking its not going to work and you're going to try it only to prove yourself right, then it will of course never work. I'd also read up and see how people do it rather than just having two people sit at a computer but otherwise trying to code like you usually do, otherwise you're unlikely to see any benefits.

Excellent points. Here are some good ideas for getting started.

https://medium.com/@maaret.pyhajarvi/the-driver-navigator-in...

Re: The mortifying ordeal of pairing all day

#188

Post by ryanmarsh » Mon, May 10, 2021, 3:31 PM UTC

Pairing is hard because it involves two or more brains trying to solve a complex problem live through mediocre sensory and speech motor systems.

Naturally it’s going to work fine for some and be disastrous for others.

Re: The mortifying ordeal of pairing all day

#189

Post by kstenerud » Mon, May 10, 2021, 3:31 PM UTC

MockObject wrote: post #178

Agentlien wrote: post #173

Earlier quoted context omitted.

Shallow and too late criticism sounds like a problem with how the reviews are handled. At my previous job reviews were required before you were allowed to check in, meaning if it wasn't good enough you had to rework it. This meant junior engineers were quickly brought up to speed with code convention and best practices. If you didn't adhere to them your code wasn't approved. I also found it a great way to catch subtl…

Logically, any review criticism is too late, because the code was already written! Catching the issue before commitment is great, but the proper time for the feedback was during the actual writing. Now the code must be sent back for rewriting, and time has been wasted.

If the code requires such a substantial rewrite after review, that would be indicative of serious communication problems on the team. In 20-odd years of reviewing code, I can't think of many instances where a review led to a substantial rewrite.

Re: The mortifying ordeal of pairing all day

#190

Post by MockObject » Mon, May 10, 2021, 3:33 PM UTC

varispeed wrote: post #180

MockObject wrote: post #169

Earlier quoted context omitted.

I've never seen or even heard of a place where pairing is optional. I've only ever seen it compulsory or forbidden.

In many organisations pairing is encouraged, but not mandated - it means that if developer is stuck with something they ask if someone is available to pair to unblock them. Usually they'll find a person who loves pairing and get things done. In rare cases the PM would tell a developer experienced in the domain, to stop what they are doing and help. That's not too bad provided the interrupted developer gets an extra t…

I think in every company, it is encouraged to help someone who is stuck. By "pairing", I mean that a ticket is assigned to a pair, who complete it as a pair. I've never seen a place where some tickets are done by pairs but others, solo. In my experience, if management isn't fully committed to the process of pairing, then they have a hard time understanding how pairing isn't wasting labor.