I Love Pair-Programming
nomachetejuggling.com
nomachetejuggling.com
I can't "navigate" someone moderately competent because it takes me forever to stuff a pile of someone else's code into my head. I have to keep scrolling here and looking there, which I can't do without a separate keyboard and monitor. I want to navigate from an extra computer so I can flip through the code, look up docs, and so on. But, by gum, that's not "pair programming." Hence, the only thing I'm good for as a navigator is catching syntax and spelling errors, which is something an appropriate editor or IDE can do.
And I can't accomplish much while I'm "driving" because either I have to spend all my time explaining everything to the noob, or I'm not allowed time to think. If I stare into space or scroll around a bit, the navigator thinks I'm stuck and feels compelled to chatter away with advice or questions or something. And unlike the author's "Progammer Man," the code I produce solo in the Zone is better than the code I produce in a pair out of the Zone. The best "navigator" is someone who watches awhile then gives up and "pairs" with someone else! No, I take that back. Apoorva is a decent navigator. He mostly just sits there and makes a few pleasant quips, occasionally raising an insightful question. I guess I'm very, very finicky about navigators.
The places I've seen it work seamlessly has been where it averages out the work to a consistent level, whether all intermediate coders that no longer make rookie mistakes or all advanced ones that no longer slow down for newbie speed bumps. I've even seen pairs attack projects in programming languages they've never worked with before. I was brought in to Pivotal for an afternoon or two to give Flex/actionscripting advice to the programmers working on a friend's prototype site and they didn't need my help at all, I was happy to see that they knocked it out just fine.
On a side note, I just tried out pair designing this week (instead of programming) and it was a really interesting experience. You could see that we each had different focus (me = interaction designer, partner = visual designer) and that helped compliment our work rather than act as a source of friction. And not to get into a toolkit debate but we also shared similar philosophies about hating Photoshop and long design cycles, loving Fireworks and quick clickable prototypes, etc.
OMG, I just got an insight. I'm an effective Rover or mentoring "navigator" as long as no one expects me to read. I need to not look at the monitor, not try to read the code or docs or whatever. As long as all I do in the presence of talking people is do my own listening and talking, my brain doesn't turn to complete mush. I noticed long ago that I have almost zero reading comprehension when I read English (native language) aloud. I also remember covering my ears while reading silently when someone else reads or the teacher is talking. Etc. So the big insight is, my reading incomprehension in the presence of speech extends to reading computer code! I have a reading problem (or attention problem, or whatever it boils down to) which frustrates my ability to pair.
That explains why I have such a hard time understanding even a single line of code in most pairing sessions. That explains why, when I'm the "extra set of eyes," all I'm good for is syntax and spelling check (which really should be done by software, not me). Writing code happens to be a lot more of reading what's on the monitor than head's down typing. So, the question is, how am I able to drive okay with insightful and not-so-obtrusive Apoorva? Well, it often doesn't work. But I notice it does work when there's only one other pair in the room and I haul Apoorva and me to the far end. That cuts the other voices down significantly.
Thank you, thank you for prompting me to think this through.
I suspect companies that institute pair programming because employees are less likely to goof off when they have another set of eyes on them. I have a hard time believing that it actually makes motivated people more productive.
I think those of us who initiated pairing on our team were the most motivated programmers, and those who wound up pairing regularly were likewise the most enthusiastic about the project and about professional development too. I'll admit that it's hard to separate causes and effects here, but I do believe that on our project, pairing was more of an effect of our desire to improve our productivity.
I was tempted to say that our pace was somewhat reduced (not to 50%), and our code was greatly improved, because that was our impression. We did not adjust old estimates to account in any way for pairing, and we saw a trend toward improvement in |actual - estimated| costs.
Then again, every feature/bug and programmer is different. We didn't have many old estimates for unfinished work. We didn't consciously account for pairing in new estimates, but we didn't have any sort of experimental rigor. The non-pairing programmers definitely wrote worse code, but they were the weaker programmers in the first place. Maybe our improved estimation accuracy was because our product was maturing.
There are some reviewed papers covering experiments on pairing. Laurie Williams [http://collaboration.csc.ncsu.edu/laurie/] is an author of many of them. Here's one not by her: http://portal.acm.org/citation.cfm?doid=1145293.
If you know your IDE well enough, you probably won't need a powerful text editor to be effective (unless you are using a language that is not toolable, which is bad). And yes, your powerful text editor is feature poor.
You like what you like. He likes what he likes. You are in a mutually recursive Bulb paradox.
This, of course, assumes your IDE doesn't suck. Most do. If your IDE isn't powered by JetBrains, chances are it actually does suck.
Apparently some languages have so much verbose boilerplate that the only way to be productive in such a language is to pick the boilerplate out of a menu when you need it. Or so the IDE folks say. (Other problems include insane organizational schemes that require the computer to move code between specifically-named files in order for your app to run.)
Anyway, the IDE thing is a classic example of a "local maximum". The language made a bunch of bad decisions, and the only to get productive again was to invent an incredibly complex tool to abstract away some insanity. Sure, it's kind of good. But if you threw both away and started over, you'd get a better maximum with less complexity. The word "blub" comes to mind.
So in the end, you are exactly right -- if you are using a reasonable programming language. If you are using Java, you need all the help you can get. (And yes, I mean that in two ways.)
I've worked with Java programmers in the past who used IDEs. They produced more lines of code, with far less functionality. Going through their code was horrible. I'm guessing because their IDE conveniently hid most of the cruft from them. As a result they knew far less about the code base than those not using an IDE. etc etc
If your bottleneck is how fast you can type the verbosity, then you're doing something seriously wrong.
Java is still unpleasant either way. What takes ten files in Java would be ten lines in any other (real) language. Also, the standard library is horribly, horribly designed. If you read the implementation, you'll see it's clear that nobody writing it has any idea what OOP is, which makes me very very sad. Anyway, this idiotic design makes writing Java even more difficult, IDE or not :)
Hopefully I will never have to write Java again.
>> "What takes ten files in Java would be ten lines in any other (real) language."
Come on now, it's not quite that bad. Also, I don't really buy into the whole 'all verbose languages are bad' thing.
For me, the three biggest IDE feature areas I love are navigation, refactoring, and code analysis.
Navigation: Jump to type or method (super and subclasses or by name), find usages (filtering by callers or assignments), and especially "go to definition". All things that help me spend more time reading code and less time reading code to find the code I want to read.
Refactoring: the power to rename an identifier across my entire project in half of a second is sorely missed when I work on Python stuff. Never underestimate the productivity gains of one keystroke method extraction or safely safely rearranging parameters. Make those changes you are afraid to make with confidence and without manually fixing in a long list of text search results.
Code analysis: finds compile and runtime errors before ever even compiling. Little colored squiggles under my code have saved me so much time, it is not even funny. You'd be surprised at the level of support these things can offer. Resharper, for example, lets me know when I use method overloads that don't pass an optional culture parameter. My code never has a localization bug with list separators such as commas and periods because Resharper warns me when I am not specific about what the correct behavior is.
It's one of those things where you can see how much it matters that you can rely on each other to catch stuff before it becomes a dead end, when you're programming on your own it's very easy to waste some time every now and then, and to have to backtrack later.
If you can't actually program pair wise I'd certainly recommend that you go over your design with somebody competent before you commit to code, you'll be surprised how much time that will save in the long run.
Basically, when you pair, you get one better programmer instead of two lesser programmers. Think about the old 10x/100x developer question (http://c2.com/cgi/wiki?DevelopersWithHighProductivityTenxHun...). In reality, it isn't that simple. A 10x programmer won't write simple code (Hello World) 10x faster. On the other side, a mediocre programmer may be unable to do some of the things that a better programmer can do, no matter how much time you give them. So it's silly to compare productivity along a linear scale like this.
Pairing is similar. It's meaningless to say that a pair 2x as productive as 2 developers, or 3x, or 1.5x, because it depends on the task. They might work far faster at a complex problem, but no faster one programmer at an easy one.
That's why my preference is to pair on anything that is moderately challenging (or harder), and to work separately on the easy stuff.
(I could rant on and on about this, but I won't. Basically, if you haven't programmed seriously in a dynamic language, a functional language, Smalltalk with Squeak, Lisp with Emacs/SLIME, and Java or C# with an IDE, any commentary you have on programming languages and tools is worthless. You haven't experienced enough yet.)
We used it mostly for collaborative design. It was helpful for bringing a new team member up to speed on our code base. We also used it as an interview technique, and that seemed very successful although that one hiring decision is weak evidence.
It usually begins with about 5 minutes of joking around and wasting time, but it takes only a minute or two to achieve flow. Individual programming can take 30 minutes or more to achieve flow. Once in flow, it is much harder to come out of it because you aren't tempted to browse to Hacker News. Also, no one will stick their head in your office and bother you because it looks like you are in a meeting.
Partners are incredibly helpful spotting errors and act as an extra cache for all the little details you need to keep track of. Usually the person not typing has a lot more capacity for those details because they don't need to spend the energy operating their editor and manipulating code (no matter how good you get at it, it still requires some brain power: a limited resource).
Also, when all is said and done, you now have TWO experts on a topic. Redundancy is a good thing.
Anyway, now that I don't have coworkers like this, I find it's easier to go off on my own. I also don't find it particularly useful to write a failing test and make it pass, I tend to alternate between big batches of code, a batch of passing tests, some todo tests, and then making that all work again.
YMMV, but you have to keep in mind that things like XP, Scrum, Agile, TDD, etc. are designed to make big groups do things in a consistent amount of time, so that the code works reasonably well and it is delivered in a predictable amount of time.
It is not necessarily a good way to do things if you are a good programmer. (Strict rules are for robots, not artists.)
"The amount of time you spend trying to figure out “what’s going on here” or “why isn’t this working the way I expect” is severely reduced. I’m talking hours of debugging that literally turn into seconds."
I'd attribute this very much to the extra "cache" of the second brain that isn't having to manage typing and editing as snprbob86 above mentions.
Have you ever watched someone searching for some piece of info on Google or Wikipedia, or looking for a phone number on a website? The person not wielding the mouse/keyboard can often parse and comprehend the info on the screen more quickly.
I also agree strongly with this: "the QUALITY of the code that IS produced is so, so, so much higher"
I think the post helps to dispel some myths of pairing as well, and it works best if pairing to reach the goal of completing specific tasks.
This tends to happen organically.
When it comes down to the heads-down time necessary to plow through some changes, a second pair of eyes hovering over my shoulder becomes a distraction and a productivity killer.
There exist shops where the mantra is "Pair Programming = Good" and you are encouraged (and socially pressured) to do most or all of your coding at a single screen with someone else. I tend to do not so well in these.