Your project, your rules

If I had a nickel for every time I searched through Reddit for the “best web framework” or the “best game engine”, or even comparing two very similar technologies for a head to head “winner takes all” type lecture… well, I don’t want to count them.

I’m willing to admit I used to spend too much time on that, and honestly I don’t blame anyone else for doing that too. Don’t get me wrong, searching for what tools are best at a certain thing you want is impossible to avoid, but those “Rails vs Django” debates are utterly useless to newcomers looking for an idea of what they should learn. Don’t believe me? Just hear me out.

This post isn’t just for newcomers - it’s for anyone working on their own project or learning. From those who’ve been drowned in Reddit posts too long, to those who barely know what HTML even is, I think you’ll gain something from this. It’s been hard for me to let go of any idea that one tool is simply better than another, and I know you probably would too. That’s why I’ve learned to embody a philosophy that I feel anyone on the internet should know: Your project, your rules.

The best advice?

This isn’t my own original idea, of course. I can’t even begin to figure out who coined it first, or if any one person deserves credit here, but it was something I heard around the internet randomly. It started as an occasional Redditer responding to a post asking for what tech stack their Discord clone should use with something like “Who cares? Use whatever you want.” No, that didn’t happen word for word, but you probably get what I mean.

At first glance, you might see this as unhelpful to newcomers. For people who already know how to code and could build this in one language or another, it could work. But for the people who are just starting out in this field, with not much insight on frameworks and good practices? It sounded utterly useless to me. Boy, was I naive.

Sure, having a clean cut answer is always nice - but you have to learn that there isn’t always one way to do it in programming (Sorry Rails, it’s just the truth). What I didn’t realize at the time was these people were hinting at arguably the best kind of advice: They were telling them to not pick something just because someone on Reddit said so. Or, for that matter, anyone on any website.

Most people don’t care if you pick what they said made sense, they were just there to share what they use. But it’s easy to just think “Ah, the most upvoted answer is (insert tool name here), I better use that!” and run with it. Never do that. Instead, compile a list of all the tools you could use for a project, and then research what each engine has it’s strengths in. Gather intel, lay it all out to see, and then start ruling stuff out.

Like the advice implies: It’s your project, so why should someone else tell you what you should make it in?

Everything has it’s place… usually

Every language and tool has it’s strengths and weaknesses, and there’s no perfect screwdriver to use on the nail. Each of your options could get the job done, but they’ll take slightly different routes to do so. Loads of people will tell you you’re “overcomplicating it” by “writing it all in Rust” - and yeah, they’re not exactly wrong, but that doesn’t make it pointless to do so.

Let me give you an example: Static site generators are used to make website development fast and simple - from supporting Markdown files by default (instead of just HTML), to letting you use a JavaScript framework without the hassel of a big project setup. As you can imagine, tons of these exist, and are all written in a variety of different languages. To name some:

Though most of the popular ones are written in JavaScript (or TypeScript), many others aren’t - why? Because not everyone wants to use JavaScript for it. Plenty of other languages can make it happen, and if it’s open source than you have people who also use that language wanting to help. It can also lead to optimization, especially in cases with Go and Rust, where speed is always better than in most languages. Never count something out until you know it cannot be used for the project.

Work stuff is one thing

If you do programming professionally - specifically, working for someone else - you likely use set technologies at work and it’s not very flexible. You like Vue over React? Well, not everyone wants to recode the UI, so you’re stuck with React. But that doesn’t mean you have to use it in your personal projects too. Sure, it simplifies a lot, because it means you can get better at React and therefore thrive more at work (I can’t blame you for taking that route either). But if you’re really not a fan of React, what’s stopping you from using Vue for your own personal website? Or maybe that Discord clone I mentioned earlier? The answer is: Nothing. Stick to those popular tools when you’re trying to get hired, and then afterwards continue your learning with whatever you find interesting next.

Learn to walk before you run

All of this talk has been great, but I admit I may have taken too long to establish one important thing - if you’re new to this, don’t overwhelm yourself. Look, I get it, you have that killer game idea and just need to make it. Having no programming knowledge doesn’t automatically make it a bad idea to open up a new project in whatever engine you chose and start working. Just remember that being overwhelmed by it is totally normal. Advice on learning to code is as diverse as the programming languages themselves - I could go on a whole rant on a “better” way to learn programming (upcoming post perhaps?), but that’s not for today.

For now, just give stuff a try. Don’t be afraid to try out that big beefy engine for your first game, and likewise, don’t be afraid to use that small, less popular engine to make it. As long as it works, it works. I will say starting small is always better though, and putting those big, scary, yet insanely powerful tools on a shelf for now is encouraged. You’ll get there eventually, just don’t give up.