I would agree. For most things, I don't find it very useful. Maybe if you're trying to learn how to use a tool, it can be worth sitting in, but for the plain mechanical tasks of coding, it's a waste of at least one person's time. If you're debugging something, you have to work at quarter speed or less - worse, if you've actually invested the effort to learn how to use your tools efficiently - as you'll be bouncing around too fast for anybody without a telepathic link to keep up with.
Bull sessions waiting for those slow-as-death Keurig machines everybody has replaced their good old drip pots with to finish making a tiny cup of coffee are just as good a use of your time, really.
It is cool for a really hard algo or for bringing up a new guy to speed. To do it 100% of the time? That is torture. I would not work in those conditions.
I worked at a place that had pairing stations at separate tables in the team area. We were supposed to pair when doing any coding.
In practice we paired when doing difficult stuff. It worked well.
Tips:
Don't pair at your desk. Use a pairing station.
Pair for a task, short if possible. If not, timebox.
Pair for short periods!
Train yourself to be productive while pairing. Don't relax. A short period of hard work.
Pick a consistent pairing time and make it a habit. Such as after standup, after lunch, whatever. Some times when you would not be productive solo, like after lunch, you can be productive in a pair. Experiment.
Failure modes:
Long, unproductive, exhausting pairing periods. People will quit.
That one guy that nobody wants to pair with. Happens, sorry.
Sitting there twiddling your thumbs while your pair partner writes an email. Only pair for coding / debugging / testing! Don't pair at your desk.
If someone has questions that are hard to answer without having the machine in front of them to point things out, sure, I or they will pull up a chair, and we'll both take a look at it.
But all day pair programming would drive me crazy.
Sure I'll do it...on a white board to solve a problem, or reviewing a spec.
Pair programming glorifies the task of programming as overly difficult. Solving problems can be difficult, programming them shouldn't be. Solving a tough problem in a code editor is not a good idea, IMO.
Some people think pair programming consists of one person sitting with another person at their disk taking over their workstation and having them just watch. This is actually horrible and hurts the body because looking at the screen for a long time in a weird position aches. I had this happen at an internship of mine before. I loathe that experience.
I used to work at a company where we did a lot of pair programming and enjoyed it a lot.
As a fast touch typer I preferred to be the one at the keyboard. I sometimes like to sketch things out first to test my initial idea.
I think pair programming can be extremely effective and fun when done in an ambitious work environment with open minded people who can work well with others. I much prefer doing pair programming than not since it's an opportunity to discuss requirements/design/solutions and also a kind of code review before the actual code review.
Coding on your own hides wrong assumptions, incorrect thinking, lack of teamwork/collaboration, misunderstandings and code quality issues which could likely to be found in pair programming sessions before a code review. It can be a great synergy when trying to solve complex problems where two people balance up different aspects of problem solving.
11 comments
[ 3.5 ms ] story [ 34.4 ms ] threadI just haven't had a great experience with it, though I remain open to trying it again.
Bull sessions waiting for those slow-as-death Keurig machines everybody has replaced their good old drip pots with to finish making a tiny cup of coffee are just as good a use of your time, really.
* someone I know and like.. I imagine being paired with a person you disliked would be awful
In practice we paired when doing difficult stuff. It worked well.
Tips:
Don't pair at your desk. Use a pairing station.
Pair for a task, short if possible. If not, timebox.
Pair for short periods!
Train yourself to be productive while pairing. Don't relax. A short period of hard work.
Pick a consistent pairing time and make it a habit. Such as after standup, after lunch, whatever. Some times when you would not be productive solo, like after lunch, you can be productive in a pair. Experiment.
Failure modes:
Long, unproductive, exhausting pairing periods. People will quit.
That one guy that nobody wants to pair with. Happens, sorry.
Sitting there twiddling your thumbs while your pair partner writes an email. Only pair for coding / debugging / testing! Don't pair at your desk.
But all day pair programming would drive me crazy.
Pair programming glorifies the task of programming as overly difficult. Solving problems can be difficult, programming them shouldn't be. Solving a tough problem in a code editor is not a good idea, IMO.
As a fast touch typer I preferred to be the one at the keyboard. I sometimes like to sketch things out first to test my initial idea.
I think pair programming can be extremely effective and fun when done in an ambitious work environment with open minded people who can work well with others. I much prefer doing pair programming than not since it's an opportunity to discuss requirements/design/solutions and also a kind of code review before the actual code review.
Coding on your own hides wrong assumptions, incorrect thinking, lack of teamwork/collaboration, misunderstandings and code quality issues which could likely to be found in pair programming sessions before a code review. It can be a great synergy when trying to solve complex problems where two people balance up different aspects of problem solving.