views:

125

answers:

5

Anyone got any experience of teams doing pair programming where there is a mixed IDE environment? I'm a long time IntelliJ user, others use Eclipse, which you may have heard of.

In my mind pair programming involves a lot of passing the keyboard between the programmers. But every time I get the keyboard I grind to a halt as I don't know to do anything anymore. (It's like suddenly I'm an idiot!)

Now I could, probably should, learn my way round Eclipse. (Not starting a holy war here about relative merits.) But I wonder if anyone else has got an opinion?

+1  A: 

In pair programming, the pair should standardize on an IDE.

My suggestion would be either to pair with another IntelliJ user or, if the rest of the group is on Eclipse, start learning Eclipse.

You're going to lose too much time switching between IDEs to gain the efficiencies of pair programming.

Justin Niessner
+2  A: 

I don't see the need for passing the keyboard around. In my view, you work on part while the other half of your pair looks over your shoulder. Sometimes I imagine you would have to take the wheel, but generally not every 10 minutes. If he types for 4 hours, then you switch places, just switch IDEs at that time.

I agree you should learn the tools that are used, and if there is an actual published or documented standard you should follow it, but if you are allowed to use any IDE you want, then I don't see an issue. But if it inhibits your ability to deliver, then maybe you pair up with someone using the same IDE as you.

MJB
I've never worked with this technique, so I'm curious as to what is supposed to be gained by having one developer look over the other's shoulder for 4 hours?
FrustratedWithFormsDesigner
@FrustratedWithFormsDesigner: I am not trying to sell pair programming, so I might not be the best person to explain, but I'll give it a go: If I am coding on my own, sometimes I go off on a tangent trying to solve a problem that has a) already been solved in a library or b) secondary to the actual issue or c) not part of the requirement or d) interesting, but not important. Working together, with 1 person looking over your shoulder, allows the coder to stay on track and not lose sight of what is important. It also makes 2 people who know this section of code (great when bugs appear).
MJB
"If he types for 4 hours, then you switch places" to me is not really pair programming anymore... the dynamics are completely removed from the process this way. Not to mention, a pair programming session of 4 hours is about the max a pair can take per day (unless the other guy is taking a nap while you are typing ;-)
Péter Török
@Peter: I agree 4 hours is too much. But do you switch drivers every 10-20 minutes?
MJB
I don't think that this would actually be pairing, more observing.
Paul McKenzie
@MJB: Maybe with a defined methodology it's different, but I've had developers stand over my shoulder and make constant "suggestions" (yes, we were working on the same project/codebase) to the point where I wanted to throttle them. Instead, I usually got rid of them by taking a long break until they got bored and walked away.
FrustratedWithFormsDesigner
@MJB, I admit I haven't had that much practical experience with pair programming (unfortunately - I would have really liked to). So my thoughts are more theoretical and feeling-based on this. However, I can well imagine the control being switched every 10-20 minutes on average. Beck and Jeffries published the notes of several of their pair programming sessions where they do it even more often. Or one user has the keyboard, another the mouse.
Péter Török
@Frustrated: I generally have wanted to throttle (or kill, if we don't have to be PC), the developers looking over my shoulder. But in my experience, about 1 minute out of every 20 they have been helpful. Kind of a high overhead rate, if not done right.
MJB
@Péter Török: One has the keyboard and the other has the mouse? Wow. They must get along really *really* **really** well. They sound closer than most married couples I know.
FrustratedWithFormsDesigner
I have found that using two mice works well, so that the non-typing dev can point and click to suggest changes. I would like to try it with two keyboards, but haven't had a chance so far.
Paul McKenzie
A: 

You could have both IDEs loaded on the pairing machine and switch between them as needed, but I'd recommend standardizing IDEs with your pairing partner. You might want to bring this question up in your next retrospective and see what the team consensus is.

James O'Sullivan
+2  A: 

Standardize your environment! As much as you need a common source style, I would argue you also need a common way of working, including having a common IDE. All kinds of settings, knowledge, plugins, etc. is much easier to share, including your example about pair programming.

Marc van Kempen
+1 for mentioning common coding style.
Péter Török
code style can be imposed/implemented in both IDEs and in continuous integration build.
Paul McKenzie
+2  A: 

I have not done this in a multi-IDE environment. But pairing is, to my mind, far and away the best way to learn IDE features. So you should come up to speed quickly on Eclipse, and your colleagues, likewise, should get a handle on IntelliJ in short order. Both of you will become better versed in both environments - and that's a good position from which to settle on a team IDE, should you choose to do so.

By comparison with other means of learning, pairing teaches you the features that are useful to you (or your pair, who probably has a similar set of needs). You learn almost by osmosis; as your pair uses a feature you may find yourself asking, "how did you do that?" or "what did you just do?" This is teaching you the features you need, exactly when you need them.

In your situation, there may be additional value: you may find yourself wanting a feature that your IDE offers; your pair may never have encountered it (but it might be in Eclipse, too). So you spend a minute tracking down that feature, and now both of you have learned new (and useful) functionality of the IDE.

Carl Manaster