About

A typical RockStar programmer.

I think it was Bill Gates who said, “Software is a great combination between artistry and engineering,” and he was absolutely right. It is. 

The first time I heard the term “rockstar programmer” was in relation to John Carmack. He was the guy who first used binary space partitioning in a 3D game, dramatically speeding up rendering and giving us classics like Doom and Quake on a 66MHz Pentium. In the mid-nineties, Mr. Carmack was driving a red Ferrari 328 and became the synonym for the term, launching us all into a dream about becoming filthy rich game programmers. I am a guitarist and a big Rolling Stones fan, so at that point, I had already started using Keith as my online avatar, but Carmack is without a doubt a contributing factor to why it stuck.

Software is incredible in the way that you only need a computer and your mind. From that, you can build anything from applications keeping track of your private economy, to train times, to building Martian invader games, or entire fantasy worlds. Only your imagination and your skill set set the boundaries, and this is where things start to fall apart. Skills. While it is super simple to create smaller applications, things get exponentially more difficult with bigger applications, and become busy beaver-level complicated with large applications.

Now, you might think that making a mobile game or a video editor is a job for a large team. That is not entirely true. While a big 3D shooter or a full-fledged Image Editor will require a large staff for assets, artwork, resources, and answering angry customers, the core software team is often built around (if not a single person), then at least a very small team. Think of Minecraft, Tetris, Navision, or even Microsoft or Google, although the latter two kinda have blown up recently : )

For many years, I was the lead developer of the open-source 2D iPhone API, Cocos2D. In its golden days, close to 50% of all games in the App Store top 100 were made with Cocos2D, and at that point, we were considerably larger than Unity3D. During those years, I saw many “one-man companies” release games and overnight make hundreds of thousands, if not millions, of dollars. Notable examples would be Train Yard, Geometry Dash, and Plague Inc, the latter booming during the pandemic. As for myself, one of my larger applications would be Emote. A mobile-based video editing platform, built from scratch to the beta stage shown in the video in nine months, and featuring some very beautiful “programmer's art” (cough). The beta later landed us a large investment, but that is a story for another day.

Many programmers have started building their applications, only to get stuck. The application may have started to crash, changes became increasingly difficult as they broke other parts of the application, or large core libraries had to be replaced. Some rewrote the entire thing, but the vast majority eventually gave up. The good thing, though, is that it is possible to do something about it.

The goal of this blog is to provide guidelines on how to write larger applications. While I am not advocating a specific style or trying to force you to do something in a particular way, I present to you the way that I have been able to write large and highly scalable applications. I am an old-school programmer who has been around since plain vanilla C was the new kid on the block, so I do it the old-school way, and am a strong believer in not making it more complicated than it absolutely has to be. If this blog can help some of you become better programmers, and you can find inspiration or guidelines in how I do things, I will be a happy camper.

Special thanks to ChatGPT for fixing all the grammar :)

January 2024. 

Lars B. Amundsen

Gråsten.