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

For Writing Software, a Buddy System

nytimes.com

Post reply on HN
Print view View original

11–20 of 34 posts

Re: For Writing Software, a Buddy System

#11

Post by gruseom »

dandelion wrote: post #8
mynameishere wrote: post #7

Earlier quoted context omitted.

Yes, in practice, everybody pair programs, on an as-needed basis. When it's not needed...well, you shouldn't be doing it. I seriously think that non-stop pair programming is just a way to keep people from goldbricking (as the article hinted at the end). And really, 90 percent of programming is more "typing" than programming because the work is straightforward.

That's an exceedingly ignorant statement.

I don't know which statement you mean, and it's a bit unnerving to be defending HN's gold medalist of curmudgeonry twice in one day, but I was going to comment on this anyway:

90 percent of programming is more "typing" than programming because the work is straightforward.

This may be exaggerated, but it has more than a grain of truth. If you take it to mean 90% of programming as actually practiced, as opposed to 90% intrinsically, it's not even that much of an exaggeration.

Working on harder problems in higher-level languages than I used to, I felt less productive for a very long time. In some ways I still do. I eventually figured out that this was because I was spending much more time thinking and much less time typing. Typing feels like good-old-fashioned-work in a way that thinking doesn't. That's why people feel satisfied after cranking out thousands of lines of code, when in reality they may well have made an unmaintainable mess (and thus destroyed value rather than created it).

Re: For Writing Software, a Buddy System

#12

Post by sachinag »

ojbyrne wrote: post #10

One of the things I find really effective, and almost never see, is pairing up product managers directly with programmers. Instead of product types going off and holding endless meetings finally resulting in a product spec carved in stone, there's a nice interactive process of product development.

We did exactly this for the two-month sprint for the initial code for Dawdle. I moved into the contracting firm's office, and we did this stuff all day long. It was great; they got a sense for what was "nice to have" and non-negotiable and I traded stuff that wasn't as important (a functioning search; we ended up using SWISH-E, shudder) for stuff that was (user account management). Both sides learned a lot, and I now know that most programmers aren't as good as the people who did that code.

To this day, two years later, our search still sucks, but the basis of that user account management has meant that we haven't had to touch that code in almost two years.

Re: For Writing Software, a Buddy System

#13

Post by aaronblohowiak »

sandaru1 wrote: post #9

Pair programming seems to be good, if you have everything defined. But in reality, you research, experiment, hack things around. You work on hunches and quickly implement them, then gradually improve them, compare the solutions and find the best. Pair programming would be pointless; rather annoying in this case.

Actually, it is precisely the experimentation / hunch-following times where I've found the biggest productivity gains -- bouncing ideas around with another smart and creative person is a lot more stimulating and effective than the code - compile -check loop!

Re: For Writing Software, a Buddy System

#14

Post by sandaru1 »

aaronblohowiak wrote: post #13
sandaru1 wrote: post #9

Pair programming seems to be good, if you have everything defined. But in reality, you research, experiment, hack things around. You work on hunches and quickly implement them, then gradually improve them, compare the solutions and find the best. Pair programming would be pointless; rather annoying in this case.

Actually, it is precisely the experimentation / hunch-following times where I've found the biggest productivity gains -- bouncing ideas around with another smart and creative person is a lot more stimulating and effective than the code - compile -check loop!

"code - compile - check" - I'm assuming that you are talking about coding/algorithm bugs.

What I'm saying is, lets say you want to find a way to update a web page with live data(http push?). Then you do a brainstorming session with others and get some ideas(comet, bosh, xmpp, etc). If you want to see which technology fits your product most, then it would be a good idea that each person is spending time on different ideas.

"brainstorming" is completely different from "coding together", specially coding a hack.

Re: For Writing Software, a Buddy System

#16

Post by s3b »

haupt wrote: post #3

'Pair programming' would get a bit frustrating, don't you think? I suppose productivity would greatly depend on the personalities involved.

Yes, personality flaws are a problem. Some people are selfish with the keyboard, some always want their ideas to be implemented, some don't coach well, some don't have good personal hygiene, etc. However that said, I still feel pair programming is the best way to do it. Productivity is a lot higher when pairing.

Re: For Writing Software, a Buddy System

#17

Post by akeefer »

ojbyrne wrote: post #10

One of the things I find really effective, and almost never see, is pairing up product managers directly with programmers. Instead of product types going off and holding endless meetings finally resulting in a product spec carved in stone, there's a nice interactive process of product development.

I definitely agree . . . it's a fairly standard "agile" practice to make sure that product managers/"customers" work closely with developers, but it's often not done that way. The bottleneck at my company has historically been around seating; we have an open office plan with clusters of 4-6 desks, but even then you have to make tradeoffs around who sits near who, and we've historically put developers next to developers and product managers next to other product managers so that they could all talk and coordinate with each other. That tends to mean the product managers are just far enough away from the developers that they don't talk much.

For our most recent development cycle (which started about 10 months ago), we finally bit the bullet and split the product team into cross-functional sub-teams we call "pods" consisting of (roughly) 5 developers, 3 QA, and 1 product manager. Having the product manager sit literally next to the developers, instead of 15 or 20 feet away, has made a huge difference in the interaction there and our ability to quickly iterate on features. Instead of just making assumptions when the product requirements are unclear or don't seem to make sense, we have much more of an ongoing dialog all day about how things should work, meaning we waste a lot less time building the wrong thing.

Re: For Writing Software, a Buddy System

#18

Post by gruseom »

aaronblohowiak wrote: post #13
sandaru1 wrote: post #9

Pair programming seems to be good, if you have everything defined. But in reality, you research, experiment, hack things around. You work on hunches and quickly implement them, then gradually improve them, compare the solutions and find the best. Pair programming would be pointless; rather annoying in this case.

Actually, it is precisely the experimentation / hunch-following times where I've found the biggest productivity gains -- bouncing ideas around with another smart and creative person is a lot more stimulating and effective than the code - compile -check loop!

It works both ways. Sometimes I want to throw ideas around with a partner and other times I want to go deep inside an intuitive thought process. The key is to recognize what wants to happen at any given moment, and to have a culture that respects that flow. It really bugs me when people try to impose a predefined process on that. But it also bugs me when people come up with reasons to say co-programming isn't productive, when experience shows that it clearly often is. (Not that you were doing either of these things.)

Re: For Writing Software, a Buddy System

#19

Post by xcombinator »

My experience with pair programming:

It is so great when the other person is very good/smart at programming. You sense that your work is way more than the sum of the individual parts. It is like an explosion of creativity because you don't stop when you have a block and the other has not, or he has a block and you have not.

It is not great when the other person is not good/smart. You make all the work, the other can only spot the obvious, and makes the sum way less than individual parts. Feels like an endless drain that won't finish ever.

In world war they experimented with airplanes pilots: creating groups with the best ones, letting other groups with the not so good. It was fantastic for the elite groups, but bad for the mediocre ones.

They mixed groups with good and mediocre people and it made the mediocre turn good, but the good didn't became elite.

So I think this has pros and cons, and is not for everyone.

Re: For Writing Software, a Buddy System

#20

Post by aaronblohowiak »

gruseom wrote: post #18
aaronblohowiak wrote: post #13

Earlier quoted context omitted.

Actually, it is precisely the experimentation / hunch-following times where I've found the biggest productivity gains -- bouncing ideas around with another smart and creative person is a lot more stimulating and effective than the code - compile -check loop!

It works both ways. Sometimes I want to throw ideas around with a partner and other times I want to go deep inside an intuitive thought process. The key is to recognize what wants to happen at any given moment, and to have a culture that respects that flow. It really bugs me when people try to impose a predefined process on that. But it also bugs me when people come up with reasons to say co-programming isn't product…

Totally! These tools are best used in a flexible environment, when you're in need or the situation calls for it. I think it is pretty safe to say that "this way all the time" is wrong for all values of "this way".
Post reply on HN