The mortifying ordeal of pairing all day • Hacker News Board

Re: The mortifying ordeal of pairing all day

#211

Post by Sharlin » Mon, May 10, 2021, 4:18 PM UTC

ratww wrote: post #32

I also worked at a company where pairing was mandatory for 8 hours a day. Plan was concocted by two tech leads who, of course, didn't pair themselves. The exhaustion was visible, and productivity was very low. Since everyone vocally thought it was a "waste of time", there was a Fight-club-style "rule" where we couldn't talk about the downsides in public or even in Scrum meetings. We missed several deadlines for an MV…

This sounds almost like the intentionally absurd example scenario described in Meditations on Moloch [1]:

> Imagine a country with two rules: first, every person must spend eight hours a day giving themselves strong electric shocks. Second, if anyone fails to follow a rule (including this one), or speaks out against it, or fails to enforce it, all citizens must unite to kill that person. Suppose these rules were well-enough established by tradition that everyone expected them to be enforced.

> So you shock yourself for eight hours a day, because you know if you don’t everyone else will kill you, because if they don’t, everyone else will kill them, and so on. Every single citizen hates the system, but for lack of a good coordination mechanism it endures. From a god’s-eye-view, we can optimize the system to “everyone agrees to stop doing this at once”, but no one within the system is able to effect the transition without great risk to themselves.

[1] https://slatestarcodex.com/2014/07/30/meditations-on-moloch/

Re: The mortifying ordeal of pairing all day

#212

Post by stjohnswarts » Mon, May 10, 2021, 4:20 PM UTC

I just can't do pair programming. I like doing my work, testing a bit and throwing it over to CI, QA, etc. Sorry, I'm just not that social, nor do I want to be in communication that often with any other human being other than my kids or wife.

Re: The mortifying ordeal of pairing all day

#213

Post by MockObject » Mon, May 10, 2021, 4:22 PM UTC

Agentlien wrote: post #208

MockObject wrote: post #200

Earlier quoted context omitted.

> But if that fails, it is definitely better to review and catch it after the code is written than to submit badly written code out of fear of wasted effort. Yes, without a doubt. > Having reviews to catch the odd lapse in judgement or logical misstep doesn't usually add a lot of overhead (as opposed to allocating two programmers to every menial task) Having paired for years, and soloed for years, I have found that t…

I have done some pair programming. At my first job we sometimes did it when some problem proved especially tricky. Typically a tricky bug. In some cases it's invaluable, absolutely. I just don't think that's a large percentage of the code written on a daily basis. For most tasks pairing seems to be either 1) one person tapping out simple code which practically writes itself while the other lazily nods along. 2) One p…

When I've seen it adopted, it was in the context of XP. The red-green-refactor cycle affords a decent flow for pairs, who may switch off between test writing and feature writing. I can see that without the other XP practices, pairing may be awkward.

Re: The mortifying ordeal of pairing all day

#214

Post by stjohnswarts » Mon, May 10, 2021, 4:23 PM UTC

gherkinnn wrote: post #118

I’ve had incredible experiences pairing. There were whiteboards, snacks, rating each other’s themes, and jokes. What worked very well was to pair for conceptional problems, like architecture and defining modules and their interfaces. Commit some types and pseudo-code. We’d then break away and work at our own speed and in our own style using the common foundation. Come together to integrate and discuss. Pairing is als…

I assume you are an extroverted person? Talking that much with another human being outside of someone I care dearly about just does not work for me, it just makes me anxious af. I'm glad it works for you and may you always another fellow extrovert to work. I left a job because they demanded pair programming as the new company paradigm. And yeah I gave it a shot for 3 months, and the other person was about as easy as anyone I could imagine anyone to be, but honestly I got tired of staring at his stupid face (although he was actually quite smart and capable, I just didn't want to see/communicate with him 8-10 hours a day)

Re: The mortifying ordeal of pairing all day

#215

Post by stjohnswarts » Mon, May 10, 2021, 4:24 PM UTC

cableshaft wrote: post #127

gherkinnn wrote: post #118

I’ve had incredible experiences pairing. There were whiteboards, snacks, rating each other’s themes, and jokes. What worked very well was to pair for conceptional problems, like architecture and defining modules and their interfaces. Commit some types and pseudo-code. We’d then break away and work at our own speed and in our own style using the common foundation. Come together to integrate and discuss. Pairing is als…

I like pairing for debugging a problem or discussing a design solution. You get stuck, bring someone in and discuss it, let them look at the code, point something out that sets your brain on the right track, or a solution pops in your head from something random they said or from the process of you explaining thing. Many, many issues have been solved that way. But I hate it in all other circumstances, especially when…

This works and I think is the natural way of things for human beings to bounce things off one another but for it to be a constant; no way!

Re: The mortifying ordeal of pairing all day

#216

Post by superduperycomb » Mon, May 10, 2021, 4:25 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 have ADHD and pairing is liberating. I don’t need medicine, I can stay focused and motivated for years. I’m seriously worried that I’ll have to get back on medicine because the pairing opportunities in the industry are becoming so far and few between. If anyone has recommendations I’m all ears (and eyes)!

Re: The mortifying ordeal of pairing all day

#217

Post by lthornberry » Mon, May 10, 2021, 4:26 PM UTC

jmcgough wrote: post #51

Since the comments here are mostly people appalled by the idea of pairing - try it before you knock it. Even the author says there's a lot of benefits to it, but it wore down on them over time. I did pairing for a few year at a company early in my career. Some days it felt draining, but I learned a lot , quickly, from working with senior engineers and seeing how they approached problems or building systems. You even…

I also think it's important to acknowledge individual differences. To give one relevant example, pairing sounds particularly challenging for people on the autism spectrum, which as a group is well-represented among software engineers. Several of the things the author sites as problems (need for sensory breaks, difficulty sustaining social engagement) are real issues for most autistic folks. It's not a coincidence that autistic people talk about "burnout" in much the same way that the author does--a total cognitive shutdown.

I'm not saying the author is autistic, although they might be, I have no idea. But enough people are that designing a work environment that won't work for them is something we want to be very careful about. And even more people aren't autistic but have some overlapping traits--the author might be in this group. That's also where I'd place myself, as someone who's not on the spectrum but has multiple close relatives who are, and sees more than a bit of myself in them, although not enough to be diagnosable. I think I could handle pair programming up to 30 or 40% of the time, but more than that, and I'm pretty sure I'd burn out fast.

Re: The mortifying ordeal of pairing all day

#218

Post by stjohnswarts » Mon, May 10, 2021, 4:27 PM UTC

thomascgalvin wrote: post #135

gherkinnn wrote: post #118

I’ve had incredible experiences pairing. There were whiteboards, snacks, rating each other’s themes, and jokes. What worked very well was to pair for conceptional problems, like architecture and defining modules and their interfaces. Commit some types and pseudo-code. We’d then break away and work at our own speed and in our own style using the common foundation. Come together to integrate and discuss. Pairing is als…

Pairing is also, bar none, the best way I've seen to onboard a new hire. There is no better way to learn a codebase than to work closely with someone who knows that codebase, on a real-world, production problem.

The best way I found to onboard was what I called "half day onboarding". Half the day the mentor can help, the other half the new person has to be self sufficient. Otherwise people start using their mentor as a crutch. This is the way I brought on new people as team manager.

Re: The mortifying ordeal of pairing all day

#219

Post by t0mbstone » Mon, May 10, 2021, 4:28 PM UTC

commandlinefan wrote: post #141

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…

> but rest assured that there are those who aren't built that way Yeah, the title suggests an anti-pair-programming rant, but the author seems to have stockholm-syndrome'd himself into accepting it. I tried pair programming once, a long time ago, when it first "came out". We immediately ran into all sorts of practical issues like, how do you check your e-mail? (Back then, you had to read e-mail in a dedicated e-mail…

The best pair programming experiences I've had involve each programmer using their own laptops, each with a separate screen attached.

The pairing sessions were shared via ScreenHero (now I use Tuple), where each person has independent control of their own mouse cursor, but can grab control by clicking anywhere and typing.

Because the pairing session is constrained to the external monitors and the laptop screen isn't shared, each dev can still check their private email or look up things off to the side, but can also keep an eye on the pairing session and jump back in whenever they are needed.

This methodology works well in a side-by-side pairing environment, and it also works great for remote pairing.

Re: The mortifying ordeal of pairing all day

#220

Post by stjohnswarts » Mon, May 10, 2021, 4:29 PM UTC

jmcgough wrote: post #51

Since the comments here are mostly people appalled by the idea of pairing - try it before you knock it. Even the author says there's a lot of benefits to it, but it wore down on them over time. I did pairing for a few year at a company early in my career. Some days it felt draining, but I learned a lot , quickly, from working with senior engineers and seeing how they approached problems or building systems. You even…

I did try it, it works when there is a hard problem to be solved, but for day to day coding no effing way. I can see extroverts who need to communicate a lot enjoying it, but I find they're in the minority with programmers especially the more senior they become. There are instances like mentoring or solving a tough problem, but otherwise I think email and slack and such are good enough communication tools, it doesn't need to be forced.