Hacker News Reader

Comment by tweakimp | Hacker News Reader

>>> Since we are employing two programmers to do work on the same keyboard at the same time, the output of pair programming must be greater than 2x the output of a single programmer to make sense.

Not at all. Two programmers working on the same project at the same time is already slower than one programmer working twice as long because these two have to communicate. And during pair programming, the communication is sped up.

In my experience, pair programming is really fun and helpful for some parts of my work, for example brainstorming solution ideas or finding bugs.

View on HN

> Two programmers working on the same project at the same time is already slower than one programmer working twice as long because these two have to communicate. And during pair programming, the communication is sped up.

That's assuming two people pair programming would otherwise need to communicate about every individual line of code.

No, they would need to communicate about the ideas and thought processes behind every individual line of code. If not now, then the next time there's a bug in said lines.

> ideas and thought processes behind every individual line of code

I realize you're being hyperbolic (at least as hyperbolic as the parent), but this is one of the big hangups of pair programming for me: waiting for folks to get through boilerplate. Let's talk ideas and thought processes about the important (or at a minimum non-boilerplate bits of) code, not an entire programming session.

"Alex, what were your thought processes that lead you to use 'i' for a loop variable?"

"Alex, what were your thought processes that lead you to a for loop here, rather than a {while loop/list comprehension/map operation/linq expression}?"

I actually disagree pretty strongly with this.

If you have two programmers working on the same project at the same time, you can split up the project along a pre-negotiated interface ahead of time. It takes some amount of communication to do that, but you don’t have to communicate about every single line of code the way you do with pair programming. In fact I’d say my #1 problem with pair programming is the added communication overhead.

I consider that brainstorming and working with a team mate, not pair programming. As a daily thing it's ridiculous and only for people who are exceptionally friendly and need a lot of human interaction. Give me a problem, a laptop, and some space and I'm all set. I agree with brainstorming during the design phase(s) of a project though, lots of good ideas come out and there is some synergy you can have that will never happen over zoom or email.

Reply on news.ycombinator.com