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?"
What is to be done about this? Ask for a different partner, maybe? Pair programming is useless if you can't work with your partner. This should be obvious. Not everyone is compatible, not with each other, and some people probably aren't even compatible with pair programming at all. That's fine, everyone's different.
Nothing will ever be a magic bullet. Pair programming, agile methods, and all that other crazy marketing-speak, it's just a procedure. If it works for you, use it, if not, try a different approach.
Random and weird software I've written.
Scenarios and results from my experience.
1) If your partner is more experienced it is usually annoyance for them and great fun learning for you.
2) Vice versa of 1.
3) Neither partner is experience or knowledgable enough to do the work on their own then productivity increases only slightly because you have two people trying to figure out new things at once. Also makes the job programming less painful for both since you share suffering.
4) Both partners are knowledgeable and experience enough for the work. It depends on the personalities of the people
4a) personalities are conducive to teamwork, super productivity! Project gets done fast, bugs are caught during implementation, everyone is happy.
4b) personalities not conducive to teamwork, super bad! Both programmers are knowledgeable and could therefore be doing more work if they each coded separately.
As long as neither partner lacks basic social skills and is not a complete loner then teamwork is usually good experience because you can enjoy the company and conversation of another programmer while you work.
The GeekNights podcast is going strong. Listen!
I found my pair programmer a bit difficult to work with.
That's actually the whole point of pair programming. It's supposed to slow you down so you make fewer mistakes.
The main thing it does for me is keep me focused on working. It's also good when there's a hairy problem to figure out. But sometimes when it's time to just crank out some straightforward code without getting distracted it's better for one person to go take a break for a while.
Not really anything different than working with any other person. Programming doesn't introduce some new kind of situation to deal with that teams of two haven't been dealing with for centuries.
So, my tips, just coming off about a year's worth of pair work:
1. The most important thing is that you have to be complementary. That is, their strengths have to fix your weaknesses, your strengths have to fix their weaknesses. If they don't have any strengths, it will be more like training for them, a mentor/student situation as opposed to a true team.
2. Think of it as a product. If "average" or "baseline" is 1, it helps if you're a 2.1 and they are a 1.4. If you're very good and they're not, the total suffers. Only work with someone that is as good as you or better, and only do it if you're very good to begin with.
3. Define exactly who is going to do what! This is not terribly succesful when managers do it because they're not you two -- they can't see you in action and suggest anything. It's up to you to figure out what works best --- split up all the different tasks so that each of you are doing what you do best. As you go along you will find out whether it's better to write these down and adhere to them or (better yet) have them be somewhat fluid so that some responsibilities cross over.
4. One system should keep track of what's going on. Whether that's a calendar you both use, a checklist pinned on the wall, an eraseboard, or just one of you two.
5. (Regarding the previous). Think in term of goals, not minutiae. You both should be good enough that if you're, for example, auto mechanics, one of you says, "Find out where the noise on the Pontiac is coming from" rather than saying "From 10:30 to 11:00 I want you to inspect the following parts and pieces of the Pontiac: A, B, C, D..."
6. Keep everyone else out of it! Once a system is established and you've learned to rely on each other it's going to be really obtrusive to have others meddle in.
7. Meet together with management whenever possible.
8. It helps if both of you have similar goals as to the level of your performance. Even if both of you are skilled gurus and one of you is checking job sites because they need to leave in the next six months, that's not going to work out.
This is, as I said before, from about a year's experience working day-to-day with only one other person. I hate paperwork, don't really like a lot of "busy" work and, in both cases, the other person just wasn't very good at some of the major intricacies of the position. The first time, we were more succesful than either of us was alone (generally being 2.5x times as productive as any individual). The second time, we were doing about as much as eihter of us were doing individually.
The good thing is that now I'm back by myself and have become a lot better thanks to the teamwork environment. I wasted a couple of months, but that's behind us now.
Small potatoes make the steak look bigger.
I think the best approach is to pair an experienced person with a less experienced person, and make it clear to both that the more experienced person had two votes and the less experienced had one in any disagreements.
;-) He's the only one in his group I'd be willing to work that way with, though.
I wouldn't mind being partnered with someone with a lot more experience. I would consider it an opportunity to turbocharge my own learning, and though I would ask lots of questions and might even gently challenge some decisions, I would make it clear that they were HIS decisions to make, even if the boss didn't manage it that way.
I also wouldn't mind being the senior partner as long as the junior understood that, though I would appreciate his input, the decisions were mine.
Two inexperienced people shouldn't be paired. All of their arguments will end up being over who is able to make who back down. Complete waste.
I would also be willing to be paired with another experienced person, with my (senior) level of experience, if it were the right person. It would be harder to make this work with two arbitrary people than the case with unequal pairings and one guy in charge. In the case of two experienced people, if you had to specify which one was in charge, it probably wouldn't be a good pairing.
I had a discussion with another senior architect (like me) the other day, and both of us agreed that it would be fun for us to try pair programming together some time because both of us have concluded that the other has expertise that we wish we had.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
First of all, I think the problem is with you. Here you are asking us for feedback on pair-programming, but you barely tell us what problems you encountered. Do you just sit with your pair and say "all this shit is fucked up?" You should probably tell us the specifics of the issues, at the very least for our education, and maybe someone can address them more specifically.
Anyway, just kidding. Didn't mean to attack you personally, just consider what I said.
I find sitting and developing with someone very useful, especially if this person is new-ish and I want to bring them up to speed. Basically I watch them do their thing and comment on what they're doing, especially if it could be done better. This is certainly very effective at keeping them from putting in silly errors, because I spot those right away. But the real advantage is that from short sessions like this I can ascertain the person's grasp of the task. If I can see that he's basically looking at the right things and going about it the right way, I feel OK with going back to my desk and doing my stuff. If the guy makes a lot of errors and is generally approaching things the wrong way, good thing I am there to keep him from getting too deep.
I would guess that mandating 2 programmers per computer at all times is too much, but there certainly are times when doing this for short periods of time is extremely productive.
Ecce Europa - Web Design for Business
Grow up and get on with your job.
some of these so called "experienced" developers are completely idiots with no real skills. There are these terrible hacks who know little about good practices and aren't willing to learn. I think we've all seen this before. If I ever get paired with one of these types, I would lose it, working with them on the same project is bad enough. They break the build constantly, keep files checked out for no reason, make rookie mistakes constantly, get you to help fix a problem that was their fault yet act like it was yours, etc. Experience does not mean someone is a good at what they do.
Pair programming is a crutch to prop up people who have no clue what they're doing. Take one smart person, one thumb twiddler, and they just might be a quarter as productive as the smart person alone. But we don't mind, because Mr. Thumb Twiddler isn't twiddling his/her thumbs anymore. And getting things done isn't nearly as important as making sure everyone looks busy.
The only way to program is on your own. Learn stuff from more experienced people at code/design reviews. If you need someone staring over your shoulder all the time, your either very lonely outside of work or just incompetitent on your own. Sometimes there's something tricky enough to warrant talking it through with someone, but doing it all the time is just being chatty.
When we were pairing around here (gave it up, not appropriate for this business model, etc...) we got over this in the first day.
Our Driver could type all of the mistakes he wanted to, but since the Navigator was doing the big picture stuff too (in addition to being an observer) he could indicate just before the driver switched functions/files/pages that there were problems. So your conversation would have gone more like:
Navigator: Modify that bit in Foo.bar() to do such-and-so.
Driver: clickety-clickety
Navigator: (Quetly noting mistakes.)
Driver: clickety-clickety, fixing some mistakes he's noticed, making others Okay, now where?
Navigator: Before we pop over to Class.method(), that variable should have an uppercase Z and you want to pass obj1 to method bar() not tmp1.
Driver: Okay. clickety-clickety Going over to Class.method now.... mousey-mousey
The Navigator isn't backseat driving and the driver can type things any way he wants too as long as he doesn't leave a mess somewhere.
Get off my lawn.