Back in 2009, I wanted to build a web-based strategy game. I had a vision of a sci-fi universe where players could colonize planets, extract resources, build fleets, and wage interstellar war.
At the time I was working as a developer at a Drupal-focused agency, all-in on the Drupal ecosystem. So I decided to build the game on top of Drupal.
It made total sense to me. Planets, fleets, and alliances could all be represented as content types. Resources could be user properties. The solar system and battle visualizations could be rendered with Views. The game logic could live in custom modules.
What I’ve learned since then is that just because something could be done a certain way, doesn’t mean it should be.
What I would do today
Seventeen years richer, with plenty more tools in my toolbox, I would do things very differently if I wanted to create a web-based strategy game now.
I would probably build a core of game logic in Go, with a hexagonal architecture so the core would be easy to test; ports and adapters for the database and everything else living on the outside. On top of that, an API for clients to talk to. Then a first frontend in React, with the door held open to swap it for something else in the future, like a mobile app.
That sounds more complicated, and it is. But I’d bet a lot of money it would have been faster to get a first working version out the door, and it would definitely have been easier to maintain and evolve the game over time.
Drupal is still part of my toolbox today. There’s nothing wrong with it — it’s a tool best suited for some kinds of projects and not for others. The problem was never Drupal itself. The problem was that my toolbox held exactly one tool, so that’s the tool I used for everything, even when it was the wrong one for building a sci-fi game.
The hammer you can’t see
All of this is obvious to me now. What’s interesting is that it wasn’t obvious to me then, and that I see developers today making the same mistake I made. Not because they’re bad developers, but because they simply don’t yet have the experience and the tools in their toolbox to make a more informed choice.
You know the classic saying: if all you have is a hammer, everything looks like a nail.
The really interesting problem is this: if all you have is a hammer, it’s very hard to recognize that all you have is a hammer, and to realize that there are other tools out there better suited to some of your problems.
The Drupal game is just one of many examples where I’ve since realized I picked a tool that wasn’t right for the job, without even being aware that better-suited alternatives existed or considered that possibility.
The conclusion, then, is that we’re probably hammering away in many parts of our lives, completely oblivious to the fact that we’d be better off switching to a screwdriver, or a saw, or a drill, or whatever tool actually fits the task.
Expanding the toolbox
It’s very important, however, that we don’t let that conclusion paralyze us. We can’t stop everything and wait until we’ve gathered more experience and more tools, because then nothing would get done and we’d miss too many opportunities.
Which leaves only one reasonable way forward: work with the tools we have, while constantly, systematically, and deliberately expanding our toolboxes. Keep challenging our own decisions and choices, so that the next choice is a little more informed than the last.
How do we do that?
I personally like to build my toolbox by reading books and articles. Another powerful way is talking to and learning from others: going to conferences, meeting over a cup of coffee, joining a meetup, or simply talking with colleagues at work.
Just remember to experiment also — that’s how knowledge turns into skill.