Be a good pair
As a response to Chris’ call for help, I thought I’d share the best pairing practices I’ve learned over the past coupla years. For the record, I wouldn’t label myself as an “experienced” developer just yet. It’s all about small steps and picking up tidbits as you go. And I wouldn’t call this an absolute answer to his question, just some suggestions to address the problem.
- Respect your pair. I find this one of the hardest things to do as a consultant as you’re working with clients whom you do not know and understand. But respect has to be given before it is expected.
- Ask questions and allow for questions to be asked. If your pair is one of those who would rather be sitting alone and banging out code, slow him/her down and ask questions about what their thought process is. And be persistent. To fend you off, they’d be forced to take their hands away from the keyboard and talk to you, then that’ll be your chance to take control of the keyboard
just kidding… - Take turns. One good pattern to follow is the ping pong pattern which is a way to figure out when to code and when to watch.
- Pay attention and think ahead when your pair is coding. This is the most important lesson I’ve learned so far about pairing. Watching while someone else is coding does not mean that you stay idle. Your job is to think about what the next step should be when your pair is done with the current task. Not coding also gives you the ability to take a bird’s eye view of the code and see if you can spot any issues with it.
Do you have any more to add to the list?
Hey Dahlia,
i like your points. these are things which i would add to your list:
- let your pair do what they want
the most senior consultants/developers dont always get what they want. If you go into pairing expecting this, you wont enjoy the experience.
This is valid even if the issue is something that you think is really important. For example if you love tests, but your pair doesnt want to write them. Why not try not writing tests? They will soon want to write tests when everything starts breaking and they will respect you more for allowing them to learn the mistake themselves.
Ironically, i think that youre much more likely to get what you want when you take this approach.
- if you’ve stated your case and your pair doesnt like it, dont argue.
its just not worth it. it leads to frustration, confrontation, people get defensive, you dont get what you want and you have a horrible day. this doesnt mean you have to agree – just dont argue.
- communication is key
if something is in your head, then its not in your pairs head. you both have to be moving in the same direction.
- have fun
take a chill pill. who cares what they renamed the method to – its much more important to enjoy the experience and have fun with your mate.
Cameron Swords
December 10, 2008 at 1:06 pm
thanks cammy! good points. i want to pair with you now
Dahlia Bock
December 10, 2008 at 9:08 pm
[...] of my colleagues have replied citing some of their best practices and I have previously posted about what I think [...]
Pair Programming: What works for me at Mark Needham
December 17, 2008 at 12:13 pm
[...] you do when you’re not busy on the keyboard? Possibly related posts: (automatically generated)Be a good pairAn interesting blog post about Mockito (and other mocking frameworks)Check out this KeyboardDamn [...]
Pairing: What to do when you’re navigating « Dahlia Bock
May 23, 2009 at 6:51 am