More on Pairing

Kicking Off a Task or Story


 


Some people can just sit down at a keyboard and start generating unit tests.  I can’t do this myself.  Personally, I’m much more effective if I spend just a little bit of time sketching out an approach in crude UML or merely writing out a list of the changes to make in the code (new method here, new class there, etc.).  One very effective tactic I like is to do in a pairing session is to start at a whiteboard and task out the work together and make a list of the coding work.  It’s a simple and quick way to get a shared understanding of the work.  You’ll undoubtedly throw away some of the list and go a different way, but it’s the act of making the list together that’s important, not the list itself.


 


The Backseater Must Be Engaged


 


The person not driving has to remain actively engaged in the coding.  When you’re not the driver, you’re Goose from Top Gun watching the driver’s “Six”.  The backseater should be thinking ahead and looking for potential problems with the current approach.  According to the old folks like Steve McConnell and Robert Glass, code inspections (reviews) are one of the most valuable tools for removing defects from the code.  The backseater should be performing a code inspection in real-time. 


 


I think it’s okay to have the backseater doing some sort of research for the next piece of work sometimes, but otherwise the backseater is focused on the coding at hand.


 


When you’re the backseater, don’t be an ass.  Slow down on the whole “you forgot a semicolon” commentary at least until the driver has moved on to the next line of code.  Nitpicking is a great way to be a bad backseater.


 


Switch roles often to keep both people involved in the story.  No decent developer likes to just watch someone else coding.  There was a somewhat sad incident in a stand up meeting last year when my pair from the day before listed his activity from the day before as “watching Jeremy code.”  That’s being a bad pair on both our parts.


 


Smooth out the Worst Tendencies of any Sole Developer


 


By having input from two coders into any coding activity, you have a sanity check that can help rein in the worst tendencies of any one developer.  As for myself, I’m filled to the brim with design pattern theory and it leads to some temptation to go off and be an Architect Astronaut.  Coding in a pair with somebody who does not share this affliction helps to keep me grounded and write code that makes sense to the rest of the team. 


 


On the other hand, if your partner suggests implementing a task in a 1400 line stored procedure you can remind them that T-SQL is not a very good solution because it’s hard to test, debug, and read in this context than C#/VB.NET/Java (and Jeremy has implicitly threatened bodily harm to anyone who puts business logic in a stored procedure ever again).

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Pair Programming. Bookmark the permalink. Follow any comments here with the RSS feed for this post.