Today is my last working day of 2009, this last year has flown by! I did briefly contemplate writing a blog about the things that I have learned this year, but soon realised that would be crazy, there has been so much. This time last year I had been a Ruby developer for 3 months, on top of that I was learning Rails, TDD/BDD, Agile etc. I also distinctly remember what the last week (of 2008) in the office was like, I got to see first hand what happens when the technology that should be working for you, starts to work against you. The technology we were using to store our data was falling over frequently, the delivery date for the iteration was looming and important decisions had to be made. Stick with it and try and make it work? or migrate over to something a little more tried and tested? We went with the latter, because of good design decisions and practices.
That week I learned the value of abstraction, had we had tied our data model code too closely with a certain technology we would have been in trouble. Despite being a bit of an inconvenience the move over to the other technology was relatively easy. The other lesson I learned was to take the last week of the year off 
So that’s what I’m doing.
Bringing everything back up to the present, this week has been good all-in-all. Monday afternoon was the time that I ran through my first apprenticeship task with disappointing results. We were asked to do a Binary Search code kata in Ruby and RSpec. The kata was successful in that the tests I wrote lead me to a solution, the way in which I approached the tests was wrong… very wrong. I approached the problem how I would with any new model I was creating, I started to spec how I wanted the code to behave. This challenge differed slightly from your day-to-day client project, in that you are trying to drive the development of an already-designed algorithm. All I really needed to do was to drive an initial set of assertions and then develop a suite of tests to cover the other edge cases. There was no real need to test every line of code. By doing so you only tie yourself down to your implementation. What if you were asked to implement the algorithm using a different approach, you would have to throw away all your code and most of your tests. Waste. If I had written a suite of tests that covered exactly what the outcome should be, I would only have to re-write my code, using the same tests to confirm when it was complete (all passing). Very important lesson learned, thanks James and Chris.
So i’m going to spend some time running through my kata again until I get it nailed. It has also inspired me to spend some time learning how other people do TDD. I have realised over the last year how different everybody approaches TDD, it is very rare to find two people who completely agree on how best to write tests. Everybody has their own styles and practices, and thats a good thing, as long as the code is tested well. Over time i’m sure i’ll develop my own style and practices, but always remaining open to change.
Have a great Christmas and New Year! See you in 2010!