Experiences with Pair Programming? 125
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?"
Hmmm (Score:2)
Re:Hmmm (Score:1, Funny)
1) Pull the US military out of Iraq.
Re:Hmmm (Score:2, Funny)
Well said. (Score:2, Insightful)
Grow up and get on with your job.
Personality Problems... (Score:2, Interesting)
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.
I too find my coworkers difficult to deal with (Score:5, Insightful)
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.
Re:I too find my coworkers difficult to deal with (Score:3, Interesting)
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
Re:I too find my coworkers difficult to deal with (Score:3, Insightful)
I think I fall into this category. I would probably fall asleep when my partner was programming, and when it was my turn at the keyboard, I would erase everything he had done and do it the way I wanted it done.
Re:I too find my coworkers difficult to deal with (Score:3, Insightful)
It's good to change pairing parters every 2-4 hours. That's short enough that you should be able to deal with anybody on your team, and long enough to get something done and checked in.
Also, learning to pair is exhausting. When people are first getting used to it, I encourage them to work into it slowly. E.g., 1 short session the first day, 2 the second, and so on.
perhaps this is relevant? (Score:3, Funny)
It's hard to be humble when you're perfect.
Think that may relate to this issue, as others have commented on personality conflicts.
Re:perhaps this is relevant? (Score:2)
Re:perhaps this is relevant? (Score:2, Funny)
Well, maybe she's a screamer.
Not my business, I guess.
Re:perhaps this is relevant? (Score:1)
Not that I'm an expert but having dealt with many personalities over the years, I think the fact that you are introspective enough to even think about this and then post it where everyone can see means that you don't have a real problem. If you're really concerned, look up intJ [typelogic.com] personality types and read a little Venus/Mars and you'll be fine.
Re:perhaps this is relevant? (Score:2)
i don't have to be a jeenius to know i are one.
Sounds like... (Score:1)
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.
My Experience (Score:5, Insightful)
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.
Re:My Experience (Score:2, Insightful)
Totally agree, it all depends on how good the communication is between the two persons. If it's not good, try with omeone else. I have had some great experiences with pair programming with experienced people. It's just good when both are experienced but have different kind of knowledge. This way, both will focus on different aspects and make the entire thing better.
On the other hand, if both have totally different approaches to the problem, it can cause a nuclear war, especially if both programmers have
Re:My Experience (Score:2)
Well, this is true whether or not you're pair programming. It's just that in pairing, you get to find out about the conflict before the code gets written. That's generally the best time to resolve things. And if things are hard to resolve, it's often a sign that
Re:My Experience (Score:2)
They're not? Woah.
Re:My Experience (Score:2)
Different skill sets. That's the crux. When it works, it dominates everything else.
On the other hand, if both have totally different approaches to the problem, it can cause a nuclear war, especially if both programmers have a large ego.
If both egos are after the same turf, you will have problems. With a bit of skill in working in
Who's in charge? (Score:5, Insightful)
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.
Re:Who's in charge? (Score:5, Interesting)
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.
Re:Who's in charge? (Score:2)
And it th
Re:Who's in charge? (Score:2)
In many cases, the amount of time saved on code creation, bug catching, and testing far outweighs the initial investment of two developer's time. If the code is better and contains few bugs, it is worth a lot more than the same mass of code with far more bugs.
Re:Who's in charge? (Score:2)
Therefore? That may or may not be true, but you've proven nothing.
Between me and the previous poster, we listed 11 things that pair programming improves. If those have any effect on productivity, then that changes the productivity ratio. The only thing that's 2x in pair programming is the hand/keyboard ratio, so your theory would only be true when typ
Re:Who's in charge? (Score:2)
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.
This is not my experiance.
EWither the topic is not important, then they will really fast solve it by chosing either of the two approaches.
If he topic is important, the one who is wrong will very likely understand the arguments of the other one.
Smart people usually want to get the job done and move forward to other interesting "problems" like anyone else.
If the
Re:Who's in charge? (Score:2)
I think the reason we disagree on the question of two inexperienced people being paired relates to the source of the disagreements between them. You are talking about "the one who is wrong" as if in most disagreements one will be right and one wrong.
In my experience, almost all of the disagreements are over personal preferences regarding how to do handle something. "We should use a 'for loop' because... No, a 'while loop' is better in this case because...." Or
Re:My Experience (Score:1)
hm, sorry to answer to your post, as your analysis is quite ok.
Most posts here are really negative. I wished that most of you would start your post with: I've never done it.
Bottom line: only the posts starting with: "I've done it" are relevant.
I was allways wondering about an "Gedankenexperiment" (I know this is an english term
Re:My Experience (Score:1, Offtopic)
Slashdot needs a spellchecker.
Re:My Experience (Score:2)
You saw that post on
angel'o'sphere
Re:My Experience (Score:2)
Re:My Experience (Score:2)
I think this about sums it up. I've never done this in a work-environment, but can easily guess from doing programming in the CS-major-only lab. Man did I hate 1 / 2 when the other guy was a real dumbass and didn't really care. You have to laugh at 3 if you overhear them talking to eachother from a distance. 4a was the best though. How I wish I could have 4a and still be self-employed. Nothing beats writing a huge chunk of code and finding all the bugs simply because another great programmer is looki
Re:My Experience (Score:5, Insightful)
I've seen this mistake in numerous contexts, from programming to pairs sports. If you put two people together of very different abilities, there really is very little for the more senior partner to gain. Sure, they can pick up the odd thing occasionally, but not enough to keep them motivated and justify the time they "waste". Likewise, teaching can be a useful way to solidify knowledge, but that only works if the abilities are different but not too different. Getting a world champion to coach an absolute beginner will be frustrating for both. Getting a 20-year veteran to teach programming 101 to a newbie by drip-feeding on the job will be frustrating for both.
The art of good management/coaching in these situations is to pair up appropriate people, and only appropriate people. If you do, it can be a rewarding experience for both parties. If you don't, the senior guys will simply decide it's not worth it and walk away, leaving you with only the junior guys left. Good management consists of making the best use of all your resources, not dumping half the guys with things they really don't want to do and calling it "teamwork".
FWIW, I don't rate full-time pair programming in most places. IME, a culture where junior developers feel able to ask for help as often as required and senior developers are happy to give it whenever they can, and where training and review are taken seriously, gains you most or all of the benefits without anyone getting claustrophobic and feeling under permanent pressure. This has been the case in pretty much every good dev team I've ever worked on.
Re:My Experience (Score:1, Insightful)
Re:My Experience (Score:3, Interesting)
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
Re:My Experience (Score:1, Flamebait)
I've seen this mistake in numerous contexts, from programming to pairs sports. If you put two people together of very different abilities, there really is very little for the more senior partner to gain. Sure, they can pick up the odd thing occasionally, but not enough to keep them motivated and justify the time they "waste". Likewise, teaching can be a useful way to solidify knowledge, but that only works if the abilities are different but not too different. Getting a world champion to coach an absolute b
Re:My Experience (Score:2)
Hmm... Your posts are usually much better than that, so I'm guessing you're tired, drunk, or high. Fair 'nuff.
In any case, I think you're making my point beautifully. Of course children can be a source of great joy; I'm not challenging that at all. Many people would also enjoy teaching a newbie programmer, or gain a sense of satisfaction from helping someone less experience out on-line. (In my real life guise, I've got thousands of newsgroup posts logged doing just that.)
But a child will not teach a 25-
Re:My Experience (Score:2)
You are right. But most posts ANTI pair programmng are ephasizing the discrepancy betwen the better and the weaker coder.
Just as if they fear they have to code all week and all month from now on for ever with a weaker code "who drains them".
But that is very unlikely. You will have a weaker guy for a week as partner. And then you get another partner. And he weaker one is moving to someone else. After 1/2 a year he will have learned or you kick him anyway. And if the guy is b
Just get off the keyboard retard! (Score:5, Funny)
"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."
Re:Just get off the keyboard retard! (Score:2)
Re:Just get off the keyboard retard! (Score:3, Interesting)
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.
Re:Just get off the keyboard retard! (Score:2, Offtopic)
"Ok, just turn left before the round about."
"What? Turn left at the round about?"
"No, turn left before the round about."
"So I have to drive up to the round about?"
"Yeah, but turn left before it."
"Ok". We then proceed to turn left at the round about.
"No, you needed to turn left back there."
"You said turn left at the round about."
"I said turn left before the round about."
"No you didn't."
"I did!"
"I asked you if we needed to drive up to the round abo
Re:Just get off the keyboard retard! (Score:2)
The funny thing about the comment above was that someone actually thought it was funny. Heh. Wait until you get married
Re:Just get off the keyboard retard! (Score:2)
Re:Just get off the keyboard retard! (Score:2)
Re:Just get off the keyboard retard! (Score:1)
guidelines, and prospectus.
Frank Fingerman
It is most efficient to communicate by means of the
internet. I have conducted studies to confirm this.
Please convey your remarks via email.
Frank Fingerman
How are you coming along on the prospectus?
Frank Fingerman
I gave up (Score:5, Interesting)
If I ever get forced into another pair programming situation, I'll use my spare time to apply for other jobs.
Re:I gave up (Score:1, Funny)
Re:I gave up (Score:5, Informative)
Your experience was done completely wrong. Part of pairing a senior developer with a junior is to teach the junior developer things they didn't learn in school However, the junior developer constantly questioning the senior developer's judgement is equally as bad as the senior developer ignoring the junior developer. Neither developer is there for the other's amusement, and it's good to keep in mind that there should be no criticism; sometimes neither developer's idea is very good.
These are the problems as I see them:
Re:I gave up (Score:1, Insightful)
Re:I gave up (Score:2)
Agreed. When people are learning to pair, I tell them they should make sure the keyboard changes hands every 10 minutes or so.
Another good way to force collaboration is to have person A write a test and person B make it pass. Then B writes the test and A makes it pass. It's a fun game.
Re:I gave up (Score:2)
That didn't come out right. Before I get flamed, let me explain myself by saying that I'm not claiming that you personally are an asshole. I was attempting (badly) to show how you could be perceived by the senior developer, and that sometimes it requires practice to learn to not say something at the right moment.
Anyway, I hope I preempted any confusion, hurt feelings, etc.
Re:I gave up (Score:2)
That was one of my ignored suggestions.
Possibly. Actually, I don't think he was even hearing me.
Likewise, you need to learn when to shut up and not be such and asshole.
I did shut up. I thought that was made clear in my OP.
Re:I gave up (Score:4, Interesting)
You were on the right track! Your pair was improperly trained.
Possibly. Actually, I don't think he was even hearing me.
That's completely unprofessional. All I can say is that the developers that I have worked with would never do anything like this. In fact, in the last place I worked where pair programming was not policy, we sometimes ended up initiating a pair programming session on our own when we had a particularly hard problem to solve. This happened regardless of the seniority of the engineer.
I did shut up. I thought that was made clear in my OP.
Ack, that's not really what I mean; see this earlier explanation [slashdot.org]. In your particular case, being quiet wouldn't have helped you. Unfortunately, your partner is an antipattern, and probably no amount of diplomacy would have helped.
Let me try to illustrate this better with an example: Back when I was a junior developer, I was put on a project I had no experience with (I didn't even know how to program in the language they used), and told to add a particular feature in a very complicated section of the code. Of course, I had questions, and it so happened that the main developer (and the person I was told to work with) was located right across the hall from me. So, I would pop in from time to time to ask questions about what certain undocumented variables meant, or which part of the state machine I could safely change. I thought everything was fine until my annual review where I got lambasted for, "asking too many questions". Of course, my first thought was, "That greasy bastard!"
However, you have to look at it from his point of view. The code that I was working on was not critical (it was going to be heavily reviewed and documented before it was passed off on). The code he was working on was critical, more complicated, and on a tighter deadline. He was the more critical resource, and even though he was told to help me, his time was more important. What I should have done was prepare a list of all the questions and sample code that I had, and scheduled an early meeting with him. In other words, working with him instead of pissing him off.
This is a skill that has to be learned, and unfortuately the way it's usually learned is that the junior developer gets pinged. Over the years, I have found myself in the same situation as the senior developer in my story, but I have, at least, been better about telling junior developers what I expect and scheduling time with them.
Re:I gave up (Score:2)
I would hope that any pr
Re:I gave up (Score:2)
Re:I gave up (Score:2)
Wow. Sometimes it's better to just slow down and not make stupid mistakes like that to begin with. When I start to do that I go home... and post on slashdot.
Re:I gave up (Score:2)
We have bought the book "Pair Programming Illuminated", ISBN 0-201-74576-3, which talks about the practical things related to pair programming.
I have not read it yet, but I noticed that one of the chapters has the following title: My Partner Is a Total Loser and Other Excess Ego Problems :)
Small experiences (Score:1, Funny)
I fell in love with her.
you were no rose either (Score:2, Funny)
Missing the point? (Score:4, Insightful)
That's actually the whole point of pair programming. It's supposed to slow you down so you make fewer mistakes.
Re:Missing the point? (Score:2)
Um, couldn't I just type with one hand tied behind my back?
People either know what they are doing, or they don't. A system which siameses two people to do the job of one sounds like the latest "Managment Consultant" speak, as well as a way to sidestep the issue that some of the people can't do the job.
Teamwork is for Horses. More can be accomplished by having fewer people exerting individual effo
Re:Missing the point? (Score:2)
The problem lies in the fact that you can't just automatically put two people together and assume that that is the best case
4 years of xp and all i got was this lousy t-shirt (Score:5, Interesting)
- 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 get a lot done (Score:3, Insightful)
Re:I get a lot done (Score:2)
Re:I get a lot done (Score:2)
Re:I get a lot done (Score:1)
Well, yeah, that's part of it :-)
Last week I travelled to an office where I had no internet connection. One of my most productive weeks in a long time.
Re:I get a lot done (Score:1)
Re:I get a lot done (Score:2)
I am guessing that you own a Mac! Java draws things slightlty differently on a Mac. Drawing a circle is always 1 pixel larger to the right and also down on a Mac. Now that I know this I need to take it into account. I also need someone with a Mac to test it.
I will put a fix up and reply to this your comment.
Nothing different (Score:5, Insightful)
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.
Re:Nothing different (Score:5, Interesting)
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.
Re:Nothing different (Score:2)
Keep the people who are paying the bills out of it? You're joking?
Keep management out of it? You're joking? They're the ones who tell the bill payers how things are going.
A teams actions must be transparent and accountable for their actions, right up the chain of leadership.
D
Re:Nothing different (Score:2)
Management judges a team on results, not on how the results were achieved.
If a team fails to perform, it's back to the old way of doing things.
Management's rights regarding teams is the ultimate solution, to destroy the teams.
A teams actions must be transparent and accountable for their actions, right up the chain of leadership.
That isn't a team. It's a chain of command. Weakest link and all that.
Re:Nothing different (Score:2)
Really? The ends justtify the means, and all that? I have never seen a management team who judge only on results. They manage, not just judge.
Really? You've never seen a situation where one team reports to another team? e.g. a Build team reports to a managem
Re:Nothing different (Score:2)
Good one, but if the ends do not justify the means, then what does justify the means? If the means are not employed to effect some end, then why are the means employed? What is true is that ordinary ends do not justify extraordinary means.
"management team"? Like a "sanitary engineer" is almost certainly not an engineer, a "management team" is almost certainly not a team. The term "team" is used in the hopes of maybe getting a wee bit of cooperation out of the memb
Quasi_pair (Score:4, Insightful)
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.
It doesn't have to be all day! (Score:1)
The key is communication (Score:3, Interesting)
Actually I'm doing this right now... (Score:2, Informative)
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- leve
Extreme Programming (Score:2)
Re:Extreme Programming (Score:2)
Eek, you had more than one programmer working on the same system, and NO REVISION CONTROL???
Please tell me you at least had backups?
Re:Extreme Programming (Score:2)
Thick Skin (Score:2)
that should be a lot of fun (Score:3, Funny)
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.
Re:that should be a lot of fun (Score:3, Insightful)
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-clicket
Pair Programming with two keyboards (Score:1)
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.
Re:Pair Programming with two keyboards (Score:1)
All praise emacs!
Re:Pair Programming with two keyboards (Score:2, Informative)
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.
This is a joke, right? (Score:2)
"...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 i
Re:This is a joke, right? (Score:2)
Design->Code->Test. Do it once, and do it *right*. Fred Brooks has much to say about the pitfalls of this strategy. Waterfall is often associated with over-design or design paralysis and failed, over-budget projects.
Nowadays, many folk prefer some iterative or incremental approach, where skiing off piste (unforseen additions/removals/refactorin
I peer program every day... (Score:2, Interesting)
One word (Score:1)
Working in pairs requires two focuses (Score:3, Interesting)
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!
Equal opportunities (Score:1)
Alternatives (Score:2)
sounds too much like being married! (Score:2)
I hate it I hate it I hate it I hate it. (Score:2, Insightful)
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 y
Different skills (Score:2)
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
My Pair Programming Experiences (Score:2)
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, sin