Hacker Newsnew | comments | show | ask | jobs | submit login

I'm going to go against the grain here and say that after almost a decade of trying, pair programming is just not for me, for a few reasons:

1. Cluttered thoughts

When I develop software, very little of that time is spent typing. If you were to watch me program, what you'd see is someone sitting in a chair doing nothing. Before I write a single line of code, I'll examine my future program in my head, poking, prodding, trying out different approaches, weighing the benefits, considering edge cases, and so on. I cannot do this if distracted by talking or typing, as it clutters up my thought process (unless the task is quite trivial). Because of this, pair sessions tend to be awkward, with me not saying much and not typing much 90% of the time. What I can do effectively is design a system and then ask someone to critique it before I start coding it out.

2. Social exhaustion

I have a hard enough time dealing with the exhausting process of social interaction as it is. I don't avoid it entirely, because I know that it's important. However, my mental stamina is also important if I'm going to be doing anything useful, so I try to strike a balance between social obligation and isolation. I've never paired for more than a couple of hours, which is draining and becomes stressful before long. I can only imagine that I'd be climbing the walls after 8 hours of that.

3. The zone

I like programming in the zone. Everything becomes so easy and flows so nicely, but it can sometimes take a long time to get into the zone, and it's fragile and breaks easily. I find it impossible to enter the zone if I'm talking.




I used to feel the same way. It largely depends on who you are pairing with. Nearly every experience for me was unique. The part I keep chasing after is your first point. I usually work that way when solo. But with a good pair, it is the same effect without all the planning. If the other developer is just as good as you are, you will inspire each other. One of you will try something that doesn't pan out, but with give the first a new idea that does. It is an amazing experience when it happens, though a bit rare.

The exhaustion you get used to. I feel more tired after 8 hours of pairing than 18 of solo.

-----


It hardly seems worth the trade-off. The more exhausted I am at the end of the day, the less inspired I am the next day. And trading two (experienced) developers' time for a rare chance at an epiphany doesn't seem worth it, either.

-----


I meant that it was rare to find a pair that you function like that with. If you have two senior developers who can do this and are not letting them pair, you are introducing serious amounts of waste.

-----


Couldn't agree more.

There seems to be a strong correlation between people pushing pair programming and people I wouldn't want to work with in the first place.

-----


I love pairing. It is the right thing for me, and I work in a company that has pairing in its core culture. Feeling that pair programming isn't the thing for you is your choice and it probably works out well for you, but you wouldn't be hired by my organaization, or Braintree. That's the point that the blog post tries to make while also talking about virtues of pair programming. Not that it is for everyone and anyone who doesn't do it is foolish.

-----


Yes, I definitely wouldn't work for a company that has pair programming in its core culture. I also wouldn't work for a company that has standing desks in its core culture, or Perl programming in its core culture, or Emacs or vi in its core culture. In fact, I avoid monoculture as much as I can, because it stifles innovation by reducing diversity.

-----




Applications are open for YC Winter 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: