Pair programming etiquette
Everyone’s heard of pair programming, right? It’s one of the best-known practices of Extreme Programming, and basically it involves having two people work on every programming task, providing feedback and encouraging higher quality code.
Some people think — not to mince words here — that it’s a load of crap. They’re entitled to their opinion, but I have to say, I think many of them would change their minds if they had a good pair programming experience.
But what makes a good pair programming experience? Well, as far as I’m concerned, it’s mostly to do with how you interact with your programming partner. And, funnily enough, a lot of that comes down to etiquette. So I’m going to try and give you a handful of etiquette tips to help you pair program more effectively.
If you’re at the keyboard, do…
- Share. You learnt this in kindergarten, right? Don’t hog the keyboard and prevent your pair from having a turn.
- Communicate. If you’re at the keyboard, you need to keep a running monologue of what you’re doing. “OK, I guess we need a new subroutine for that… I’ll just write some tests first… hang on a sec while I check the docs.” Not talking will leave your partner bemused and disoriented.
- Accept criticism. Whether the criticism is direct or indirect, your partner’s comments will probably help you program more effectively, so don’t discard them without consideration.
… and don’t …
- Sit and stare. If you’re stuck, hand the keyboard over. If you’re pondering deep and complex design issues, do it out loud or grab a whiteboard.
- Email or IM. Unless it’s related to the work you’re doing, leave them alone for now. Shut the apps or turn off notifications if you can.
- Change settings. If you’re at the other programmer’s computer, don’t change any settings without asking first. If their setup bugs you too much, log out and login again as yourself.
If you’re the co-pilot, do…
- Offer suggestions. That’s what it’s all about. Whether you have a commandline shortcut or a design pattern that could help the other programmer, don’t be afraid to say so.
- Offer to take a turn. The standard phrasing is, “do you want me to drive?” It’s best to do this if your partner seems stuck, or if you find yourself giving suggestions in so much detail that it would be easier to do it yourself: “No, down three lines, just after the regexp… add a quote mark… hang on, how about I drive?”
- Call for breaks. If you’re sitting back from the keyboard, you’re in the best position to notice when you’re both worn out. A break can be for lunch, some time diagramming the system on the whiteboard, or just half an hour at your own desks to check your mail, read your blog feeds, and let your brain relax.
… and don’t …
- Zone out. Now’s not the time to read a book, send text messages, or stare blankly into the middle distance. Your partner deserves — and requires — your attention.
- Invade privacy. If you’re at the other programmer’s computer it’s likely that you’ll notice things like browser tabs, email subject lines, and the like. Affect indifference, and never mention that you noticed anything of a personal nature.
- Be ambivalent. When you say things like, “yeah, whatever, I don’t care,” you’re undermining the energy that should exist between a coding pair. You can like things or hate them, but save your ambivalence for things where there’s really no way to pick between the two, and phrase it as: “I think either option is equally good.”
Got any others?
4 comments4 Comments so far
Related to email or IM is answering the phone, but with some exceptions.
If it is a desk phone that belongs to someone whose role involves monitoring the production systems then they should answer it, but if not for a production issue it should be a very short call. Similar for an “on call” phone as the only time that should ring is for a production issue.
Apart from this, a desk phone should be diverted to voicemail. The caller will either leave a message, call back later or call someone else.
Personal mobile phones however… NEVER! You could probably do an entire article about mobile phones in the workplace.
Stephen: Good to see you here! Your points about phones are very good. I kind of forgot them since my workplace hardly ever uses phones at all. My phone was unplugged for weeks, once, and I didn’t notice.
Until you and your pair get that rhythm where you say “I think it…” and the other programmer says “oh yeah… duh!”, as the non-typing half of the pair you need to be both succinct and fairly specific about your input. “Line 12, check for malloc returning NULL”, that kind of thing. Use technical aids of course: turn line numbers on! Turn syntax highlighting on!
When feeding people UNIX commands they’re clearly really unfamiliar with, be very precise in your spelling out “w-g-e-t space hyphen captial p” etc. This is probably a personal quirk, I go nuts when people don’t specify spaces and uppercase well the first time.
As the coding half, turn all your best practices for easy to follow code back on in your head, if for whatever reason you’ve never found them necessary to maintain your private code (and your colleagues are yet to kick your butt for it). Indentation according to the house standard, or language standard if there’s no house standard, or something sensible in the event of no standards. Functions that fit in a screen so that your pair can absorb them over your shoulder. A few less lines that have more than five side effects. That kind of thing.
Do :
Wash
Don’t:
Eat crunchy things with mouth open