"We create our own demons." These are the first words from the movie Iron Man 3, in which one of Tony Stark's own creations comes back to haunt him and the rest of the world. I've found these words to be incredibly true in my studies of computer programming. There are certain little distraction gremlins that you encounter along the way with the potential to utterly destroy your focus and detour you onto a dead-end path. This will only happen if you feed these little monsters; if you are staunch in your commitment to learning what you set out to focus on, these temptations will be barely noticeable. If, however, you are like me when I set out to learn to build software, you allow your focus to stray all over the place and follow every glittering strand, after some time you'll stop to look at your progress and be highly disappointed.
One of the demons I've gently nurtured over the last three years that I've been interested in programming is the need to start at the very beginning of every new topic I encounter. For instance, when I gained an interest in game programming, rather than focusing on working through the textbooks I had purchased and thoroughly understanding the skills they attempted to teach, I'd grab onto a dangling thread in the text somewhere such as a brief discussion of CPU cycles, and decide that I need to fully understand computer architecture before I can learn game programming. This then repeats, ad nauseum, resulting in nice profits for Amazon, but very little progress or ROI for me.
This pattern of distraction began innocently enough. It emerged from the need to cut through the complexity inherent in computer technologies when trying to learn. Considering the game programming example, there are so many platforms and game engines available today and each is so immensely complex in what functions it provides, a newcomer can easily feel overwhelmed by all there seemingly is to learn and thoroughly underwhelmed by the results of his first attempts at getting something up on the screen. It was because of this challenge that I began seeking simpler examples to learn from with the goal of working my way into the complexity from the bottom up rather than the reverse. Rather than just work methodically through a book on say, OpenGL programming, I decided I go back to learn 'old-school' VGA programming in DOS, when you had to use ROM BIOS functions to draw to the screen and needed to write assembly routines for really intensive operations. Though this is obviously much more tedious and error prone, it is undeniably less complex than having to parse the inheritance structure of some API with a thousand other classes and methods you'll never come close to needing. Add to this the fact that nearly all of the 'example' code you usually find tends to do things in a seemingly (particularly to a newbie) completely non-intuitive way, expecting you to 'come around to the way we do things in _fill-in-the-blank_'. This frustrated me to no end. (to be cont'd)