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.
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.
When I first looked at the comments this was my fortune:
It's hard to be humble when you're perfect.
Think that may relate to this issue, as others have commented on personality conflicts.
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!
"Type foo"
"What?"
"There, foo"
"Oh yeah, ok"
"No, foo"
"Oh right"
"Oh for fuck sake.. FOO, the keyword is FOO"
"Oh sorry, was thinking about something else"
Pair programming is like watching a woman change channels. "You know what's on this channel, it's shit, keep going."
How we know is more important than what we know.
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.
Hey! You were no rose either. And that whole printing routine was a farce. And its YOUR FAULT. I suggested something different but you had the keyboard. And speaking of which-you hogged the keyboard the whole freakin time too!
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.
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.
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.
... 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]
Right now I'm taking a real-time and embedded systems course at RIT. The idea is that it's inter-disciplinary: CE, EE, CS and SE students are taking the course.
So for the projects, they pair a CS or SE student with a CE or EE student. This makes for teams with one person who's strong in lower level (assembly/ hardware) work, and another who's more familiar with higher- level programming concepts.
I've found that while my teammate knows the assembly much better than I do (I'm SE) I can more easily grasp the overall design and algorithms involved to complete the task. This actually made for very productive work since it's like having two different perspectives working on the same puzzle.
I imagine that if both of the ppl involved were at the same level knowledge-wise, it could get frustrating. In that case I would just look for peer review. But in my case it's been working great.
Driver: click, click, click, tappety-tap tap tap, click.
Observer: Dude, Intelli-sense just underlined that word in red. It's some kind of syntax error -- just hover your mouse over it to see it.
Driver: Ya, I saw it ... I just want to finish up what I'm typing and ...
Observer: It just underlined something else in your code. I don't think it's gonna' compile.
Driver: Of course it won't compile. Just wait until I finish this thought .... tap, tap, clickety click, tap-tap
Observer: I would fix those errors before continuing.
Driver: WHY? clackety-clack, slam, bang
Observer: Why not?
Driver: ARGH!
Observer: I'm bored. I'm just gonna' go grab another coffee.
Driver: GO AHEAD. AND WHILE YOU'RE AT IT, HAVE A SMOKE, AN EXTRA LONG LUNCH, AND THEN TAKE THE REST OF THE DAY OFF BECAUSE YOU'RE NOT LOOKING SO GOOD RIGHT ABOUT NOW.
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!
If you're lucky and work on OSX you might want to try out SubEthaEdit.
You can browse other user's open documents via Rendezvous - errr... OpenTalk, grant them access to your open docs. And nice colors so you can see who is breaking what.
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.