Author Spotlight - How I became a Software Engineer/Game Maker

Before I wrote software for a living, I first worked a retail stockroom, then delivered pizza for a good while, before taking calls in a call center for three excruciating years. My path into this industry isn’t the normal one, and the lessons from it are exactly the lessons I’m applying right now to building my passion project game.

It’s Freeform Friday, so this is the one place on the site where I get to talk about whatever I want — and I’m feeling a little retrospective this week.

The stockroom, the pizza bag, and the headset

None of those jobs prepared me to carefully write syntax in x languages. What they taught me was something more useful long-term - how to survive doing repetitive, undervalued work and how to keep showing up when there’s seemingly no future ahead.

I didn’t go to school for computer science. I’m mostly self-taught, and the training I have came either from shadowing more experienced developers or from being thrown at real problems on the job and figuring them out under pressure. That, and hours upon hours of watching tutorials and reading documentation.

If you’re reading this from a job that has nothing to do with software or games, and wondering if it’s even possible to cross over - it is, but it’s worth being real about what it actually takes, instead of giving you the usual inspirational speaker talk.

What actually got me across the line

A few things mattered more than anything else:

I let the outside noise fuel me rather than discourage me. Stocking shelves, delivering pizza and answering calls aren’t exactly glamorous jobs. As a result, I had several people in my life ask me what I was doing with my life (I was 27 at the time), and whether I planned to just continue doing minimum wage jobs forever. I always knew I was capable of doing something more with my life, but I just didn’t know what or when an opportunity would arise.

I wasn’t scared of the unknown. I wasn’t even looking for anything to do with software when I got presented with my first opportunity to be a QA Analyst while working at the aforementioned call center. I had very little idea about what that job actually entailed. I knew QA stood for Quality Assurance, and that I had to learn about something called the SDLC (Software Development Life Cycle), but otherwise, I was taking a blind leap into something completely unknown.

I created my opportunity, instead of waiting for one. After becoming a QA Analyst, it just so happened that the company I worked for was forced to lay off a bunch of developers and QA team members after my second month on the job, and they kept me on board (mainly because I was cheaper than my more experienced co-workers). At that point I had just learned about the idea of automated tests messing around with Selenium and some very basic JavaScript functions to wait for modals and click on things, and I had a crazy idea — I asked my boss if I could start training as a developer part time since there was less code for me to QA now, and we badly needed the developer help. Oh, and I offered to do it for free in order to gain experience. Asking that simple question became the launching point for my career.

Why I’m telling you this on a game dev site

Because I’m going through a smaller version of the exact same scenario right now with my game.

Professionally, I’ve spent over a decade writing C# .NET code, building backends on Azure Function Apps, SQL and Cosmos databases, and shipping production systems for e-commerce and SaaS products. In that world, given my years of trial and error, I finally have confidence in what I’m doing in that world.

In game development, I don’t have that yet. I’m only now, after 7 years, starting to make significant progress on my project. (I’m building a pixel-art Time-travelling JRPG with turn-based combat in Unity). It isn’t even close to being released. My only public release so far is a small game called Unstaball, made in under a day for a Ludum Dare jam — a tiny, rough thing, but a real finished one I made end to end. Everything else I know about game dev, I’ve learned the same way I learned software the first time around: by building, by breaking stuff, and by watching people who are much further along — channels like Brackeys, Thomas Brush, gamesplusjames, and DesignDoc have all taught me pieces of this puzzle at different points.

The C# is familiar. The engineering instincts transfer well — thinking in state machines, keeping systems decoupled, not being afraid to refactor the mess left by my past self. When it comes to crafting games though - you have to master level design, game feel, pacing, drawing sprites that read clearly, animating attack animations, mixing audio so a hit doesn’t sound flat, etc. I’ve always had a decent idea about all those things because of my love for video games, but it’s safe to say none of that came from my day job. I’m learning pixel art in Aseprite the same slow way I learned to write code: by doing it badly first, then a little less badly, over and over.

Staying motivated when there’s no deadline forcing you

The hardest part of both transitions — stockroom to software, and software engineer to game maker — wasn’t the technical part of it. It was staying motivated on the days nobody was checking on my progress and nothing was forcing me to show up besides me.

A few things that have actually held up for me:

• Small, finishable goals beat big ambitious ones. So instead of “Implement the inventory system”, try for “Create the UI for the inventory system” or “Create the item storage logic”.
• Game jams are the fastest motivation reset I’ve found. A hard deadline and a tiny scope, like the one where I made Unstaball, forces you to finish something instead of endlessly polishing something you’ll never ship. Finishing anything, even something rough, does more for your motivation than another six months of “someday” work on the big project.
• Compare your current self to your past self, never to a stranger’s highlight reel. They say comparison is the thief of joy, and I’ve been down that road more than once. I still constantly compare my pixel art to the amazing artists I find online, but I keep reminding myself that at the end of the day they’re just people who practiced harder and longer than I have.

If you’re curious what that tools actually looks like once you compare the options, there’s a full breakdown in my comparison of pixel art software for game dev that covers Aseprite alongside the free and lower-cost alternatives. Also, if you want to see what “learn by doing” looks like in a completely different engine and problem, the walkthrough on coyote time and jump buffering in Godot 4 is a good example of the kind of small, concrete problem that teaches you more than a week of passive tutorial-watching would.

Something to try this week

If you’re stuck between a job you don’t love and a skill you’re trying to build on the side, don’t wait for permission or the perfect moment. You have to make your moment come. Pick one thing you can finish in a weekend — a tiny tool, a tiny game, a single mechanic — and finish it. Don’t worry about perfection. That one completed, imperfect thing will teach you more, and motivate you more, than another month of research ever will.