I’m finished with Learn Ruby the Hard Way. It took me way longer than I thought it would. All in all, it was a really great overview of the Ruby language, test-driven development, and project organization.
I found Chapter 37 to be one of the more valuable in the course. It’s simple enough: go through a few dozen of Ruby’s symbols and keywords, guess at what they do, look up what they really do, then write some code that shows what they do. While this may sound tedious to some, I found it incredibly valuable to get a better grounding in the Ruby toolbox and a reminder to spend time studying the entirety of the languages I use instead of just nibbling around the edges.
The course involves a good deal of repetition. Revisiting concepts and projects throughout to help drive home the fundamentals of the language. Practice and drilling on fundamentals is something that you don’t always hear about when people talk about learning to program, but it’s probably the best way to learn. Like the 10,000 hour rule says: if you want to master something you just have to do it. A lot.
One of the the aspects of the course that didn’t resonate with me was that the larger exercises focused on creating games of one sort of another. I had a difficult time dreaming up a text-based “you’re in a hallway with a door in front of you” type of game.
Luckily, my office has a mostly-weekly Ruby quiz. One of the challenges was to develop a blackjack program and it coincided nicely with one of the game development chapters. I was excited to dive in and began making good progress. As I implemented rules, the card deck, and other aspects of the game, I discovered something. My code was a mess. Blech. There were instance variables all over the place, methods that did all kinds of different things…an unmitigated disaster. But it ran!
Great, so I had basically created the AMC Pacer of blackjack programs, the Spruce Goose of Ruby scripts. When it came time to show my code, I told everyone how dissatisfiled I was with the way it turned out. Thankfully, I work with a supportive group of people (MINiSWAN) who had a lot of great suggestions. The most useful feedback I got was the following: “your code works, but it’s not clean.”
It’s clear that my study of Ruby as a language will take me longer than one month. I had a feeling when I set out to cover a different topic every month that some would probably spill well over that limit. In those cases, I can either “call it” and move on or take the extra time, depending on the situation.
In this case, I feel it’s well worth it to stick with my study of Ruby for at least another month. The next topic I plan to cover is Pragmatic Programmer’s screencasts on metaprogramming and the Ruby object model. I’ve watched a few of these already and I’m looking forward to going through the rest.
Special thanks to Joe Nelson for sending me a virtual pants-kick via Twitter.