Thursday, March 30, 2006

Pair programming at work (not exactly)

Today I had a new experience, working side by side with someone on coding. It was a rather instructive experience and not truly pair programming, though there were two monitors, two keyboards, two mice, and two of us. :)

Mostly I was given the rundown on how this particular code was setup (C#) and how it was used as a test against the actual class.

After that, we ran several test executions to demonstrate how the test ran versus what it was designed to test. Changing things here and there. And, believe it or not, I actually contributed a very tiny bit to improving the test.

Overall it was a great learning experience and time well spent. Sadly, there just isn't enough of that at our jobs these days.


1 comment:

Mike J said...

I still want to see this topic addressed (perhaps in a slightly more thorough form) on the work blog. That aside, I would say it was pair programming. There are lots of kinds of pairing sessions: learning, purely collaborative design and implementation, etc.

The session we had last week was primarily to introduce you to interaction tests. We shifted to a state-based test as a point of contrast when you noticed a problem in the test (thanks for finding that!). Even though I drove the whole session it still counts as pair programming.

The only thing we should change next time is the duration. Two hours is probably a minimum to get in the pairing groove.