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

What's up, everybody? Welcome to another episode of the p w podcast. In this one, I'm gonna talk a bit about starting over or just refactoring an idea, pivoting, whatever you wanna call it. Now the reason I mention this is, you know, a lot of folks I see, myself included, very guilty of this. You have an idea for something, whatever it may be, and you just you dive in.

Right? If you're a if you're a coder, you start coding. If you're a designer, you start designing. If you're whatever, you you you start doing the bit that you know that you're really good at, and away you go. That is the first sign of a problem, in my opinion.

Because let's take an example. Right? One of my games that I have been working on for years at this point, Project Hack. And you can find it at projecthack.net, but I'm just using this as an example, not to promote it. Now it's a game, and I have used, at this point I I I've lost count of how many times I have started it over.

And I don't feel bad about it. It's frustrating, but I don't feel bad. Right? Because here's what happens. I start working on it, and maybe I get really far into it.

Like, for example, at one point, I had finished the single player version. Everything was great. I'd nailed the bugs. People, I've I've released it as, a test version, and some folks played it, and it was was fine. Everything was great.

There was no reason in the world I could not have shipped it as a single player version. But it's not the vision that I wanted. The vision that I wanted was to have multiplayer where people could compete against each other for some things. Again, the details don't don't matter for this as we're talking about it. But my point is, when I got to the part where I needed to do that, I realized that I had not thought about it enough.

And this was, a gush. I don't even know how many years ago at this point. And I hit the snag. And so I was like, okay. So, you know, I dived in and started trying to fix that part, trying to make that part and get it to work because I'd done everything else.

This was the last part. And I just could not get it to work. And the reason I could not get it to work was I had not thought about it. Now I knew I didn't have the technical skills, but was not worried about that because technical skills, in my eyes, something you can learn, solve the problem. Right?

But because I had not thought through how this was gonna integrate, how it was gonna be, what what the specifics were, I just couldn't get it to work. So I I let it sit for a little while like I do sometimes, go do other things, and come back to it. Well, at this point, I have done this cycle now. I I don't know how many times, and I have tried different approaches. I have tried different game engines.

I have tried different ways of doing this whole thing. And at this point, I'm even using AI to help try and figure out how to get some of this to work. Now first of all, let me say, AI has done a great job at solving some of my technical problems that I didn't know how to do, had never done, and and it had figured it out for me. So that was great. And then I adapted it to what I needed.

But here we are several, many years later, and I still have not shipped the version, the vision that I had. And I I know that the problem is, again, not not a technical problem that can be solved. The problem is I just had not spent enough time figuring it out before I put pen to paper, keys to you know, fingers to keys, what whatever your method or your, you know, your choice of tools, what whatever it is, whatever your project. Right? I had not spent enough time thinking about it.

And, yeah, you know, for someone like me, the the the part of thinking about it used to be the the most annoying part because it's like, oh god. I don't wanna spend all this time just figuring stuff out before I make it. I wanna make it. Right? Over the years, I've learned, of course, that that's the problem.

That that that is the sign that stop and do your forward planning. Right? Even if it's just a little bit. You know? In my case, for something like this, which is so infinitely technical and crazy and spaghetti that it needs a lot more.

But at the end of the day, every time I had tried this and I I I guess I've done this I can say I've done this at least four times because I know I've used four different game engines for it. And it's not that any of them couldn't do what I wanted. It's that I couldn't figure out how to get the appropriate engine to do what I wanted it to. Right? Because I had not thought about it.

I had not done my homework, and I had not let the idea bacon long enough. Now here's here's kind of the part here that I think is is gonna be beneficial. If that's you or it sounds like you've done a project, right, and it and it's not about whether you should start over again or pivot or or anything like that, but just stop and think about it. Now this time around that I've been building it, I actually embraced something that I always kind of thought was, what's the point? I'm a one person developer on this.

But now I realize the value, and that is I have a game design document. Not gonna go into the specifics what it is, but, basically, again, I'm trying to keep this generic for everybody and and whatever your choice of medium is and so on. It's a document that describes what I'm gonna make. And that can mean something different to everybody depending on the project, but I also update it as I go. So for example, I I have this in a folder.

Right? It's a dedicated folder to 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 to do on a list. Every time, I implement a feature, I document how I've done it, right, including, sketches of interfaces.

In in in many ways, it's a journal. Right? It's exactly what it is at this point. Started out as a a document that said, this is what this thing's gonna do. And at this point, it's a journal of how I'm gonna get there and the things that are not working that I need to solve and the things that have worked and and how I solved those.

And the reason for this too is, in my case, when you come back to code, whatever, two, three months later, even longer, you are not gonna remember why you made every decision. And a comment in the code is not necessarily gonna help you. It may tell you technically what you did. Like, you know, when you take a photograph and you record the details, or we used to. Let's put it this way.

Back in my day, with filming that, we would record the details, jot them down. These days, of course, it's all in the metadata. But that doesn't tell you why you took the photo. It just says, here's the technical aspect of this photo, which okay. That's great to a certain point.

But what if you wanna look back and go, why did I do this? How could I make this better? What was I thinking? None of that is gonna be in that data. Right?

That's why you want these documents or just little notes to yourself, things like that. So that's kind of what I got for you in this one. And I'm I I I get that it seems kinda specific, but, you know, abstract this out to whatever your scenario is. And that is do the boring bit first. Trust me.

You will thank yourself later on. Or maybe on the flip side, maybe you're someone who loves to do that part of it but doesn't care for the, okay, now go make it part. Right? I'm I'm not sure that that's the audience for this, but that happens. If that's the case, you know, hey.

And you you can work with other people, great. Do the bit you love. But if not, you know, do the bit that you feel you don't need because that will be your flag to say, I have not thought this through before I started. And I think all of this will help you complete projects, get to the end of projects, or maybe realize this project is not going in the direction I thought, or somehow I have pivoted and taken this in a direction I didn't mean to. But you need that material to reference.

And like I say, it's very much like a a journal, and it will keep you sane, I think is the word to use. Game development is incredibly hard. Personally, I've said this before, I think game development is far more challenging than making apps, and I make apps professionally every day of the week. And I think that's a lot easier than doing games because there's just things you never like, why would a user do that? Well, they do it because they do.

Right? And things like that. So that's my advice. Right? Take it a bit slower.

Embrace time to think about something. Right? And and and I've been very careful not to say project planning because, gosh, you know, formulate something that's gonna work for you, or you at least have a reference before you dive in, and then later on, live to regret it and start to hate a project because you created a a brick wall for yourself that if you'd have thought for it five minutes before you started, you would have seen this brick wall and dealt with it there and then and not suddenly become totally demoralized and wanna give up halfway through a project, especially if it's just a project for yourself where your brain knows you can walk away from it. Alright? So that's it, folks.

If you have any thoughts on this or you wanna come on the podcast and talk about that, that'd be great. Wanna hear them. Reach out to me. Peter Witham dot com forward slash contact. There's a link in the show notes.

With that, folks, I will speak to you in the next one.