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

301–308 of 308 posts

Re: The mortifying ordeal of pairing all day

#301

Post by RogerL »

simonmales wrote: post #15
MattGaiser wrote: post #5

How the heck can people work like that for 8 hours? I start to get very worn out at 2 hours of conversation.

I've paired on a couple projects and miss it. The exhaustion is very real but pairing really works when you take breaks. When one is loosing focus, there isn't a hesitation to say let's take a break. I found it similar to taking a timeout in basketball. As an engineering manager I stressed it to the team. Take breaks or you will break.

> Take breaks or you will break.

Life is waaaaayyy to short for that shit. Work so hard you are in danger of injuring yourself. No thanks.

Re: The mortifying ordeal of pairing all day

#302

Post by marcus_holmes »

jacques_chester wrote: post #293
marcus_holmes wrote: post #61

Earlier quoted context omitted.

This is something that I find very hard to explain to non-technical managers when I run dev teams. There's the expectation from non-technical managers that time away from the keyboard is "wasted" - that coding is a matter of pushing the buttons constantly, and that code is of a consistent quality, so more of it is better. There's also the bullshit long-hours work culture where leaving work before the boss does is som…

> And the code itself is a liability - it must be maintained in the face of changing requirements and technology. A nitpick: the better analogy is that code is an inventory asset. It can decay or rot, it costs money to acquire and money to maintain. But it is not a debt owed to someone else, as a liability is.

I was quoting other, smarter, people.

https://proxy.c2.com/cgi/wiki?SoftwareAsLiability

What the code does is an asset. The code itself is a liability.

We have "tech debt" that isn't actually owed to anybody yet must be paid.

Re: The mortifying ordeal of pairing all day

#303

Post by simonmales »

RogerL wrote: post #301
simonmales wrote: post #15

Earlier quoted context omitted.

I've paired on a couple projects and miss it. The exhaustion is very real but pairing really works when you take breaks. When one is loosing focus, there isn't a hesitation to say let's take a break. I found it similar to taking a timeout in basketball. As an engineering manager I stressed it to the team. Take breaks or you will break.

> Take breaks or you will break. Life is waaaaayyy to short for that shit. Work so hard you are in danger of injuring yourself. No thanks.

My limited experience with pairing has been positive. The negative is you can easily get caught up in the pace.

Which can be solved by taking breaks.

Re: The mortifying ordeal of pairing all day

#304

Post by papito »

Silhouette wrote: post #229
papito wrote: post #53

Earlier quoted context omitted.

Microsoft tried the 4-day work week, for example: https://www.npr.org/2019/11/04/776163853/microsoft-japan-say...

I'm not so surprised that they got such good results in Japan, where traditionally the business culture has been extremely demanding compared to most places. It would be interesting to know whether they did ever try similar experiments in other parts of the world with more "normal" working hours, and if so, whether they managed to repeat the successful result.

The Japanese work ethic of working yourself to the bone is puzzling to me. A culture driven by deep traditions, they need to stop once in a while and re-evaluate some. Not all traditions are worth keeping, like working all day every day, or using fax machines - another tradition that is refusing to die in Japan.

Re: The mortifying ordeal of pairing all day

#305

Post by jacques_chester »

marcus_holmes wrote: post #302
jacques_chester wrote: post #293

Earlier quoted context omitted.

> And the code itself is a liability - it must be maintained in the face of changing requirements and technology. A nitpick: the better analogy is that code is an inventory asset. It can decay or rot, it costs money to acquire and money to maintain. But it is not a debt owed to someone else, as a liability is.

I was quoting other, smarter, people. https://proxy.c2.com/cgi/wiki?SoftwareAsLiability What the code does is an asset. The code itself is a liability. We have "tech debt" that isn't actually owed to anybody yet must be paid.

I disagree with the other, smarter people, is my refined point.

Re: The mortifying ordeal of pairing all day

#306

Post by marcus_holmes »

jacques_chester wrote: post #305
marcus_holmes wrote: post #302

Earlier quoted context omitted.

I was quoting other, smarter, people. https://proxy.c2.com/cgi/wiki?SoftwareAsLiability What the code does is an asset. The code itself is a liability. We have "tech debt" that isn't actually owed to anybody yet must be paid.

I disagree with the other, smarter people, is my refined point.

I get the point. In terms of accounting principles, you're right, technically.

But it doesn't drive home the message that more code doesn't mean more asset. Having a developer write more code doesn't automatically create more value. The value is in what the code does, not the code itself. And a developer can actively harm the codebase by working on it. You can pay someone to improve it, and the end result is a decrease in value, not an increase. I'm not sure there are other asset classes that behave the same way. I could be wrong.

Re: The mortifying ordeal of pairing all day

#307

Post by suhlig »

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…

> how do you check your e-mail?

You don’t. That’s what breaks are for (assuming personal e-mail).

> What if there's documentation that needs to be read?

- Define an objective together (e.g. „We‘d like to understand how the HTML progress element works“)

- Optionally, agree an a timeout

- Split (both reading at their own pace, on their own device)

- Join and discuss results

Re: The mortifying ordeal of pairing all day

#308

Post by CRConrad »

commandlinefan wrote: post #268
jdlshore wrote: post #258

Earlier quoted context omitted.

If you couldn’t figure out how to check your email or read documentation, it sounds like you were looking for reasons to fail. Pairing doesn’t mean you’re literally joined at the hip. You’re allowed to exercise judgment.

Well, no, in our case it literally did mean we were "joined at the hip" - we shared one computer.

"Bloing!" -- "Oh look, an email. Never mind, I'll read that later."

"Bloing!" -- "Oh look, I think I need to read that email now." -- "OK, I'll toodle over to my own desk and see if I've got any. See you in five."

A computer isn't a hip.

Post reply on HN