The first operating System I remember using was MS-DOS. I was just a kid, but my dad had made a cool .bat file that showed a menu of all the games that were installed on the computer whenever I typed menu commands into the computer. I was enthralled that I could make the computer do something like that.

To this day, some of my favorite games I have ever played are the Commander Keen series, Doom, Heretic, and Hexen - all games created by a little company called id Software.

Who is John Romero?

Id software, at the time these games were created (1990-1995) consisted of three employees, John Romero, John Carmack, and Tom Hall. These three individuals ended up shaping much of the gaming world as we know it today. Side-scrolling games on PC? They invented that with Commander Keen. 3d first-person shooter? That was them too with Doom. A concept of a common game engine that you could develop several different games on? Built by id software.

Needless to say, the founders of id Software are legends in the programming world because of what they were able to accomplish so quickly, and so early. You can imagine my excitement then when I found a recent video of John Romero himself giving a talk at a tech conference. Programming advice from one of the people that basically invented the way games are created now? Yes, please!

3 Programming Principles from the early days of id Software

In his talk, he outlined eleven principles that the team lived by to keep themselves efficient and organized. They are all fantastic, and each is still completely relevant to software development today, despite the games they are known for being published decades ago. Despite all of the changes in technology, computers, and programming languages, his advice remains timeless.

Here are three that resonated with me the most.

Keep Your Code Absolutely Simple.

Keep your code absolutely simple. Keep looking at your functions and figure out how you can simplify further.

Too often, I have fallen victim to getting "in the zone". I know what needs to be done, and I know how I want to do it, so I just plow ahead, and write the code to do it. I don't think there is anything wrong with this approach initially. As they say, "make it work first, then optimize later."

The problem is that it is all too easy to remember to do the second part. If you make a mess in the code and never go back to clean it up, then you are going to be left with a mess. A mess eventually grows and grows until it becomes unmaintainable and you have to start over from scratch again. It doesn't have to be this way.

Some of the code that I am most proud of was code that I wrote that ended up reading like a story. Not like an actual book, but it was made up of lots of little functions that all had descriptive names of the single thing that they did. Yes, it made for a lot of functions, but that's not a problem. It makes it really easy to debug something when you can trace a problem to a single function that is no more than ten lines or so long.

Keeping your code absolutely simple, to me, means keeping your functions small, descriptive, and flexible. Make them readable so the next person who comes along can quickly see what the code is doing. His advice shares a lot of similarities with some of the things I write a while back in a previous article.

Keep your code simple, so you can keep moving forward.

As soon as you see a bug, fix it.

As soon as you see a bug, fix it. Do not continue on. If you don't fix bugs, your new code will be built on a buggy codebase and ensure an unstable foundation.

This one takes disciple to master. I have yet to find anyone that likes fixing bugs. It is usually much more enjoyable to create new things than it is to try and fix old things.

The reality is though that bugs happen. You will create them yourself more times than you will ever be able to count. You will create bugs in other people's code.

Welcome to software development.

The important thing is that you fix bugs as soon as you find them. I will slightly amend his statement to "fix it as soon as possible". You might not be able to fix the bug right at that very second - being a developer also means balancing all the priorities and tasks that you have to get done. If you find a bug that is tangential to what you are working on, and it doesn't directly affect you, then write it down, and come back to it as soon as you are finished with what you are working on.

I have been in messy codebases before - it seems like every code base has its "dirty closets" that need to be cleaned up. But a "messy" codebase and a "buggy" codebase are two different things. I would rather have a mess that works, than something that doesn't work at all.

Break your code

We are our own best testing team and should never allow anyone else to experience bugs or see the game crash. Don’t waste others’ time. Test thoroughly before checking in your code.

The only thing worst than having to fix bugs is finding that they exist in the first place. It's never fun to find out that you made a mistake.

The key to getting past this is knowing that you are going to make them. Software bugs are going to happen, despite your best efforts. The key is minimizing them.

How do you do that? You just have to test the crap out of your code. Don't just test the things that you know will work. You have to test unexpected inputs. Try and break your own code! If you don't try to break it, you can bet somebody else will, either on purpose or unintentionally.

The real problem comes when bugs are encountered that disrupt the program. In a game, for instance, there is nothing worse than having it straight-up crash on you. So Romero and his team would constantly try to crash it by doing as many weird things as possible. To their credit, I don't ever remember any of their games crashing while I was playing them.

Do the same for your code. See if you can make it break. What happens when you give invalid input? Do you get a helpful error message about what went wrong, or does your application just blow up in your face?

Nobody knows your code better than you do when you are writing it so you are the best one suited to testing it; not a QA team member later down the line, or heaven forbid, a user of your program. You wrote it - you bulletproof it.

Check out Romero's Talk

I've included a link below to the full talk given by Romero at the StrangeLoop conference in 2022. If you are an aspiring developer, his thoughts are well worth your time.