Slashdot Mirror
Experiences with Pair Programming?
gmletzkojr queries: "I recently was able to engage in some Pair Programming for a couple of days. However, my experience was less than rewarding. I have read books regarding the subject, and all of the case studies show praise for the effort. I found my pair programmer a bit difficult to work with. Has anyone been in this situation, and what things can be done to work around the personality conflicts?"
I've always tried to deal with personality issues when I hire.
I've also had significant success when using pair programming. It's a great way to make sure process is followed, it improves quality, and it spreads knowledge around.
It's a crock. You'll never, get anything done if two or more individuals are sitting down to code. The only point where you want more than one person is when you are actually doing design. Coding or programming, which is only one aspect of Software Engineering should be done by a single fully capable individual working on a small part of the overall code.
I was assigned to do pair programming with a more senior person. I got so tired of my suggestions being ignored (not disagreed with, ignored), that I just gave up and sat and watched him. The project had long since morphed into a Death March so this was just one more reason to loathe going into work each day.
If I ever get forced into another pair programming situation, I'll use my spare time to apply for other jobs.
It's simple: I demand prosecution for torture.
Things I would recommend:
- Communication. This is by far the most important quality to have as a pair.
- Patience. Sometimes your pair might not be at the same level you are, in this case, it is your job to help get them there.
- Assertiveness. If you have no clue what your pair is doing, ASK!
Other recommendations I have are to force your partner to drive if they are more inexperienced than you. This will help you both learn. If you don't have any idea what's going on then tell your partner you'd like to drive for awhile. I find this helps get you focused and allows you pick things up faster.
Of course, if your partner just isn't willing to cooperate, then I think there are other issues that need to be dealt with. But, for the most part, I think people are more than willing to teach others, you just have to ask and communicate.
Another thing to keep in mind, too, is to give it time. You aren't going to be a master pair after a few days or weeks.
I have found that along with Pair Programming, all code needs to be "group owned". Anyone can modify any code they think they need to. Having Pair Programming in this situation helps because you have a second set of eyes to keep your code as clean as possible.
Since all code is group owned you don't always have to have the same partner all the time, you just end up with whoever is available when you are ready to code. I can't imagine how Pair Programming is much of a benefit if the pair is always the same two people.
Of course, most of the time I have had a personality problem with a partner in Pair Programming was because I was being hard-headed and not willing to learn from my partner. If you are truly the expert, you will not feel threatened and will be willing to help your partner learn. If you aren't then the personality problem is probably caused by both.
As for what to do, let it go. Do your job and leave the problems out of it. If they are that bad, others will notice in time and the Pair Programming practice will work.
That's one good reason for pair programming, but it's far from the only one. Here are reasons I like promiscuous pair programming:
That last one is probably my favorite. When I'm on an XP team, taking a vacation is never a big deal, because I'm never the only person who knows how to do something.
Pair programming is like watching a woman change channels. "You know what's on this channel, it's shit, keep going."
If it's like that, you're doing it wrong.
For me, it's like the driver/navigator combination on a road trip through an unfamiliar city. Except it's better. If I notice my partner glazing over, I just shove the keyboard over to him. That's harder to do in a car.
Both of those things may be true, but there is a big difference between "not working in a vacuum" and "never having time to work on something alone and uninterrupted". A strong dislike of the latter situation does not imply that you are "not a team player".
As is often the case, the best programmers don't necessarily make the best programming teachers, nor vice versa. Sometimes junior guys will benefit more from a training course. Sometimes they'll get more out of working on something with a mentor available when they need one. Working full-time with a much stronger developer would just intimidate the hell out of a lot of people and cause their productivity to plummet.
As I said before, the art of good management is to make the best use of all your people. The first step to that is acknowledging their respective strengths and weaknesses. The second step is figuring out how to take best advantage of the former while avoiding the latter as much as possible. If that means taking a guy who can write excellent, highly maintainable code and leaving him to get on with it most of the time, so be it.
That would be an overly naive and/or arrogant attitude, unbecoming of a senior developer. However, the alternative explanation is that some of slashdot's moderators appreciate the point that this is a management issue, which needs to account for individuality. And while it's nice to know some people found my post insightful, I didn't make it for the karma, and have plenty of that already, thanks.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
... if you are not both effective communicators then pair programming will only be painful. You must be able to handle criticism, give criticism, and do so in a constructive way. If you can't do that then you're too old skool programmer for the new skool programmer ways.
[signature]
Programming doesn't introduce some new kind of situation to deal with that teams of two haven't been dealing with for centuries.
1. "their strengths have to fix your weaknesses, your strengths have to fix their weaknesses"
By far the most important. An old rule of thumb (before the Mythical Man Month) was that "if one programmer can do it in one year, two programmers can do it in two years." When and if the "two heads are better than one" comes enough into play, the answer can be two months!
3. "who is going to do what". Bad place for management to meddle. People tend to hide their weaknesses, even from management. When a team works, individual weaknesses are very well hidden from all onlookers.
4. "One system should keep track of what's going on."
Absolutely. In fact one bad system will beat two good systems.
You can tolerate different goals or directions. You cannot tolerate different positions of where you are now.
6. "Keep everyone else out of it!" Effective teams become very suspicious of all "foreigners", not excluding management.
me and my partner run a web development firm, after getting to know eachothers styles, it's a breeze now! we can colaborate together, or finish up eachothers work, it's a great experience. i guess not so much if you're just starting out with someone, but give it time and you'll love the benifits.!
Working in pairs can only work if each member of the pair has their own responsibilities, and not, like in most pair programming, the same responsibilities. For example, pilots can work in pairs since while one 'has the stick' or is talking to the tower, the other can be dealing with navigational and environment issues.
Sitting watching someone program is not the same, whether you're making input or not. Put it into the pilot's position. Pair programming is like the co-pilot constantly saying to the pilot.. 'er, nudge to the left a bit', 'hey, watch out for that cloud there', 'it's time to call the tower', instead of actually doing something productive.
Mechanics can work in pairs, but generally they'll be working on different areas of the car.
Surgeons can work in pairs, but each will have a specialty, or more hands are just required to do that particular op.
Musicians can work in pairs, trios, and so on. But they don't all gather around a piano and give suggestions to the person at the keys! They all have their own instrument and play at the same time.
If you want to code in groups, code in groups.. but make sure at least everyone has a keyboard!
Seems to me this approach would actually WASTE time. "What are you doing....why....how 'bout doing it this way....what's that...." SHUT THE F*CK UP! Seriously, you would pay 2 people to do the work of 1, it would likely take longer, & I really have doubts that the quality would be better. A different perspective isn't necessarily a better perspective, but developer A may go along with bad ideas just to get developer B to not A) keep talking B) tell the boss dev A isn't a team player. Personnaly I hate working with someone looking over my shoulder. This approach has too many flaws to mention...