Investigators without Investments: Killing Software Craftsmanship

Recently with an inexperienced developer, I had an overwhelming sense of dismay over this developer’s wasted potential and lack of awareness and ownership in coding. This developer fits into a genre that I will describe as the “Investigators without Investing”. Often they may even take ownership of a task and “hack” away at it for hours on end, only to end up empty handed, or with a pot of boiled-over spaghetti code. I’ve wondered to myself, “how could this happen?” These “investigators without investing” seem willing and committed to development. Yet, beneath it all, these expert beginners are merely investigating established code and theories, without ever investing into their own talent and skill set. Learning concepts, theories, and established code will only take you so far – at some point to become, you must do.

When I was first learning to program I did a ton of hack and slash to get my pet projects working. These were, of course, learning projects. I had one goal: build X, make it work, and then go back and clean it up – or maybe not. Guess what? It didn’t matter because they were my learning projects to better my coding skills. When I went to work, I would work with leads and senior developers and consume as much of their knowledge as they were willing to share. I would team up with those I could learn from and ask a lot of questions. These thinking sessions were beneficial for both of us. When I would write code, I would do it with purpose. Completing the objective was not enough, I wanted to understand the Why and How code worked.

On one occasion I can remember a great friend and mentor of mine stopping my coding process, to give me this piece of advice,

“You must learn how this one component works completely, and be able to tell anyone exactly how it works. Once you’ve done that, we can move on to what’s next.”

From that encounter, my theme of personal growth has been that “Code must be learned one line at a time. Built on a foundation made steady by doing for yourself.” Experience doesn’t mean being able to understand what someone else does, or even writing X amount of lines of code. Experience is being “there and aware”, writing the code for yourself, growing, and becoming better as you do. You must investigate AND invest in programming to become better. In the end, you’ll never become until you do.

Leave a Comment