The mortifying ordeal of pairing all day • Hacker News Board

Re: The mortifying ordeal of pairing all day

#161

Post by throwawayboise » Mon, May 10, 2021, 2:41 PM UTC

Cederfjard wrote: post #69

ratww wrote: post #54

Earlier quoted context omitted.

This was a very strange workplace. Its atmosphere was half frat-like and half cult-like. There was literal chest beating and shouting motivational stuff during sales meetings, an incredibly amount of beer (which isn't necessary an issue, but in this case it was ), sometimes drugs (which led to some people being fired whenever it became public), lots of sexual harassment complaints (which also led to some surprise fir…

> The cult-like part was the CEO fancying himself some Steve Jobs type, doing two-hour long presentations on random topics like his favourite economic ideas, or presenting a treatise against post-modernism. I of course knew which youtube videos he was plagiarising. Amazing. So ”Michael Scott from The Office”-type people really exist out there.

Oh yes. I can't even watch The Office because it's too real.

Re: The mortifying ordeal of pairing all day

#162

Post by kodah » Mon, May 10, 2021, 2:49 PM UTC

goatcode wrote: post #122

ChrisMarshallNY wrote: post #114

Earlier quoted context omitted.

Pairing works great; as long as everyone is on the same "wavelength." That's absolutely vital , and has both good and bad sides. The good, is what the author was talking about. That team cohesiveness, that he disturbingly compared to being in a Borg Collective, is something that can't be easily quantified, but can amplify energy and positive morale. The Marines have known this for a couple of hundred years. Every Mar…

The only way I've seen this kind of situation come about is if pairing isn't forced. "Forced" means leadership encouraging at every opportunity, ham-handedly, without considering context. If there isn't an extreme investment by leadership, badly-executed pairing will ensue, form what I've seen.

Pairing is a decision made between two devs, not as a team or company, imo.

Re: The mortifying ordeal of pairing all day

#163

Post by nthj » Mon, May 10, 2021, 2:50 PM UTC

pydry wrote: post #95

Olreich wrote: post #84

Earlier quoted context omitted.

Pair programming only seems good when there is a large disparity in experience or seniority. The senior engineer is there to teach the junior engineer and is sacrificing a great deal of time and energy to do so. That trade off may be worth it. Pairing people with the same skill set? Mostly that’s just a waste.

It's good for a number of things: * Having multiple perspectives on design. * Having an extra pair of eyes to catch things one person might miss. * Being able to bounce ideas off each other. * Redundancy (if you are on holiday or sick somebody else still knows the code deeply) * Onboarding (it works better at getting me up to speed than any docs ever have) * Motivation (i find it's kind of like having a gym buddy). *…

> * Redundancy (if you are on holiday or sick somebody else still knows the code deeply)

This is the part I’m always puzzled by. I read and understand every line of code my team merges in. If I don’t feel like I fully understand it, I ask questions, in code review. If I’m still not getting it I may ask for a zoom meeting. But that’s maybe once a week. Consequently I can jump in and manage issues or bugs pretty much anywhere in the product, and it’s fairly complex.

I think there are two kinds of programmers, those who quickly read and understand code and those who more quickly understand from talking about the code, and these two groups will always talk past each other when discussing pair programming.

Re: The mortifying ordeal of pairing all day

#164

Post by PragmaticPulp » Mon, May 10, 2021, 2:54 PM UTC

Pairing all day, every day is a relatively rare version of pair programming. In every case I’ve seen, pair programming was only done for a few hours a day or in select circumstances such as architecting a system.

Browsing the comments, that seems to agree with what most people have experienced at their jobs, with the exception of a few horror stories about companies that forced 8-hour per day pairing and paid the price for it.

Re: The mortifying ordeal of pairing all day

#165

Post by MockObject » Mon, May 10, 2021, 2:54 PM UTC

Agentlien wrote: post #109

hughrr wrote: post #90

Earlier quoted context omitted.

I'm actually here because my colleagues keep coming up with things posted here and on other sources and I was intrigued as to the consensus behind them. I'm pleasantly surprised to read that there is a nice critical balance of discussion. The worry for me is that there is almost always an obvious detachment from the steps carried out to the benefit which is the precise definition of a cargo cult. A lot of people can'…

I agree with your criticism against pair programming. I also agree that it's helpful with an extra pair of eyes on anything you write, which is why I'm strongly in favour of code reviews.

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.

Re: The mortifying ordeal of pairing all day

#166

Post by kstenerud » Mon, May 10, 2021, 2:56 PM UTC

jhedwards wrote: post #150

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…

How do you teach other people? In our team we sometimes have people working on systems that they are unfamiliar with, either because they are new to the team or new to the feature/system, and we've found that it saves a huge amount of time to have someone who is familiar with the system pair with them to get up to speed. Sure, once the person is comfortable (and the "expert" is comfortable that they aren't going to d…

I bring up the existing documentation, and have them run through it mostly on their own with me sitting there, asking me whenever they have questions. I watch over their shoulder and nudge them if I see something going awry. They jot down notes that they'll use to update the documentation later. Once they're up and running, they ping me whenever they get stuck, and then jot down notes for the documentation later.

The important part is that they read the docs (as a sanity check that the docs still make sense to a newcomer) and perform the actions themselves. I don't touch the keyboard except when it's a complicated, exceptional issue that they're not expected to deal with at this level.

The other important part is that they update the documentation.

Re: The mortifying ordeal of pairing all day

#167

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

> There are people who can pair indefinitely, for years. Who don’t experience the most demanding version of it often. Whose recovery capacity comfortably outpaces the demand.

I've paired for years, at two companies, but I have no personal sensation of "recovery capacity", because I'm an extrovert, and pairing gives me energy, instead of draining it away. One of my biggest complaints with my current company is that pairing is never done.

Extroversion is nothing but a neurological condition from birth.

Pairing is awesome for some, and torture for others.

Another benefit is the ability to work productively in the noisy Great Hall offices into which careless management and high office rents conspire to confine us. Instead of requiring the dead silence I need for solo concentration, I only need to be able to hear my pairing partner over the constant din of telephone calls, and reviews of last night's tacos, aisles away.

Re: The mortifying ordeal of pairing all day

#168

Post by kodah » Mon, May 10, 2021, 3:04 PM UTC

I've found pairing really useful for certain activities. If I'm working on very critical code or if I need to churn something vast out quite quickly, then pairing has served me well. As a new generation enters software I've noticed there's some differences, but it follows the same theme. Aside from pairing, they like to watch people code. Notably, I had a codebase that had been through a POC but lacked some E2E tests, so I streamed myself writing tests and refactoring code to make it more testable. The engineer picked up on the tools I was using, what I was doing, why I was doing it, and got to see me make mistakes. I think this is yet another avenue where we have opportunities to engage young devs and onboard them more quickly.

As someone that loves and suggests pairing, I'll pass on this:

- Never mandate pairing, authorize it. Some people really don't like pairing and will just complain endlessly.

- If you authorize pairing, find two people who are really good at it and have them train people on how to do it with your equipment and your environment.

- Personalities that clash on a team will predictably not pair well together.

Re: The mortifying ordeal of pairing all day

#169

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

kodah wrote: post #162

goatcode wrote: post #122

Earlier quoted context omitted.

The only way I've seen this kind of situation come about is if pairing isn't forced. "Forced" means leadership encouraging at every opportunity, ham-handedly, without considering context. If there isn't an extreme investment by leadership, badly-executed pairing will ensue, form what I've seen.

Pairing is a decision made between two devs, not as a team or company, imo.

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

Re: The mortifying ordeal of pairing all day

#170

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

g051051 wrote: post #153

MockObject wrote: post #151

Earlier quoted context omitted.

All those benefits he listed there can, and often do, offset what seems like a waste of an extra programmer.

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.