Global Day of Code Retreat
This past weekend my co-worker, Jon, and I participated in the Global Day of Code Retreat, an event that focuses on two things: Test-Driven Development (TDD) and Pair Programming.
Neither of which are exactly new to me, but in my day-to-day work there are only a handful of projects that use TDD, and we basically never do pair-programming. We collaborate, but never really in front of the same computer for any length of time.
The format was somewhat maddening for anyone that likes to see results from their efforts which I’m guessing is everyone. You get 45 minute sessions, each with a new pairing, each with some new constraints, and each potentially a new programming language to solve a problem that is completely unsolvable in that span of time: Conway’s Game Of Life. And after each session the code must be deleted.
I ended up faking my way through C# for 4 out of 6 sessions. The C heritage makes it fairly easy to guess the basics, and in 45 minutes, you can’t really test the limits of a language. The other 2 sessions were with Node & Ruby respectively, and they had their own problems.
In node, I had a outline for a TDD type project, but it turns out some of the core stuff (requires etc.) has changed since using it last and I spent probably 15 minutes actually getting the project running. In the ruby session we decided to forget the test library completely and use a single file with the classes and run the test functions within it. Worked well enough, though I actually had a harder time jumping into Ruby syntax initially than C#! That was bizarre to me.
Two of the “programming constraints” stick with me and I’d like to outline why:
1) No methods longer than 4 lines.
This is really hard! It really forces you to decompose the logic of your code into bite sized chunks. It also makes it really easy to check your logic at every step with test coverage.
2) No if/else/switch/case
This one is even harder, and I think i’m still learning the lesson within it. The way I see it is that it formalizes your comparison and conditional branching. We started by getting around it with some ugly boolean comparisons. But when we were forced to make a true conditional branch, it started to become clear. The solution we came up with, in C#, was to create a mapping of functions with a boolean key. Something like this:
true -> MethodToCall() false -> OtherMethodToCall()
And to do this, you also must create an interface that each of these methods implements. This takes what would have been a block of inline code and creates hooks that you could call and test independently of the code that is calling it. That’s pretty awesome actually.
All in all, it was a pretty good day. The language barriers were a bit tough, but it’s good exposure to see how other people work.