Sam posts
a link to this
article which defends the use of pair programming, where two programmers collaborate
in front of a single computer to write software. I’ve never tried this
formally in a professional setting, but I do have some experience with the phenomenon:
as an instructor I routinely write small programs in front of an audience. Anyone
that’s done this knows that the viewers don’t have to know the technology
you’re using very well to catch mistakes that you make.
In addition to this, I’m involved in a project right now where
the team is geographically distributed. I spend a lot of time on the phone, and even
with that relatively poor communication mechanism, we’ve had good luck working
through code together, both authoring and debugging. We got together in Minnesota
a few weeks ago, and had even better luck when we did the same thing with the code
up on a projection screen.
Of course, I think one of the contributors to the productivity increase
is that it makes you focus more. If I could write code for two hours straight on my
own without checking email or the web – something I wouldn’t do when I’m
using someone else’s time, too – I suspect I’d get more done. The
paper Sam references has some quantitative results, but I’d be curious to see
something more rigorous. And to try this approach myself some time, on some real project,
end-to-end.
I think your point about pair programming causing you to "skip the distractions" is spot on. (For instance, I'm posting this comment right now, after reading your blog entry, instead of working.) I've certainly experienced this increased focus myself - for several months during a project (and it was quite effective.) One (fairly small) downside is that, on your own, you might tend to pursue a solution to a problem that is not as quick in the short term, but will improve your skills - you interleave learning as a natural part of the process. As part of a pair, I've find the focus tends to be on raw production.
ReplyDeleteAgreed on the downside - my transition from mostly being an instructor to mostly being a consultant has left me with a lot less latitude on learning stuff. It's been great for me - writing real code is a skill I need to hone, too - but at some point I'm going to find myself falling behind on theory, and I'll want to transition back to a lifestyle that emphasizes that.
ReplyDeleteFor working stiffs, I think the answer is that companies need to be more generous in giving people time to study abstract principles and technologies for technology's sake.
Well, I also agree on the "more work, less investigation" mode this style puts you in, but it has another benefit; sharing of knowledge. I have been using pair programming professionally for several years (long before I knew the practice had a name). In my case, 95% of the time it was me teaching a less experienced programmer about a technology, pattern, etc. Although it does suck time away from the senior developer, it's time well spent. Over the long run, there's a payoff: after a learning period, the other programmer spends more time being productive when you aren't pair programming (they're now familiar with the coding style, development tools, prefered patterns, etc), and it sometimes will cause a senior programmer to rethink how things are done. ("Why do you do that?" "Well, that's the way I've always done it, but now that you mention it... Let's see if we can do it a simpler way now.") In fact, I've found that I prefer working as a pair - sometimes teaching is the best way to keep learning.
ReplyDelete