When I left college I knew a bit about GNU Make. Just a bit though. Only what I had been taught in class to make my C++ applications build. I had no idea what I was really doing, nor had I any concept about the power of the tool or related tools like Autoconf.

I had to run into the problem of a complex build and deployment process before I really “got” the idea of build scripts. The same thing was true for me about test-driven development. Until you experience the pain of playing wack-a-mole with regression errors it’s hard to comprehend the importance of well written unit tests. Hell, when I think about it, almost every single major point of growth in my ability to develop software has been based on me virtually banging my shins on something.

At this point in my career my virtual shins should be entirely black and blue.

A major benefit to learning software development in this manner is that every line of code you write, you write with purpose. You avoid falling into a trap placed in front of developers by many well-meaning experts – you never get religion. If an expert says you must do TDD or always follow the rules of OOP… well, you do it! Because it’s better. But why is it better? Well, you forget, but it must be better because the smart person told you so!

Getting religion about code is dangerous. It makes you less pragmatic and less open to new ideas. Best practices are only best until something better comes along. How will you know when something better comes along if you don’t really understand why the current best practices are “best”?

I think that’s why I, as the author of a book about object oriented programming, am currently in a study group with some friends (including my co-author, Sam Wan!) trying to learn Scheme and functional programming. After all, sacred cows make the best hamburgers.