

Pair Programming Might Be Great - aria
http://posts.dynamictyping.org/how-pair-programming-might-be-great

======
sp4rki
I agree that pair programming has it's place and can be a positive workflow
for some, but for the way I work I just find it extremely intrusive and I
easily get a third of what I would get done. I'm a big advocate of peer
reviews, but pair programming just takes me out of my workflow and impairs my
creativity and performance.

------
parfe
In my work environment I find "pair programming" to be useful the 5% of the
time someone is working on a Hard Problem. Most time during the work day is UI
tuning, debugging, and generic implementation of straightforward features.

Pair programming doesn't need to be a policy because it precipitates naturally
out of someone asking for help on a Hard Problem. That 5% of the time you're
working through a tasks key algorithm, or discovering the best User
Interaction for a complex feature.

I find Pair Programming to be a important sounding label for something which
is actually quite mundane. It's called working together™.

It's a waste of my time to sit and watch someone implement the 95% of software
that is mundane.

~~~
mattrepl
I agree with your dislike for relabeling the mundane, but "pair programming"
is used to indicate a specific form of collaboration which includes the the
three points mentioned in the post.

The sort of collaboration you're referring to is what I'd call brainstorming.
Pairing with someone only for brainstorming purposes would be wasteful.

~~~
parfe
So when does putting two people together for mundane tasks have any benefit?

~~~
mattrepl
First, let's agree on the definition of mundane as used here. To me, your use
of mundane suggests the task of writing a program after high-level questions,
what and why, have received high-level answers. Everything but initial
brainstorming.

The hypothesis introduced in the article is that pair programming is
beneficial because it improves individual skills and code quality. I'm not
sure how clearly that's communicated.

Individual skills are improved by understanding your current problem-solving
process and upgrading it as necessary. This isn't only about picking up skills
by observing others, but reasoning about the steps you take and updating as
appropriate. Pair programming isn't necessary for this, it just facilitates
it. This whole being mindful thing deserves a post of its own.

I would expect that code quality would be improved because design flaws and
bugs are more likely to be caught early. Therefore there's less time spent
rewriting or debugging.

I'm treating this foray into pair programming as an experiment. It was
literally a week ago that I began to see how pair programming could be
efficient and even enjoyable. I do not plan on doing 100% pairing forever,
it's impractical and probably inefficient. Right now I'm thinking that 50-75%
pairing might be an optimum in most cases.

------
levesque
If you are paired with the right person I believe this has the potential to
drive you forward and keep you motivated. I experienced pair programming when
I was still studying.

We had a lot of team assignments and when I worked with my best friend,
instead of splitting the work like most of the other students, we just sat
both in front of one computer and went through all of it. The one guy writing
the code is always getting double-checked by the other guy and that way you
eliminate most of the little bugs that slip past your judgement when you code
alone.

Certainly a most enjoyable method of programming, although whether it is an
economically viable strategy I could not tell.

~~~
joske2
On my dayjob we did some experiments on wether or not it was economically
viable. So we tried classical programming and pair programming. We found that
classical programming was more productive, but not twice as productive.
However there were a lot less bugs found after an iteration of pair
programming. When we factored that in, pair programming did end up being the
better choice.

------
alimoeeny
Like 10 years ago my best friend and I used to sit at the same computer and do
the coding and UI design together! It was not all the time but it was a
significant part of the day. We were developing mostly ASP pages and he was
the UI designer and I was the backend coder and it made sense to go do our
part then get together and merge them and then go back to do our part again. I
really miss that time very very productive we were.

