My colleague Jay Fields has a nice post about pair programming, when it's good, and when it's not so good. I wanted to add to and amplify his remarks a bit. Basically, anytime you pair two developers of vastly different skill sets (what Jay calls a "spell checking pair"), that's not pair programming: it is mentoring. That doesn't mean that it is wasted time, but it is a different activity.
I find that mentoring is tiring for both the advanced and novice developers: tiring for the advanced developer because they have to go slower than their natural pace and tiring for the novice because they are having to peddle faster to keep up. However, mentoring is a great way to greatly increase the skill level of the novice. If you are going to mentor, it should be for just part of a day. After the mentoring is done, switch pairs with more matched levels.
A lot of companies seem to think that's what pair programming is: take a intern from college and pair them with an ace to build up their skill level. All that does is stress both.
We are generally careful when engaging with clients to pair program with their developers to determine if the project is enablement or delivery. If it is delivery focused, we tell them that the more senior developer may well leave their pair in the dust, and should be reorganized. You can't usually do both enablement and delivery at the same time except in rare circumstances.
Subscribe to:
Post Comments (Atom)
2 comments:
Reminds me of when I used to play Everquest. Sometimes you could find a much higher-level character to walk you around and help you kill things you wouldn't normally be able to kill in order to gain experience very quickly.
It was never useful for the more experienced player to do this, but you could really boost yourself if you could convince someone to do it.
I spent the last 5 years doing pair programming... and slowly learned to hate the practice when enforced by policy.
At first it offered me a fast introduction to the codebase and I became productive quickly. Later, mentoring other developers was useful as well.
The problem was we used pair programming for all production code, no matter what. Like all tools I found this practice can be over used.
Some problems are so simple another programmer is just a syntax checker no matter how matched their skills.
Some problems (for me at least) require solitary thought, code inspection, research, and/or experimentation.
I (almost) never get "in the zone" when pair programming. This experience is what I love about programming. For me pair programming is most often akin to reading a great book and occasionally having someone come by and flick your ear or ask what you are reading.
Finally I found that my knowledge wasn't gaining the depth I was used to having in other codebases - I kept relying on the "other brain" to store knowledge. The practice of collective ownership and pair programming kept me jumping all over the codebase so it never became a living model in my head.
My next job starts in two weeks and pair programming isn't required (nor will it be at any place I ever work). But I will use the tool when it is effective (mentoring is something I enjoy, from both sides).
Post a Comment