Why You Should Do the Boring Bit First. Lessons from Starting Over (Again and Again)

I want to talk about something I see all the time—and I’m incredibly guilty of this myself. You have an idea for something, whatever it may be, and you just dive in. If you’re a coder, you start coding. If you’re a designer, you start designing. Whatever your skill is, you jump straight into the part you’re really good at and away you go.

That is the first sign of a problem, in my opinion.

The Project Hack Story

Let me give you an example from my own experience. I have a game called Project Hack that I’ve been working on for years at this point. (You can find it at projecthack.net, but I’m not trying to promote it—just using it as an example.) I’ve lost count of how many times I’ve started this project over, and honestly? I don’t feel bad about it. It’s frustrating, sure, but I don’t feel bad.

Here’s what happens: I start working on it, and maybe I get really far into it. At one point, I had actually finished the single-player version. Everything was great. I’d nailed the bugs, released it as a test version, people played it, and it was fine. There was absolutely no reason I couldn’t have shipped it as a single-player game.

But it wasn’t the vision I wanted. My vision was to have multiplayer where people could compete against each other. When I got to that part, I realized I hadn’t thought about it enough.

The Technical Skills Trap

I hit a snag and started trying to fix that part, trying to make it work because I’d done everything else—this was supposed to be the last piece. But I just couldn’t get it to work. The reason wasn’t that I lacked technical skills (technical skills are something you can learn), but because I hadn’t thought through how this was going to integrate, what the specifics were, how it was all going to come together.

At this point, I’ve done this cycle I don’t know how many times. I’ve tried different approaches, different game engines, different ways of doing the whole thing. I’m even using AI now to help figure out how to get some of this to work. (And let me say, AI has done a great job solving some technical problems I’d never tackled before.)

But here we are, many years later, and I still haven’t shipped the vision I had. The problem isn’t technical—it’s that I hadn’t spent enough time figuring it out before I put fingers to keys.

Embracing the “Boring” Part

For someone like me, the thinking part used to be the most annoying bit. “Oh god, I don’t want to spend all this time just figuring stuff out before I make it. I want to make it!” Over the years, I’ve learned that this reaction is exactly the sign to stop and do your forward planning.

Even if it’s just a little bit of planning. In my case, with something so technically complex, it needs a lot more. But every time I tried this approach—and I know I’ve done this at least four times because I’ve used four different game engines—it wasn’t that any of them couldn’t do what I wanted. It’s that I couldn’t figure out how to get the engine to do what I wanted because I hadn’t thought about it. I hadn’t done my homework, and I hadn’t let the idea “bake” long enough.

The Game Design Document Revolution

This time around, I embraced something I always thought was pointless for a solo developer: I created a game design document. Basically, it’s a document that describes what I’m going to make. This can mean something different to everyone depending on the project, but I also update it as I go.

I have this in a dedicated folder for this one project. Every time I have an idea, there’s a page to put down ideas. Every time I hit a technical problem, I make a note on a to-do list. Every time I implement a feature, I document how I did it, including sketches of interfaces.

In many ways, it’s become a journal. It started as a document that said “this is what this thing’s going to do,” and now it’s a journal of how I’m going to get there, the things that aren’t working that I need to solve, and the things that have worked and how I solved them.

Why Documentation Matters

Here’s why this matters: when you come back to code (or any project) two or three months later, you’re not going to remember why you made every decision. A comment in the code might tell you technically what you did—like how camera metadata tells you the technical aspects of a photo—but it doesn’t tell you why you took that photo.

What if you want to look back and ask: “Why did I do this? How could I make this better? What was I thinking?” None of that technical data will help you. That’s why you want these documents or little notes to yourself.

The Universal Lesson

I know this might seem specific to game development, but abstract this out to whatever your scenario is: do the boring bit first. Trust me, you’ll thank yourself later.

Maybe you’re someone who loves the planning part but doesn’t care for the “now go make it” phase. If that’s the case and you can work with others, great—do the bit you love. But if not, push yourself to do the bit you feel you don’t need. That resistance is your flag saying “I haven’t thought this through before I started.”

All of this will help you complete projects, get to the end of projects, or maybe realize a project isn’t going in the direction you thought. You might discover you’ve pivoted and taken things in a direction you didn’t mean to. But you need that reference material to figure it out.

Keeping Your Sanity

It’s very much like keeping a journal, and it will keep you sane. Game development is incredibly hard—personally, I think it’s far more challenging than making apps, and I make apps professionally every day. Games are harder because users do things you’d never expect. “Why would a user do that?” Well, they do it because they do.

So that’s my advice: take it a bit slower. Embrace the time to think about something. I’ve been careful not to call this “project planning” because that sounds formal and scary. Just formulate something that works for you so you have a reference before you dive in.

Otherwise, you’ll live to regret it and start to hate a project because you created a brick wall for yourself. If you’d thought about it for five minutes before starting, you would have seen that brick wall coming and dealt with it then and there, instead of becoming totally demoralized and wanting to give up halfway through—especially on personal projects where your brain knows you can just walk away.

Have thoughts on this or want to share your own experiences with project planning? I’d love to hear them. Reach out to me through my contact page.