Hacker News Reader

Comment by ggreer | Hacker News Reader

I can't tell if this is sincere or parody [1].

If it's sincere, I think the author is attacking a rather extreme position.

Sometimes I like to write code by myself. Sometimes I like to pair on stuff. It depends on a lot factors. Is it complicated code? Do I know the language/framework/codebase well? Do I have a peer who knows more than I do about the problem I'm trying to solve? Is it important that multiple people be able to maintain this code? Etc. Like most things, pairing is a trade-off. It can have benefits, but it costs twice as much to write code.

That said, I think most people in our industry could benefit from pairing more, not less. Studies on pair programming show significant advantages in many circumstances [2]. If the author is sincere, I hope he'll keep an open mind about an occasional pairing session in the future.

1. http://en.wikipedia.org/wiki/Poe's_law

2. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.101...

View on HN

If he was insincere, let me assure you that I could make all the same assertions and be entirely sincere. Pair programming is for mediocre programmers who need a lot of support. As a highly productive programmer with decades of successful projects behind me, I can assure you that pair programming would be disastrously disruptive to me; in fact my entire team would bail if it were pushed upon us.

> I can assure you that pair programming would be disastrously disruptive to me

And so you refuse to do it even if it would be tremendous help for the other person. You won't pair with a colleague, because you don't like it, because it would "disrupt your work", even though you could cause the other person to become much more productive in much shorter time. You're not only being a jerk by doing so, you're actually undermining your project and putting your "decades of successful projects" at risk.

Yeah, highly rational decision, based on your dislike of (as per OP) interacting with other people. I'm so happy I never met you.

Projecting. I help other programmers routinely; I mentor high school students; I run architecture meetings for the group.

I don't get anything done if I'm made to waste large portions of my day hand-holding other programmers. My work is best done in a silent room with hours uninterrupted.

I'm sure you'd be glad to meet me; I don't dislike interaction at all. Lets just do it at a coffee shop.

Sure, you wouldn't respond well if it was forced on you. But what if you tried it sincerely? What if your whole team said, "this week we're going to try an experiment." Don't nitpick or naysay, just try it and see. Your use of the word "would" is very telling that you haven't tried.

Its funny; imagining the folks oppose PP because they've never tried it. Like we've been in some sort of cocoon or glass jar all our lives.

Sure, I've had to endure somebody trying to 'help' when I have a hard problem to find. I spend my time explaining to the other guy, bringing them up to speed. And they spend their time suggesting things that have already been done, or suggesting using some buzzword toolchain like it will solve all the problems.

If I were churning out web logic or designing dialogs or some such it can be useful I suppose - "You forgot a brace. Remember we have to try all these on the proto server first." etc.

But I spend my time on tricky problems in the core IP of our company. I've always had that job, wherever I work. And let me tell you, having someone in the same room is a no-go for the hours of mental model-building it takes to diagnose or design these kind components.

Now, let admit there are different kinds of programming jobs. Maybe the bulk of web design etc is amenable to having two shovels in the same ditch - of course you'd get more done, its obvious! But for other tasks it is absolutely not going to help.

Ouch. It sounds like the skill and/or knowledge discrepancy was too great. I've been in that situation before. If it doesn't get better after about 30 minutes, I say something like, "I don't think this is working out. Let's split up." If possible, I try to suggest something else to work on separately.

When it comes to code complexity, meta-studies argue against your claim. Pairing isn't worthwhile for simple code, but it's great for reducing defects in complex code:

The benefit of pairing is greatest on tasks that the programmers do not fully understand before they begin: that is, challenging tasks that call for creativity and sophistication.[1]

I and most everyone I've paired with have found this to be the case in our own work.

A side note: I'm not sure what your core argument is. Most of your comments in this thread seem to be a combination of self-aggrandizement, personal opinion, and veiled insults towards those who pair. I've tried to keep my own comments civil and evidence-based, but many others in this thread are full of negativity. It makes me sad.

1. http://en.wikipedia.org/wiki/Pair_programming#Meta-analyses

That sure sounds like a piece of work where a design discussion is necessary. However, I would not call a design discussion, pair programming. Find one or two others to help you hash out a design, but once you understand the problem, there is no need to pair program. Just build it, and call on the same people to do code review after you have built it.

A good professional engineering environment where you start a sprint by having a design discussion with peers, and then come back to your peers on the tail end of the sprint for code review, is likely to provide all the same benefits as pair programming.

After all, this is not supposed to be a software factory. Developing software is engineering work, and designing the work well, with your peers, will do just as much to strengthen the team and it will also improve the work quality.

Working in pairs is useful in bringing junior people up to the next level, and in helping newcomers learn the problem domain or the platform/framework that you use, but it is not a universal good practice that you would use all the time.

Sorry if I'm being insulting. I get that way when responding in kind.

There does seem to be more emotion than logic expressed here. I've meant to try to counter this with sincere expressions of my experiences. I must have gotten emotional in return. I'm at my wits end, trying to counter the simplistic claims of PP proponents that everyone else is a cowboy or just too inexperienced to 'get it'. I get it, I don't like it, I can see constant refutation of the whole idea of PP in my team.

Btw did you mean to use that link to support PP? It says things like

"reduce development time somewhat and produces marginal positive effects on code quality"

> Studies on pair programming show significant advantages in many circumstances

But do these studies take into account employee happiness (and thus potentially losing good developers)? In other words, is it better to have five mediocre engineers pair programming or having five stellar engineers working normally?

From section 6.4, titled "Work enjoyment":

All agreed that PP promoted the formation of good team spirit in the beginning of the project. The information radiator and the open workspace were also mentioned as contributors to good team spirit. Two of the developers liked PP more than solo programming and two found no difference.

Please at least skim references before calling them into question.

Thank you, FWIW I had read the abstract...I don't normally read (or skim) the entirety of every study somebody cites. But taking your advice I noticed 7.2 contains:

All the developers were recruited based on their interest in using agile practices including PP

Personally I would prefer not working in a paired programming environment, though I'm not sure it would be a deal-breaker. But I know developers (more introverted than me) who I imagine it might be.

While it probably biases the numbers a bit, I don't fault the study for picking people who were receptive to new practices. Picking people randomly and forcing them to change practices would just cause resentment.

Even though I enjoy pairing, I also doubt I would enjoy working at a place that required people to pair. Rules like that irk me. They're often a symptom of other, bigger problems.

The problem lies here:

> I don’t believe that I’m alone in my opinion. All of my colleagues are very similar. In my 20+ year long career, I’ve only known one person that I suspect would be comfortable with pair programming

So I can easily imagine that he was unlucky during his 20+ year career, because it is not easy to find such group of people especially in Age of Everyone Can Become a Programmer.

Add me to the unusually unlucky then. And all the guys I work with, or ever have worked with. At some point it becomes difficult to dismiss this opinion as 'someone who was unlucky'.

Reply on news.ycombinator.com