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

121–130 of 308 posts

Re: The mortifying ordeal of pairing all day

#121

Post by goatcode »

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…

>There may very well be people who work well in pairs, but rest assured that there are those who aren't built that way. Don't disparage them, don't discriminate against them, and don't play the moral superiority game with them. Accept their diversity and be a better team for it.

The most progressive view I've seen so far in the "official" dogma of pairing says to accept people who work better outside of pairing, but to exclude them from important projects. I'm at a loss as to how this is a good thing, and to me is a sign of pairing becoming a religion of extreme bigotry.

Thank you for saying something that should be common sense! Don't expect everyone to work and think in the exact same way!

Re: The mortifying ordeal of pairing all day

#122

Post by goatcode »

ChrisMarshallNY wrote: post #114
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…

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.

Re: The mortifying ordeal of pairing all day

#123

Post by throwaway894345 »

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…

Personally our industry needs to mature a lot with respect to its ability to critically understand studies before they’re going to be useful. Thus far it seems like the headline version of the first article which purports to analyze a topic is taken as gospel with respect to the topic in question. People still trot out that old article that “finds” that statically typed languages don’t reduce bugs (i.e., 90s era OOP creates enough bugs to offset those precluded by type checkers). If we’re going to depend on formal studies for these hugely multivariate issues we need a lot more rigor before they are more helpful than mere “collective industry experience”.

Re: The mortifying ordeal of pairing all day

#124

Post by edem »

bloudermilk wrote: post #22
edem wrote: post #20

Earlier quoted context omitted.

Sounds funny if you talk aloud while no one else is there.

There’s actually a term for this: https://en.m.wikipedia.org/wiki/Rubber_duck_debugging

I still have a blue rubber duck with "integer overflow" written on it. Got it many years ago but interestingly enough I never used it.

Re: The mortifying ordeal of pairing all day

#125

Post by lmilcin »

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 administrativia, some other smaller tasks, personal learning, making up for the stuff you were too embarrassed to ask during session, etc.

--

As to comments that talking constantly breaks your concentration and slows you down -- yes, it does and at the same no, it does not.

It is just a different way to achieving the outcome.

If you are programming alone you have better ability to focus, you can start/end when it is suitable for you, you don't need to consult every single part of design.

But what is left is that you are making mistakes on your own (and the longer it is uncorrected the higher the cost of fixing it) and there is no other person that knows how the stuff you developed works.

So while you yourself program a little bit slower, you are also achieving other goals concurrently with writing the code -- getting it honestly reviewed, passing knowledge, etc.

I have also found that verbalizing and explaining what I do many times causes me to find issues that I could have probably missed.

--

I personally like pair programming especially when I want to transfer some of the techniques and reasoning I use when developing solutions. This is not something that can be passed through presentations or reading and explaining the code.

Re: The mortifying ordeal of pairing all day

#126

Post by dcminter »

vertis wrote: post #119

I had so many negative experience pair programming that I started to find ways to avoid it. There were the pairs the insisted on using vim[1]. There were the pairs that hogged the keyboard. I'm sure there were other things that frustrated me about it (it's been a long time since this was an every day thing now). In the end though, I opted out of pairing, first by taking a devops role at the same company that didn't r…

Heh. I have to wonder if the pairs that insisted on using vim might be using that as a politically acceptable way to avoid pairing!

Re: The mortifying ordeal of pairing all day

#127

Post by cableshaft »

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…

I like pairing for debugging a problem or discussing a design solution. You get stuck, bring someone in and discuss it, let them look at the code, point something out that sets your brain on the right track, or a solution pops in your head from something random they said or from the process of you explaining thing. Many, many issues have been solved that way.

But I hate it in all other circumstances, especially when it comes to actual coding.

Re: The mortifying ordeal of pairing all day

#128

Post by Twisol »

geophile wrote: post #115
pydry wrote: post #95

Earlier quoted context omitted.

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). *…

> 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-understood, you probably don't want to commit to any code -- but there's no reason you can't use the development process to drive out some candidate solutions.

Re: The mortifying ordeal of pairing all day

#130

Post by edem »

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).
Post reply on HN