Once you've taken your first steps as a "Ruby nuby", you're ready to start thinking about how to write software that works. Software development is simultaneously both very simple and extraordinarily complex. It's simple because every line of code we write is easy to read and understand, but it's complex because the interactions between all the lines of code give the software its interesting behavior.
As you'll have discovered if you played around with the toy Odometer example from my last article, it's very easy to make a mistake when coding. That example was tiny; it only had three classes and less than 100 lines of code. Imagine the grief you could have working on a small application, say 5,000 lines of code, and then scaling up that fun factor as you realize that commercial applications often contain 50,000 to 500,000 lines of code (though some are much, much bigger). When applications get to be that size, verifying that the code works becomes a major challenge.
Obviously, someone will have to test the overall application once you've managed to get parts of it working, but getting large enough parts of it working for someone to test it is difficult. Yes, you can use the traditional design and code reviews to have other pairs of eyes look for mistakes, and you can try stepping through the code in a debugger to see what's really happening, but there's a much better way: test-driven development.