Code is an afterthought

4 min read Original article ↗

Since I was a kid, I thought I was good at coding systems: tinkering around a problem, writing a set of specs to understand what was going on, and from there coming up with a practical solution.

I remember seeing my XNA programs running on the background of an old LCD monitor I had back then, after hours of fighting with tutorials and setup guides on how to prepare my environment. It always came down to that moment: running, experimenting, dropping a few more lines of code, then calling it a day.

Getting bored of the boring part: setting up the environment, learning the language, and all the other things that come with learning how to code.

Eventually I ended up learning code of many different languages and syntaxis out there: how to iterate, how to loop, etc.

After a while I recognized I was doing the cumbersome part first, to just get to the fun part later on completely annoyed, eventually desisting from coding for a while, and then coming back to it again, just to repeat the same cycle with other project.

In the end, I learned a lot as a consequence of that, but I never really enjoyed the process. It was something in the middle of preparing the environment and writing code that I liked, but I never really liked the coding itself. It was just a means to an end.

At some point, I decided to host videos in Youtube about how to prepare your setup and actually code.

A few years later, after three completed games (which back then I genuinely believed were “published”…how naive I was), I decided to start coding more professionally. I began using C++, Unreal Engine 3.0, SDL, and a few other libraries, just to make my ideas come to life again. But I always ended up in the same spot: losing time configuring the environment, tinkering with every knob just to get things ready before I could actually write code, and by the time I got there, I was simply too tired to continue.

GOTO 1.

After a while of playing thought and with less time given university and such, I learned that coding itself wasn’t what I liked the most. What I actually liked was orchestrating the systems around the code to make it feel alive: particle systems, game engines, modules making other modules talk, orchestration layers, notification and alert mechanisms. Everything I built during my childhood and early adulthood was covered by this developer tooling mindset.

It was never code for the sake of code.

Make the tools you want to have, but that don’t exist yet. Looking back, it’s a bit sweet of me to have called that coding at all. Coding was coming up with novel and weird ways to apply Dijkstra, not this.

Nowadays I honestly believe I didn’t “code” much at all.

I remember the learning loop I ran every single day, from the moment I woke up until I went to bed:

  1. Pick a topic
  2. Do a simple tutorial, a getting started guide
  3. Finish it
  4. Come up with an idea from step 2
  5. As soon as you learn what you need, jump back to step 1

All of this LLM-madness-or-not reminds me a bit of those days

After reading Thinking in Systems by Donella Meadows, I realized that what I was really interested in was not the code itself, but the systems that the code enabled me to build:

Remember, always, that everything you know, and everything everyone knows, is only a model. Get your model out there where it can be viewed.

I was always more interested in the interconnections of the different components, the design of the system, and how to make it work together, rather than the actual code itself. Eventually, I ended up learning that I was never a good coder, probably an average one, but a good architect of all the moving parts.

Yeah, heck I know that LLM-code might not the best, but mine wasn’t either.

Code for me was always an afterthought.

Never the end game. Just the medium to get to what I was actually after: fun.