Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The mortifying ordeal of pairing all day

simplermachines.com

Post reply on HN
Print view View original

271–280 of 308 posts

Re: The mortifying ordeal of pairing all day

#271

Post by g051051 »

dkersten wrote: post #270
g051051 wrote: post #224

Earlier quoted context omitted.

> I don't know what kind of work you do, but in my ~20 years of programming, typing is a rather tiny percentage of programming work. Most of it is thinking, problem solving and designing. I spend a lot of time typing and thinking. And having to slow down and talk to another human impedes my thinking. It's much faster to just think. > Both people are doing these things, except you're both doing them on the same task.…

I think you are deeply misinformed about pair programming and have some ingrained misconceptions. I don't think I can persuade you otherwise though.

I'm just going by what I've seen in my career, as well as the words that you're using to describe the process, what others in this thread are saying (on both sides of the issue), plus the countless articles I've read over the years.

The best I can tell you is there is a level of performance where the cost of working in what is essentially an all-day meeting, every day, forever, is far greater than what gains might be obtained by having two people involved to get over whatever issues are better served by being in the pair. It's much, much more effective for me (and most of the people I've ever worked with) to just reach out as-needed for consulting.

The only time I do anything like what you're describing is in a learning context, either as teacher or student. In that case, one of us is sacrificing our time to work with the other person, but it is just that, a sacrifice, in order to serve the long term goals of the group.

Re: The mortifying ordeal of pairing all day

#272

Post by Huggernaut »

g051051 wrote: post #266
Huggernaut wrote: post #259

Earlier quoted context omitted.

In fluid pairing the driver and navigator are constantly switching roles and bouncing off each other. Based on another message above where you said: > No, one person is doing things, and another is watching and talking while the other person is doing things. I just don't think you're fully understanding the process, which I'm not surprised (and don't hold it against you) about because it's very nuanced. In the piano…

> In fluid pairing the driver and navigator are constantly switching roles and bouncing off each other. Apparently, pair programming places no value on flow. > I just don't think you're fully understanding the process, which I'm not surprised (and don't hold it against you) about because it's very nuanced. Yeah, pretty sure I do understand it. I just don't see how it's effective unless the people involved are either…

> Apparently, pair programming places no value on flow.

There are certainly times where flow can be difficult. However I'll offer a few other thoughts.

Pairing pairs well with TDD. You write a test, I make it pass, I write a test, you make it pass. This is an extremely easy way to get into flow with a pair which doesn't require much communication beyond the code being written.

I often find that the boundary between "flow" and "too deeply invested in current thought process" is pretty blurry. Pairing (and TDD for that matter) allow for an opportunity to _slow down_. Of course, I'm sure there are some masters for whom this is absolutely, totally, a waste of time. For the majority of engineers, I think they can find benefit (though they may find more negatives in other ways).

> I just don't see how it's effective

I'll give you a list of personal reasons that come to mind for why I find pairing effective (this goes beyond "deliver immediate value"). Of course, that doesn't mean they apply to everyone, or even to a majority, or can't be achieved in other ways:

- I am less easily distracted because I am in flow with someone else

- I am forced to consider my thoughts more carefully because I need to explain them to someone else

- I am confident that someone else can continue this work if I am unavailable

- I enjoy the camaraderie and friendships built with my pairs

- I quickly learn new tools, tricks and ideas from others

- I am able to practice my teaching or coaching skills

- I am able to quickly get valuable feedback on ideas as I don't need to bring someone up to speed

- I take more breaks throughout the day

- I am able to provide and receive significantly more interpersonal feedback due to the high touch nature

- I'm likely to discover something I've missed with a different set of eyes

- I'm likely to take fewer shortcuts, or to be called up on them

- I've become a more effective verbal communicator in the rest of my life

Of course, I can also give you a list of reasons why I don't like pairing, to even it out!

Re: The mortifying ordeal of pairing all day

#273

Post by caffeine »

scruple wrote: post #239
qamark wrote: post #194

Earlier quoted context omitted.

Just a word about the Marine analogy in case some manager sees this and gets all excited: Team work is much more natural if you are up against an external enemy in the broadest sense, like the military, farming, building an aircraft or a group of physicists taming nature. It does NOT work for creative endeavours with a) a distinct amount of self-expression like programming or writing novels that b) also require enorm…

> Team work is much more natural if you are up against an external enemy in the broadest sense This is why I've always found it frightening when some management type starts talking about the book Extreme Ownership. I am a veteran, though I was not SOF, and I have strong opinions about why military management mindsets do not translate well to the business world in _most_ cases. To be fair, I have not read the book, bu…

Think you might be pleasantly surprised... concepts like “extreme ownership” (care about everything in your stack), “decentralised command” (push decision making to those doing the work), “cover and move” (help each other) actually translate pretty well.

The book is mostly about dealing with people rather than about engineering process, and I think the people aspects of a coding team and any other high performance team probably have a lot in common.

Re: The mortifying ordeal of pairing all day

#274

Post by g051051 »

Huggernaut wrote: post #272
g051051 wrote: post #266

Earlier quoted context omitted.

> In fluid pairing the driver and navigator are constantly switching roles and bouncing off each other. Apparently, pair programming places no value on flow. > I just don't think you're fully understanding the process, which I'm not surprised (and don't hold it against you) about because it's very nuanced. Yeah, pretty sure I do understand it. I just don't see how it's effective unless the people involved are either…

> Apparently, pair programming places no value on flow. There are certainly times where flow can be difficult. However I'll offer a few other thoughts. Pairing pairs well with TDD. You write a test, I make it pass, I write a test, you make it pass. This is an extremely easy way to get into flow with a pair which doesn't require much communication beyond the code being written. I often find that the boundary between "…

Fundamentally, if two people want to pair, and can meet their obligations as far as delivering work (produce two or more times the work than what's expected of an individual), then feel free. At the end of the day, I don't care how you do your work, any more than I'd dictate which IDE you use. The biggest concern that I'd have in a group with pair programmers is the noise from the constant talking, but most places don't care about having a quiet working environment these days.

However, with pretty much anything like this, just forcing it down everyone's throat is a recipe for disaster. Probably the most confusing thing about the original article was the statements "This was one of the best things I’ve ever done for myself, socially and emotionally, and it produced some great software", followed by "It burned me out" and "I was on short term disability due to cognitive impairment for several months of 2020, and I’m still recovering my old attention span, executive function, and emotional management". Huh?

Re: The mortifying ordeal of pairing all day

#275

Post by azhu »

Humans are fundamentally meant to interact and collaborate with other humans. Technology has obscured this by empowering us each to be resourceful alone. In the long term, we indeed do operate best collaboratively.

Re: The mortifying ordeal of pairing all day

#276

Post by alistairSH »

goatcode wrote: post #260
alistairSH wrote: post #240

Earlier quoted context omitted.

Not directly. If somebody actively avoided paired work, I'd probably ask them about it during a regularly scheduled 1-on-1. And if somebody was doing a spectacular job mentoring/pairing/etc I'd definitely mention it.

That seems pretty reasonable. I'd hate to work at a place that "didn't enforce" something, but had it turn into a 15 pieces of flair type situation.

From my perspective, it’s a great way to mentor and facilitate knowledge transfer. It’s also great for working through coding roadblocks. It’s a useful tool, nothing more. Theres no mandate to use it at the office, it’s up to individual developers to use it appropriately and managers to facilitate it.

Re: The mortifying ordeal of pairing all day

#277

Post by azhu »

mrozbarry wrote: post #197
chrisseaton wrote: post #146

Earlier quoted context omitted.

> unless someone can convince me that specifically pairing is causing the burn out If someone tells you something is causing them anxiety and stress can't you just accept that rather than requiring to be 'convinced'? You say you want a team that supports and trusts... yet you don't believe people when they say something's causing them pain.

It's not that I don't trust the burnout, but I want to know what aspect is causing burnout. Is it talking all day? Is there stress because someone is watching you work? Are you not taking enough breaks? These things aren't all specific to pairing, which means that pairing wouldn't always be the issue. Sure, some people are just not the type of people that are good at pairing, and that's valid, but it's important to i…

The author explains it well IMO. Mentally computing an appropriate response to present to another human takes energy. The more different that human than you, the more energy. There'll be some outliers that are inordinately drained by pairing.

I agree that if someone can't talk about why they're feeling stressed by their work environment then it's a deeper issue than just a personal one. I would point to leaders whose lack of understanding of higher order truths about humans, like that humans are different and space needs to be permanently held for those differences to be surfaced and coalesced, can cause their well intended questioning to come across as personal attack, thereby incentivizing the team member to stay quiet.

Trust is the end state of solving a communication problem. But it's a systemic quality and needs to be cultivated from the system as a whole, not any one member.

Re: The mortifying ordeal of pairing all day

#278

Post by dkersten »

g051051 wrote: post #271
dkersten wrote: post #270

Earlier quoted context omitted.

I think you are deeply misinformed about pair programming and have some ingrained misconceptions. I don't think I can persuade you otherwise though.

I'm just going by what I've seen in my career, as well as the words that you're using to describe the process, what others in this thread are saying (on both sides of the issue), plus the countless articles I've read over the years. The best I can tell you is there is a level of performance where the cost of working in what is essentially an all-day meeting, every day, forever , is far greater than what gains might b…

> The best I can tell you is there is a level of performance where the cost of working in what is essentially an all-day meeting, every day, forever, is far greater than what gains might be obtained by having two people involved to get over whatever issues are better served by being in the pair.

And yet, my experience has been the exact opposite.

> It's much, much more effective for me (and most of the people I've ever worked with) to just reach out as-needed for consulting.

Fair enough. But, have you seriously (as I said in another comment, if you go in expecting it to fail, of course it will fail) tried it?

Re: The mortifying ordeal of pairing all day

#279

Post by g051051 »

dkersten wrote: post #278
g051051 wrote: post #271

Earlier quoted context omitted.

I'm just going by what I've seen in my career, as well as the words that you're using to describe the process, what others in this thread are saying (on both sides of the issue), plus the countless articles I've read over the years. The best I can tell you is there is a level of performance where the cost of working in what is essentially an all-day meeting, every day, forever , is far greater than what gains might b…

> The best I can tell you is there is a level of performance where the cost of working in what is essentially an all-day meeting, every day, forever, is far greater than what gains might be obtained by having two people involved to get over whatever issues are better served by being in the pair. And yet, my experience has been the exact opposite. > It's much, much more effective for me (and most of the people I've ev…

> But, have you seriously (as I said in another comment, if you go in expecting it to fail, of course it will fail) tried it?

I don't have to jump out in front of a moving car to know I'll get injured if I do. I've collaborated and worked with others enough to know it's not for me. Others in places I've worked tried it, and it didn't go well, in spite of strong management desire to see it implemented. I'll assert again that I've never seen it actually work, not heard from any of my peers that it worked. And in spite of the comments in the original article touting such benefits as "one of the best things I’ve ever done for myself, socially and emotionally, and it produced some great software", that sounds like cognitive dissonance given the horrific problems that it caused.

Re: The mortifying ordeal of pairing all day

#280

Post by _dps »

I'll confess my bias up front: pairing has never worked for me, and I really just can't write serious code unless I'm in my own head.

Having said that, let me now ask pairing proponents: can you give me a rough idea of what you believe the economics to be? Because from my perspective the two people working together on the same program need to deliver value twice as quickly as a solo programmer merely to break even. Based on what I've seen my median estimate for how much quicker things go is ballpark 1.25x, and then throw in some amortized benefit for knowledge transfer and camaraderie. But in my biased opinion find it a stretch that you even hit break-even with high probability.

So, I would love to hear from pairing proponents how they think about the development economics and the size of the win.

Post reply on HN