I recently left a long career doing corporate and business software development. In fact, I’ve written software professionally for over 20 years now.

I actually wrote my first game around the age of 9 or 10 and I continued writing games until I joined the army at around age 20 and had to grow up, as society wants to call it. As such, I’ve actually got 10 or 12 years of game development prior to that so I’m on safe ground when I say that I’ve been making computers dance to my tune for over 30 years.

Throughout those years, I’ve learned some valuable lessons, many of which are surprisingly relevant to game development, as different as that is from the “serious” side of software. I’d like to share a few relevant lessons.

1. If it ain’t fun, you’re doing it wrong.

At various times in my career, I’ve moved into different areas of software. Without exceptions, whenever I’ve started developing software within an area, I’ve had incredible fun. Without exceptions, whenever I’ve stopped having fun developing software within an area, I’ve left that area shortly thereafter.

Take web hosting. I built a web hosting company in the 90s and had incredible fun building very complex and advanced publishing solutions. At some point, we stopped doing that because it got too serious and people wanted to buy the company and other grown-up things. We had to focus on what generated revenue rather than what was awesome. It stopped being about fun and started being about making money.

The company failed within a year after that.

There’s a time to be serious and always enough serious to go around. There’s never enough pure joy in simply creating, contributing, and having fun! It is also a lot easier to keep motivated if you enjoy what you are doing.

Lesson learned: Do stuff because it excites you and makes you happy or full of joy.

2. Learn all the time because knowledge and skills are easy to bear

One important thing I’ve learned is to bring as much knowledge as possible with you when you stop working on a project or task. By that I mean that you should always ensure that you learn something when you do something, even if it is how something completely fails if you don’t follow certain patterns.

This serves two purposes. First, it exercises your brain, and from what I’ve read (don’t take this as any scientifically founded claim) your head needs exercise as much as your body in order to stay healthy.

Second, however, is that knowledge is very easy to retain. It’s not something you need to lift when you move to a new city or on which you pay mortgage over the next 30 years. It’s yours, it’s free, and it’s very valuable.

When we built our first game, Maff’s Math Game, we focused more on learning how to build games than actually building the game. In other words, the entire team mostly learned for an entire game development life cycle with no plans or intentions of making a profit.

The result is that when we start new games now, we can skip past many of the learning bits and get results much faster. True, the investment in learning cost a lot of money but we know that long-term, we get that investment returned many-fold.

Lesson learned: Omnia mea mecum porto, my life motto. Google it.

3. Build reusable components always

My previous company was currently building a new game series called Final Arena. At one point, I wasn’t entirely certain we had the right formula for the gameplay. I hadn’t tested it yet but we moved forward with development to the stage where we would hire composers, modelers, animators, and so on.

“That’s madness,” any conventional wisdom will yell at you if you did something similar. “You need to test your idea early and fail fast”. And I agree, but I’ve learned a more important lesson.

You see, the way we build games, the codebase allows us to replace any part of the game fast. If the current gameplay doesn’t work, fine, we can switch it with something better, but that doesn’t change that we need a system for controlling characters, telling the stories, saving the state of the game, keep track of health and inventory, and so on.

By building the various parts of our game as individual components, we can replace parts that don’t work without affecting the rest of the game. Equally important, we can take parts we build for this game and reuse in other games because unless I’m mistaking, there will be a need to have music, a story, and characters in future games too.

Lesson learned: Reuse always. Even if you won’t, assume you will. It’s easier than you think.

4. Language is irrelevant but mandatory

Wiser men than me have spoken about computer languages, but I tend to favor the paraphrased quote that languages are to programming what telescopes are to astronomy. You need one, but it’s never the goal of the operation.

It stuns me how frequently I see debates about which language is best for game development. The truth is that there is no answer, and that’s likely the reason why the debate can go on for decades with no clear outcome.

So, whereas you do need a language to do game programming, it is far less relevant which one you pick.

This brings me to the second part of the heading; you always need a language. Despite how many toolsets now exist for building games with no programming, learning programming is vital to game development. You cannot do game development well without learning to program.

In SharePoint, where I’ve spent most of the previous decade or so, Microsoft has had to cancel the most important non-code development tool, the visual design interface in a tool called SharePoint Designer, formerly known as Frontpage for those that know their history. Microsoft said they did this because SharePoint was getting a MySpace problem with all the willy-nilly modifications people thought were so great.

That’s happening because it is far too easy to get to a certain point and thinking you’re delivering value when in fact more times than not you are just painting yourself and possibly your team into a corner.

A programmer’s mindset, however, and in particular an experienced programmer’s mindset, will understand problems to a much greater degree before they start building solutions. They will understand maintainability, extensibility, security, and many other aspects that the drag-and-drop-and-website generation never sees.

And it’s not about programmers having superior intellects or anything like that. It is rather that writing code teaches you how to approach problems in a very rational and methodical way. As much as I can, I urge people to get into coding even if they will never write a line of production code for the rest of their lives, simply because it makes them more rational problem solvers.

Lesson learned: Learn programming. No excuses.

So, there you have it. Four important, if not the only lessons I’ve learned over a lifetime of software development that I’m now actively applying to my game development career.

Which lessons have you learned in your life that you’re now applying to game development?

(This article was first published on Gamasutra)