Two months ago I started learning to program with the goal of turning this passion into a pursuit upon which I can rely to sustain my livelihood. This past week I have reached a milestone.
A software craftsman at a leading software consulting boutique in Chicago has agreed to act as a mentor to me over the next couple months with my personal goal of being hired on as a junior software consultant immediately after finishing my teaching job of two years, and as a full-fledged software consultant by the end of the year. It is surprising to me how quickly I have progressed; I hope to maintain this momentum throughout my course of study.
My mentor's guidance requires me to approach this learning from a new perspective: using Test Driven Development (TDD) to push my projects forward. In order to integrate TDD into my skill set I will be practicing it by writing TTT TDD style. First step: Ruby Koans! This is a series of test cases for various capabilities within the Ruby programming language. In order to complete them, one must fill in the missing parts of the tests, then check if they work using the terminal to run the "path_to_enlightenment.rb" file.
The second part of my learning involves practicing sets of keystrokes and logic patterns with a technique called a "kata." The goal of a kata is to ingrain these patterns into your fingers and mind through repetition, much how a musician would practice scales and arpeggios. With a solid foundation, pattern recognition becomes easier and new projects can be tackled with greater speed and accuracy. The first kata I am working with is a project that finds all of the prime factors of a given number. A video walkthrough can be found here.
Third, I will be receiving reading assignments. The first such assignment is a book by software guru Robert C. Martin entitled Clean Code. So far I have read the first three chapters and have learned about the importance of striving for readability when writing software. More time is spent reading code than writing it (at a ratio of 10:1 according to Martin), therefore every effort should be made to reach for clarity. With this in mind, when naming functions, methods, classes, and variables (and anything else that needs a name in your code), great care should be taken to ensure that the purpose of these components is clear from the name. Finally, keeping code readable means keeping code simple. Functions should "do one thing, do it well, and do it only." Thus, nesting clauses and trying to do too much only obfuscates and makes it much more difficult for someone to read and understand the purpose of the code.