Last month in Chicago, the day before Software Craftsmanship North America, 8th Light held a “Code Retreat”. My vague impression of Code Retreat (which I'd heard of before, probably at CodeMash) was that it would prescribe a relatively straightforward programming problem, so that we could focus instead on what's going on in our heads when we solve problems, so that we could consider alternative approaches, and to these ends there'd probably be lots of pair programming. The name “Code Retreat” would prevent anyone from showing up who wouldn't want to attend something called “Code Retreat”. It would be a day for a roomful of programmers, working together, to get better at programming. I signed up.
My vague impression wasn't far off: the assignment was the old chestnut Conway's Game of Life, there were five 45-minute pair programming sessions, and the goal was not to solve the whole problem in 45 minutes (fat chance!), but rather to practice solving various parts of the problem under varying constraints. At day's end, I would not be delivering code. I would be delivering my brain in an improved state.
How to make 45 minutes disappear
The first session was simple: remember what it's like to pair with a stranger, possibly use or explain an unfamiliar programming language, load the problem into our heads, solve some of it, and throw away our halting attempt. In this and two other sessions, I “drove” in Perl, a language with which my navigators were unfamiliar. I found it satisfying to offer an existence proof that a test-infected programmer with well-configured tools can develop in Perl as quick-deliberate-ly as we expect from newer, trendier languages, and that the result — were it to live long enough to be judged in production — might well exhibit all the hallmarks of happily maintainable code.
If it's good, do more of it
I found the two sessions in which I was more of a “navigator” more satisfying still. By some combination of the role itself, languages unfamiliar to me, the particular constraints assigned, and my pairing partner, these were the sessions in which I most memorably felt my own learning. In one, iterations could last no longer than 2 minutes: the guy who actually knew Ruby wrote a test, and if I made it pass before time ran out, we could commit it, else revert (!). For the first few iterations, we didn't slice thin enough, and weren't close; for the next few, my understanding of Ruby syntax was the bottleneck that made things exciting; and by the last few, we had mastered the art of the tiny increment. Besides spending a little time with Ruby, the value for me in this session was to consider what happens when we take a familiar TDD practice to the extreme, and thereby to reconsider the meaning and utility of increments.
In the other of the two sessions, we weren't allowed to speak, because we were adversaries. Our communication channels were the compiler and the tests, no more, no less. The guy who actually knew C# wrote a test, and I could write whatever stupid/clever code I wanted, as long as it made the test pass. He'd write a test in reaction to my best stupidity/cleverness to make it harder for me to do that. A few tests in, it was considerably easier to write sensible code than dumb/clever code. Halfway through, we switched roles. I wrote a test to spot-check cell states in a sample grid; he noticed a pattern in the input data that he could exploit to pass the test, not via row-column access, but with modular division. We were off to the evil races. Time ran out, not a moment too soon, as he set about overriding the definition of Object.Equals(). Being unable to speak forced us to express intent through our tests. Being adversaries forced us to maximize the clarity of our intent. This is a familiar function of a test suite, with (as before) the knobs turned all the way up.
More learning, please
After a full day of pair programming, I realized I'd been missing something important in my life. Nobody at Code Retreat needed to be told why TDD or pairing are valuable practices. We were all practitioners, we all knew why and how, we all wanted to get better. The contrast with my day-to-day was striking: so many shared values, so much overlapping knowledge, so little friction. It felt terrifically energizing to swap expertise with people whose expertise meaningfully relates to mine. I'm reshaping my day-to-day to include more of this. (More in an upcoming post.)
In summary, Code Retreat was like I expected, but better, and I liked it so much I'm doing it again tomorrow. Global Day of Code Retreat is tomorrow, December 14. I'll be participating in Frankfurt. If you're a programmer who wants to sharpen your skills, no matter where in the world you are, I hope you'll consider attending a Code Retreat.
P.S. There's also a Legacy Code Retreat format which I hope to experience someday. In the meantime, I ported its terrible code to Perl, which was strangely hard for me.