Okay, it was noted today by Wendy that although attending the BoF on Pair Programming, no notes were posted here.  I can’t speak for everyone, but my thought is that the BoF session was one of the most informative.  I’ve never participated in a BoF session before (and only for about 10 minutes of this one), but I was found the format very engaging.  I’m not one who gets up and asks many questions in a presentation (okay, never), but I felt like I needed to jump in and participate in the discussion.  I’m definitely going to make a point of trying to implement some of these sessions at either our user group meetings or the code camp.

A couple of the things that I picked up from the discussions were the build bunny, red cards and distributed pair programming. 

I’ve always wanted to get a device to plug into our build server status and the ladies at Oxygen have a build bunny that identifies the current and trending status of the build.  Wendy also mentioned that the bunny has a web service that she’s been known to tap into when she is working remotely and in need of her co-workers attention.  I’m sure my guys at work would find this out and abuse it to no end.

Red Cards for pair programming was an interesting concept that I’d never heard of before.  The idea is that both people in the pair have a red card and they can use it when they feel that things are personally or professionally inappropriate or uncomfortable.  All other people on the team must respect the use of the red card and work to make sure the situation is resolved.

The ideas that were raised about distributed pair programming were very informative.  I’m sure if I’ll get into this situation, but knowing things like the fact that there are only so many days that you can be out of the office before the technique demands that you physically co-locate.

All good stuff to know as we’re looking at pairing with our new team members at work.  Unfortunately management only sees this as a way to train newbies instead of a commitment to quality.