Live data from Hacker News

The mortifying ordeal of pairing all day

simplermachines.com

291–300 of 308 posts

Re: The mortifying ordeal of pairing all day

#291

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.

I get flow with and without pairing.

I have ADHD, so for me flow is a spectrum from "smooth, effortless, light" to "destructive hyperfocus". Pairing almost completely prevented hyperfocus in my experience.

Re: The mortifying ordeal of pairing all day

#292
post #91

"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.

Sadly very common in Silicon Valley culture. And this is far from the most cult-like thing about Pivotal.

I once protested against the cult description and then someone pointed out that I did the 3-2-1 clap whenever my team finished an IPM or retro.

Pivotal definitely had an incredibly strong cultural field strength. That much it shares with cults. Personally, I loved it, like anyone who finds a fit in such a place.

Re: The mortifying ordeal of pairing all day

#293

Earlier quoted context omitted.

8+ hours is not okay not every other day or even less frequently. Ok, once in a while is ok if one is in a good rhythm and they are enjoying themselves. But after 4-6 hours productivity drops sharply and starts to erode from the following days: fixing up poorly made design choices, etc If your employer expects you to be productive 8 hours a day I’d look for something else

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.

Re: The mortifying ordeal of pairing all day

#294

Earlier quoted context omitted.

> 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 do…

He realizes the powerful benefits of the technique, but he is an introvert and finds sustained social interaction tiring and stressful for his neurology.

Re: The mortifying ordeal of pairing all day

#295

Earlier quoted context omitted.

> 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 aga…

> I'll assert again that I've never seen it actually work, not heard from any of my peers that it worked. And I'll assert again that I have experienced it work (in two different jobs, although one was only for a day at a time), seen it work for coworkers and a few of my peers have had it work very well too. Additionally there are other people here in this very comment section asserting that they, too, have experience…

> Your comment reads very like: "So, I have no anecdotal evidence from my immediate peers that it can work so it must not work. You have offered me first hand anecdotal evidence that it can, I shall ignore that."

No, it's "I have strong first hand evidence from seeing the attempts at my and other work places that pair programming is not a slam dunk improvement for software development".

> At this point, I have to wonder why you're even in this comment thread, since you seem so completely stuck and rigid in your beliefs.

Back at you. I'm not the only one here with strong misgivings and counter examples.

> But you're here adamantly proclaiming that it doesn't work and is a waste of time as if its some immutable truth when it really isn't, evidenced by the fact that it has worked for me and others.

I stated that I don't care how others get their work done. You want to pair program? If you can maintain or exceed the expected productivity of the rest of the team, then you do you. What I strenuously object to is the heavy handed application of this "concept".

> Also, your car analogy is invalid.

Yours isn't much better. Rocks can certainly fly, if you provide enough force, but they don't do it easily and they don't do it well, and require a huge effort to make it happen. I wouldn't want to travel by flying rock.

Re: The mortifying ordeal of pairing all day

#296

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.

For me, the hours zoom by like minutes. The end of the day is suddenly here, and I don't feel like I've worked at all. I was hanging out with a buddy chatting about stuff, and yet there is a pile of completed code in front of us.

Re: The mortifying ordeal of pairing all day

#297

Earlier quoted context omitted.

I stopped using deodorant years ago because I just didn't see the point. If it did what it said on the bottle I'd be fine with it, but it doesn't actually deodorise anything. If you or your clothes are dirty the only way that takes away the smell is to wash, adding another smell on top of it is not a solution. If they want to make a deodorant they should sell bottles of chlorine gas instead, but then they'd have to a…

you want anti-perspirant, not deodorant. Try Mitchum Unscented (It's for "women" but it's completely odourless, so who fucking cares). It's BY FAR the best deodorant I've ever found. As someone who used to suffer from serious BO; find a product that works, and learn to wash your clothes properly. Butyric acid is the enemy.

Yeah, I suspect what makes people smell bad is not so much the sweat as organisms that spring to life in their clothing when exposed to sweat, or just plain water for that matter.

Before the pandemic I worked with a lot of lycra biker types who would bike in and then shower at the office, and their wet towels made the whole office reek to high heaven. I mostly don't care about people's actual BO, but I suspect that I'm very sensitive to certain fungal VOCs. They give me migraine-like symptoms. I know some hoarders who haven't taken a shower in years, there's a kind of penile and scrotal aura in the air around them. It's not pleasant, but it's not even on the same scale as mouldy towels and clothes.

Re: The mortifying ordeal of pairing all day

#299

Earlier quoted context omitted.

I know for a painful fact that "here's our documentation, here's our bug backlog, have fun," is also realistic. For comparison, the productivity multiplier is something like 0.01x against the baseline...

I actually felt like I learned a lot this way, although I had access to a highly competent person who knew nearly everything about the code base, and I would discuss with him like 4-5 times a day sometimes. It felt like close collaboration, but I feel like if I would've been sitting with him I would have wasted a lot of his time and would have felt pressured to try to learn things faster than was reasonable. But I ne…

     I feel like if I would've been sitting with him 
     I would have wasted a lot of his time 
Yeah I think forcing devs to pair for no reason and simply hoping the magic happens... tends to waste time

What you did is what makes sense to me. Be eager to pair and/or mentor "on demand" whenever it makes sense.

Whenever I've written some weird/tricky code that doesn't explain itself, I make doubly sure to mentor the next coder(s) who work on it.

I find it pays off handsomely. Off the top of my head, I would say that 1 hour of working together can easily replace 2-8 hours of another dev stumbling through things, trying to do code archaeology, and making mistakes that might have been avoided.

Some folks would say "well, just document the code" or "write cleaner code" but sometimes that's simply not reality when racing deadlines, requirements are changed at the last minute, or you're working around bugs in external libraries or devices.

Re: The mortifying ordeal of pairing all day

#300

Earlier quoted context omitted.

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)!

That's very interesting, i never thought about pairing as a tool that help people with ADHD stay focused. At ThoughtWorks we do promote pairing, please let me know if there is anything I can do to help you out!

It’s funny you mention ThoughtWorks, I’m happily (enough) employed right now. But I’ve thought about applying for years. I appreciate the offer :)
Post reply on HN