As the saying goes, if the title of a post is a question, the answer is “no”. I don’t know how you would sensibly apply that to this one 🙂 Most of the days, for most of the time, I’m a software developer. I code, I plan, I think and learn. At other times, I’m writing things: on this blog, for book manuscripts, as letters and email; to plan, to help, to teach and to share.
Programming is a Soulslike. Dark Souls is notoriously difficult. You need to memorize enemy movements and patterns to get good at the game. You cannot beat it casually. The “Git Gud” meme traces back to this whole ordeal: You need to become a better player, learn the movements and patterns, in order to beat the game.
Watched Robert “Uncle Bob” Martin talk about “The Future of Programming” and wholeheartedly recommend it. In the talk, Uncle Bob brings up interesting points about the growth of the programming profession:
Programming does not grow up this way. On top of that, programmer mistakes in everyday devices now are causing lethal damage to real people. Self-regulation inside the profession (which, like traditional crafts, I guess could reduce the onslaught of newcomers) and proper teaching are essential to keep growing and making code more reliable a foundation of modern societies.
That’s part of why I write, too. Because I found it was extremely hard to learn creating applications properly, not just hacking together something that barely works. I want everyone else to have a head-start compared to me. While educating myself, I discovered ancient wisdom in books from the 1970s – stuff you can still tell (or should I say: sell) people today, like how to decouple parts of your system. As if we, as a profession, suffer from collective amnesia. Old wine in new skins.
Now that I know some rough estimates about programming’s exponential growth, this makes sense. There just isn’t enough time and care put into teaching these practices properly. It’s hard enough to equip students with sufficient knowledge to become somewhat dangerous in front of a programming environment. The rest then is delegated to on-the-job training, which I imagine is pretty disappointing for all parties involved.
The following isn’t a universal truth. It’s a report about my observations of a recurring theme in everything that’s great. First you imitate. Then you improvise. And then you may innovate. Imitation means repeating existing things to reach a deeper understanding of how it was done in the past. Improvisation means connecting the static patterns in creative ways to solve problems. Innovation means deviating from the known patterns in new and effective ways.
My last posts were rather prescriptive by nature. Before I start sprinkling in the casual software reviews, I want to slow down a bit and change the pace. Lately, I wondered why I do things. My answer is pretty plain, and I’d like to know what drives you to worry about organizing information. So I’ll begin to share, and then you may, if you like.