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?"
Acknowledge the personality conflict with your partner to your partner and then don't let it get in the way of your work.
GPL Deconstructed
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.
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.
Guy at KB: "would you quit breathing on me!"
Guy not at KB: "Hey! your no rose either!"
Or any variations you can come up with.
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.
I fell in love with her.
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.
you should never participate in pair programming when naked.
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.
In my most recent contract I've been working with various levels of experience and switch between working solo, teaming with an associate at the same workstation and working remotely on several junior associates workstations. For those that are significantly less experienced I've found that remotely accessing their desktop to demonstrate or help with a problem/question to be very useful, plus I can help more people in a shorter time. I get to continue working on my assignments at a steady pace and they can still work at their own pace. For more the more experienced, it just saved us time, and a long walk (although we all could use the walking!). Either way it was good because we could all maintain our own personal spaces, weren't so constrained by other people's schedules and didn't have to change contexts. While the other was testing a routine or some other long process, I could review documentation or even continue working on my assignment. Team programming doesn't have to be always at the same workstation all the time.
... 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.
Over the summer I had to do an "extreme programming" project. The group had three members, including myself. I was the 'code monkey' type. I took care of the libraries and helper functions and regular expressions and filesystem quirks. The second member was the database guy and front-end guy. Since both of us could to an extent do the job of the other while being primarily focused on separate components, this worked well. We sat down and worked on our own stuff. Occasionally we would request functions of each other, and rarely a problem would crop up that benefitted from combined knowledge. The most useful part of having someone sitting next to you was when you have those brain fart moments when you can't figure out why the thing doesn't compile or work properly. Then your buddy looks over and points at the spot where the close-brace should go and everything is rosy again. Despite having never worked together, we quickly came to trust each others work. On the other hand, the third member was useless. No matter what work was assigned to him or requested by him, he could not accomplish it without major help. He did not make any deadlines until nearly the end of the project. Even then, everything he produced had to be rewritten or overhauled. He was eventually banned from putting functions in the libraries because he had a habit of working from old files and wiping out our good working copies. Despite his enthusiasm and willingness to make a great effort at trying to learn, I cringe at the thought of working with him again or using anything he produces. He will probably end up working for Microsoft. (Other than all that, I have nothing against him. Nice guy really.) The Point: It all depends on who you work with.
It helps to have a thick skin. The only times I've done pair programming we end up making fun of every little mistake the other makes. It's fun and funny with the right person, but with the wrong person this can go too far.
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.
I actually like the working together fact. Not on a regular base, but for complex stuff it is quite usefull. So while we were having two laptops and a screen session to a file I asked out loud:
Why don't we have two carets in the same file so we can edit both at the same time.
If someone knows an editor capable for this groupworking please reply.
Support Eachother, Copy Dutch Property!
SubEthaEdit.
Well, if you have Macs, that is. I've heard great things about it, and it's shareware so you can try it out for free.
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.!
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
Ummm...that doesn't sound like extreme programming...more like collaborative programming.
Extreme programming is where you both work on the same code, on the same monitor, with one doing the typing.
Always reminded me of the Dilbert cartoon where the PHB stands over Dilbert's shoulder and screams "Click the mouse" but then extreme programming seems to be designed for people who look at coding as something to do only at work.
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!
I think pair programming can be useful but I think it is important to pair up programmers of similar skill level.
I like the concept of pair programming, but it seems in practice it's hard for everyone to get behind it, and there are other things you can do that are just as good. Like, you can get everyone in the same room with their computers close together. You can occasionally ask "what are you doing now?" and solicit opinions on your own tasks. You can give show-and-tell sessions every day. You can help write unit tests for someone else's code. If everyone understands the high-level issues, and the priorities, and helps each other occasionally, that's what matters.
No two people think alike, regardless of any equality of externaly measurable/testable aspects of their intelligence. So what is left to fix? Their EGOs. My understanding of the theoretical advantage of this approach is that it is like the discovery that you could more easily make a waterproof super-thin rubber membrane, despite the tendency of the raw material to have tiny holes, by laminating two thinner membranes: the defects never line up. Two programmers are not likely to have exactly the same blind spots in devising a piece of code. But in practice, the more the two ego's just happen not to get in the way, the sooner the two begin to work just alike, with one merged perspective whereas two competing perspectives were actually the root of the benefit. Back in the 70's the term "egoless programming" was briefly in vogue for conducting code reviews...in my experience it WAS an improvement in quality for code production. Even when it was not better code, at least it had better comments.
But DAMN I HATE IT WHEN PEOPLE LOOK OVER MY SHOULDER!
SLASHDOT: news for people who can't concentrate on work or have no life at all and got tired of yelling back at the TV.
You can dig a hole in a ground, and fill it with water, with shark that have frikkin' lasers on their heads and then toss that guy in it.
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.
I often pair up with a friend of mine on projects - not necessarily programming directly, but sometimes technical stuff (design, implementation, etc with programs already written). My friend is doing his Master's in CS, and I have one year of an Arts major done. Suffice to say, he's the better programmer.
What I bring to the team, however, is the big picture. I can design in my head in a few moments how things should be laid out and the possibilities of each option, I know enough about languages to pick the proper tool for the job, and I know enough about programming to provide input in that respect when it's needed.
Teaming up two programmers with the same skillsets might be handy from a catching-bugs point of view, but the two of us working together with our completely different skillsets works great from a design-and-implementation point of view, since I can do the design and he can do the implementation, but we each know enough to help with both.
That's what pair programming should be. Not two C wizards sitting down nagging at each other, but two people who know C and who know design, but who are only excellent at one or the other, to bring different skills to the table, and defer to the other in their areas most lacking.
--Dan
I had to do a kind of emergency-coding-session with my boss, he had dawdled on a project and then management applied thumbscrews, so we decided to just crank it out in a week.
I started as copilot, and didn't like it very much, since I was the one who had come up with a new design for the program (when meteorologists make data file formats, parsing them in real time without delays can be an exercise in ingenuity). However, my boss was very good at driver and appreciated someone to keep him focused when he was diverted by code details.
On that day, we wrote about half the project, about 750 lines of code. It worked well once we got the rhythm down. Afterwords, we were both really tired. The intensity of the activity surprised us both. It is more work than just coding, and until you're used to it, you may feel like it's a lot of work.
My boss though, basically refused to play copilot and only checked in with me ever 15 minutes the next day,so I had to finish the project on my own (the other 600 lines of the project went quickly).
Still, when it worked, it worked well, and I can recommend it. But, it does take a conscious effort to let go of your ego and a lot of effort to listen careful.
Slashdot. It's Not For Common Sense
I don't see what the problem with Ego is, it can be a very good driving force, I've worked longer and harder on projects just because of my Ego, I know I can do it, my Ego knows I can do it, but doubt will hold you back, Ego can drive through Doubt. Not to confuse Ego with Arrogance, I know of others skills, and when to rely on their knowledge over my own. Ego is good, Arrogance is bad.
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...
IMO
Pair programming is just training each other. For example when putting modules together - say module A has calls to module B - then it could be helpfull when the programmers of A and B get together and while A is typing his code programmer B instructs how to use module B.
In any case, pair programming should not be done full time, some things need to be thought out without distraction. If you can't get any work done on your own then you're a lazy ass or just incompetent.
But i'am not a pro, so what do i know.
"...Why don't we have two carets in the same file so we can edit both at the same time..."
For the same reason that cars don't have two steering wheels up front.
You're renaming/deleting class member variables in your editor view, while your buddy suddenly sees the member functions he's working on fall to pieces, because they depend on those variables?
Of course you could tell him what you're doing, and he can wait until you're done. And like many world-beating multi-threaded concepts, it is degraded into a single-threaded way of working in order to avoid those pesky race conditions & deadlocks.
This is a simplistic objection. Coming up with more horrific examples is left as an exercise for the reader.
T&K.
Political language
I posted the original topic and read through many of the comments that have been made. Some of you asked for more info, so here are a couple of my return comments.
I initially wrote a couple classes to perform some messaging, and maintain some states of objects. The code was to integrate into an existing system. I was to write the logic of the new feature, and (as a pair) we were going to integrate the new code into the system. However, the other half of the pair didn't bother to read any of the code prior to us meeting - instead, he just waited for me to tell him.
My partner was essentially put in charge of the integration from our boss - he drove the couple of days we worked together. However, even though he asked for guidance, he wouldn't actually listen to what I had said, until multiple failed attempts on his own.
As far as the obvious issues (hey, you smell bad!), they really didn't come up. And I'm sure we could all take the high road and inform the boss of the incompatibility between us, but, in the end, the code needs to get done. My pair was a competent person, but seemed to wrap his brain around the problem at hand late in the game.
In case anyone was wondering, the completed system did work successfully.
I for one welcome our new [insert main topic] overlords.
This is interesting: http://www.agiledevelopmentconference.com/files/XR 1-3.pdf/ (pdf format)
It describes how, on one project, a team from Thoughtworks chose NOT to pair program. They still had a "buddy" system though, and that replaced pair programming.
Having spent the past two years pair programming I am left with a negative impression of its practicality. My experience has shown that the amount of time saved by the other person catching something that you may have done incorrectly (from a typo to pure coding error) is only a fraction of the time wasted explaining what you were thinking and why you coded something that particular way. I agree with an earlier comment that design is best done in groups but coding is a solitary task. Having someone looking over your shoulder performing a real-time code review is more distracting than helpful. If the design was done properly the coding can be done by one person. A proper code review, after the code is written, will address the issues that will be caught by your partner without interrupting you mid-thought because you missed a semi-colon. I am not sure that this holds for everyone who writes code but, in my case, I tend to get into a stream of consiousness and the code flows from that, if interrupted just because I misspelled a variable name or didn't properly indend a block of code can can pull me out of the stream and it takes some time to build the momentum back up. especially when the compiler would catch any syntactical errors.
Group Flow is a different thing, but it's even more powerful than single flow.
I got the power when it comes to creative and unusual ideas, but I get easily distracted into investigating all those ideas. When I work with a good partner, they point out the flaws that are obvious to them and things move a lot faster.
My experiences with PairProgramming were euphoric, each time my partner and I produced far more high quality code in a few hours than I usually produce by myself in days.
Anyway, the point of 'Agile Programming' is to be agile, you wiggle around till you find what works for you and the rest of your team. If you try pair programming and it doesn't work for you, don't do it.
One important part of eXtreme Programming is that qualified people make decisions, programmers make tech decisions, and managers support the programmers who are actually doing the work.
That means pair programming or whatever should not be mandated.
The idea of XP is to form a tight and smooth team, like a jazz band, where everyone can jam together. Whether you like Acid Jazz or prefer something closer to Blues, it's the choice of the team, and every team is unique.
Shae Erisson - ScannedInAvian.com