The mortifying ordeal of pairing all day • Hacker News Board

Re: The mortifying ordeal of pairing all day

#131

Post by michael1999 » Mon, May 10, 2021, 1:40 PM UTC

thinkingemote wrote: post #23

alteredbeats wrote: post #13

Earlier quoted context omitted.

Ding, ding, ding. I find it funny most people don't realize pair programming is about control. It's like a workplace Stasi. Management expects you to deal with the inevitable conflict resolution, even if that's not your job. Even if your pair shows only for a couple of hours a day and you have to do the work of two people. “Much harder to spend time on HN” people who like pair programming either like to have power ov…

If it is like workplace Stasi and like the movie Brasil, shouldn't we expect pairs to slack off together in conspiracy, watching movies like in Brasil or commenting on HN instead of working. Does pair programming cause dysfunction? Also, is there a pair programming equivalent of the Scrum Master? That would be the chief slack position.

No. That's one of the many differences between Scrum and XP. XP is the feral cousin of Scrum.

Re: The mortifying ordeal of pairing all day

#132

Post by geophile » Mon, May 10, 2021, 1:42 PM UTC

Twisol wrote: post #128

geophile wrote: post #115

Earlier quoted context omitted.

> Having multiple perspectives on design. Serious question: Why is any design happening while programming? Seems unwise to start programming before you have designed the thing you are programming.

It depends on what you mean by "design", but sometimes the best way to figure out what your options are is to throw something together and see how it feels. Could be UI, could be API design, could be a form of test-driven design. If the problem isn't well-understood, you probably don't want to put code down -- you're better served going to the customer and scoping a problem to start from. If the solution isn't well-u…

That seems incredibly wasteful to me. I have no problem with rapid iteration between design and implementation, but at least recognize that those are different activities, and that the latter is a poor way of doing the former.

Re: The mortifying ordeal of pairing all day

#133

Post by g051051 » Mon, May 10, 2021, 1:44 PM UTC

dkersten wrote: post #98

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.

I don't agree. I wrote a top-level comment about my (positive) experience pairing, but I'll state it again here because its relevant to your comment: I was on a team with one other guy working on a complex distributed-systems project. We were both principle engineers at the company. We delivered the project in under a year and as far as I'm aware from talking with former colleagues, the code is still in production wi…

I just can't fathom that. How could the 4 hours "pairing" negate the fact that one of you can't work for 4 hours? I can see it if those 4 hours were really design/planning time, but otherwise, I just don't see how it could work.

Most of what I see people here calling "pair programming" is just normal collaboration. Bringing in someone to put a second set of eyeballs on a problem, or to discuss some design topics, or brainstorm isn't the kind of pair programming in the original article.

Re: The mortifying ordeal of pairing all day

#134

Post by JohnWhigham » Mon, May 10, 2021, 1:47 PM UTC

harryf wrote: post #80

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…

Like many things in programming, we adopt it like a cargo cult ( https://en.wikipedia.org/wiki/Cargo_cult_programming ) based on "some thought leader said" or "some company has amazing..." without actually doing any serious study. It's actually amazing for an industry that should be all about rational, reasoned analysis, that we're willing to perform such experiments on ourselves with so little evidence to show the v…

It's because software is incredibly amorphous. It's incredibly hard to compile meaningful metrics about it, partly because every project is different and used differently. We all know this in the back of our heads, and how incredibly daunting it is to squeeze out quantifiable data from it, so we instead don't tackle it (which is normal behavior for humans) and instead go with stuff that sounds and feels good. Pairing increases your code output Well, two it better than one, so it must be better! TDD prevents bugs? Well, writing the tests first sounds good to me, so it must be better!

Yeah, it's a dangerous mindset, and I don't really know how to get out of it, especially since we're all hypocrites to some degree.

Re: The mortifying ordeal of pairing all day

#135

Post by thomascgalvin » Mon, May 10, 2021, 1:48 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…

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.

Re: The mortifying ordeal of pairing all day

#136

Post by Twisol » Mon, May 10, 2021, 1:48 PM UTC

geophile wrote: post #132

Twisol wrote: post #128

Earlier quoted context omitted.

It depends on what you mean by "design", but sometimes the best way to figure out what your options are is to throw something together and see how it feels. Could be UI, could be API design, could be a form of test-driven design. If the problem isn't well-understood, you probably don't want to put code down -- you're better served going to the customer and scoping a problem to start from. If the solution isn't well-u…

That seems incredibly wasteful to me. I have no problem with rapid iteration between design and implementation, but at least recognize that those are different activities, and that the latter is a poor way of doing the former.

Programming is neither design nor implementation; it's a skill and a tool that isn't owned by a particular process. I am quite happy to sketch in code; I won't work with my hands tied behind my back.

Concretely, what "incredible waste" are you projecting here? Neither myself nor the ancestor even laid out a process to criticize.

Re: The mortifying ordeal of pairing all day

#137

Post by JohnWhigham » Mon, May 10, 2021, 1:51 PM UTC

Olreich wrote: post #84

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…

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.

I think it can be good for 2 seniors when you need something right now i.e. production bug, or feature that came out of nowhere that needs to ship by EOD. Assembling a strike team of sorts.

Re: The mortifying ordeal of pairing all day

#138

Post by JohnBooty » Mon, May 10, 2021, 1:55 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.

Yeah. I almost want to say it's the only realistic way to onboard.

Depending on the codebase, I feel it's literally 10-50x more productive.

Re: The mortifying ordeal of pairing all day

#139

Post by lmilcin » Mon, May 10, 2021, 1:58 PM UTC

edem wrote: post #130

lmilcin wrote: post #125

I like pair programming. Now, it is important to understand that, when you pair with somebody, not everybody has the same stamina or they might have worse day when you have your better, etc. I set limits on pair programming. It seems to me 4 hours of true focus is a limit for most people on most days and pair programming requires constant focus whether you are driving or observing. Other 4 hours are left for administ…

This means that if I'm working alone I can do the same amount of work with 2 pomodoro hours (absolute focus for 50 minutes x2).

Pomodoro does not generally improve focus, it just helps prevent procrastination.

Pair programming is another way to do the same -- since you have agreed with the other person to start at agreed time and work for specified number of hours it is much more difficult for you to suddenly stray to reading Hacker News.

It does not necessarily mean your quality of focus will be better, it just means there will be minimum quantity of it.

Re: The mortifying ordeal of pairing all day

#140

Post by randomdata » Mon, May 10, 2021, 1:59 PM UTC

lghh wrote: post #113

eplanit wrote: post #111

Earlier quoted context omitted.

In my experience, I've seen pairing work in the context of an experienced engineer mentoring a junior, as part of a spectrum of engagement: observing/reading, shadowing, pair programming, to then where the junior acts with more independence with some oversight, and then they're ready. Beyond that, as a general rule it's only attractive to very mediocre engineers (who are honest enough to admit they need help). In int…

> as a general rule it's only attractive to very mediocre engineers "Thing I don't like is only useful to developers who are worse than me" is a super toxic take. If you said something like that when I was interviewing you, regardless of how much pairing the company I'm running the interview for does, I'd pass on you as well.

...and then complain that there is a "shortage" of developers.