Just Get It Done

Eggerworld is the latest in a long line of game engines I've written, but it's the first time I decided to share my personal process with the world. Something I've experienced many times is analysis paralysis, or the fear of making a “wrong” choice, and stalling. This is a personal challenge I face, though I suspect I'm not alone. My solution for Eggerworld is to embrace a simple motto:

Doing it wrong is better than not doing it at all.

Obviously this is not universal advice, and certainly not advice you want to hear from surgeons and architects. But when used responsibly, I think this motto has done a lot of good for my software development.

In the case of game engineering, there were tons of questions I had at the start which kept me from starting in earnest. What is the best language to use? What libraries or frameworks? Which graphics library? How should games store world data? Do others build their own editors? I procrastinated because I didn’t want to poo the screwch right from the start. 

Ironically, my most fundamental failure was making nothing at all. A poorly-made game can do no worse than exist, and failures can teach us how to do better next time if we choose to reflect on our experience. Thus I resolved to embrace failure and learn from it.

Failure is the greatest teacher, and I have learned a lot. Many, many times. So much learning.

See, software is different from surgery and structural engineering in that it can change and modify so easily. You can build something wrong and then just revert it. Tools like Git and IDEs like IntelliJ have made it easier than ever to undo big mistakes and revise the history of our codebases. Don’t be afraid to fail something that’s easy to undo, especially if you learn from it.

Many software developers have probably heard the phrase "move fast and break things" and I don't think that's quite the same thing, because there’s a certain deliberate, destructive recklessness about moving fast and breaking things. By contrast I believe in planning what you can and accepting what you can’t. Recognizing inertia is a skill, and it’s a virtue to understand the difference between situations where "failure" is consequential and when it simply isn't. 

There are far fewer real “consequences” in life than society led me to believe. School drilled into me this idea of a “permanent record” looming over everything I do like a personal spectre. Depictions of high school students show them fearing ruin because of the toilet paper clinging to their shoe, or ruing their romantic lives because of “the one that got away”. In reality, these are transient things we’re taught to fear as if they’re permanent, glossing over the reality that these are brief flickers in a lifetime of events. The honest to goodness truth is that many risks are simply not as risky as they seem.

I advocate for really scrutinizing my decisions, which informs me how much effort I should put into making them. There’s a popular industry concept about “one-way doors” vs “two-way doors”, and I like that analogy; a two-way door deserves very little thought because very little effort is required to reverse it. Of course, decisions we make as a small team of game engine developers have lower stakes than the work I’ve done on a foundational platform used by hundreds of employees and thousands of clients. Knowing the difference between one-way doors and two-way doors is a skill and it requires practice.

So when you ask yourself what coding language to use for your next hobby project, the answer is probably a two-way door; you can always restart the project but with a better language, and it will probably go faster the second time. Don’t get stuck deciding whether your game engine should handle sound through a static global singleton or if it should pass messages to an application manager; eventually you need to just try something and learn why it’s good or bad, then refactor if you need to.

I always start with a plan, but a plan doesn't have to be a big ol' dossier, sometimes it's just being able to answer "why am I doing this?". I found it was very freeing for me to just do something when I felt like I was at a crossroads. Because just getting it done and doing it wrong definitely worked better for me than not doing anything at all.