I don't identify as a gamer. I occasionally participate in board games or an amateur football match, and I rarely spend time playing computer games. But I used to.
One remnant of that time is Civilization, or its open-source spin-off, FreeCiv, which you can also play online for free. I already tried and failed to use the FreeCiv game engine to illustrate the concept of Astro's Islands Architecture.
I then used AI for my React recap post last year, to generate a pseudo drawing inspired by my civilization idea and the visual style of my hand-written sketches.
Here is another illustration that looks much more like the actual game.
What made me want to write another article is yet another aspect of that game: the technology tree.
Remotely inspired by historic civilizations, there are different alternative and interdependent paths of technical progress. Achieved by active research, via the Great Library, by conquering more sophisticated contenders or creating alliances.
The Technology Tree and its False Promises
Those achievements promise to give you an advantage, but using them can actually hinder your progress, especially when wasting resources striving for disadvantageous achievements, even more so as technology becomes obsolete by newer alternatives.
Developers know that feeling from software engineering, legacy code maintenance and education.
Trade-Offs
We need to make decisions and compromise and decide where to steer our limited resources and efforts like time, money and mental capacity.
AI makes some things easier, while others get harder. AI is one of those technologies that many might wish we hadn't invented at all. But we had for fear of missing out and falling behind.
FOMO and Sunk Cost Fallacies
While we can't turn back time, we can still change our goals and adapt our strategies. Unlike the sunk cost fallacy feeling that previous effort is lost, it isn't.
Learning and problem-solving always have an intrinsic value, training our mind. Even if we just wasted time and effort learning the wrong (spoken or programming) language or an outdated software framework, we have still practiced. And many concepts remain the same throughout information technology, design and marketing.
Repurposing
Much like in the civ game, we should constantly question and adjust our (tech) goals and priorities, like abandoning a started project and repurposing the allocated invested effort into building something similar. In the game, you can just switch from building one world wonder like The Pyramids and repurpose previous investment taken into account for starting to build The Great Library. It's not that easy in real life, but still those can be mental models that help.
Dealing with scarcity is one crucial aspect of those kinds of civilization-building games, while in real life, we tend to deceive ourselves, acting like we have infinite time. Then we're getting hectical, distracted and frustrated, or ideally at least hyper-focused, when a deadline's near.
Productive Procrastination
Procrastination becomes dangerous when it prevents us from starting or finishing what we intended to do. Starting is especially important because it quickly dispels illusions. Once you begin, you discover what actually works, where the difficulties are, and what mistakes you've made in your assumptions. You can also identify problems that require external support. For example, if you don't have permission to access a required file, asking for access too late can cost valuable time and jeopardize the entire project.
Definition of Done
Often, we think we're finished too early. While the 80/20 principle can help prevent perfectionism, the opposite trap is stopping before the work is truly complete.
Implementation is more than simply building something. It includes testing, deployment, communication, and verification that the intended outcome has been achieved. Depending on the context, "done" may mean that the feature is live, the document has been delivered, the client has approved the work, the message has been received, or the invoice has been paid.
Choose a clear definition of done before you begin. Otherwise, you risk mistaking activity for progress and completion for success.
Top comments (8)
This is the way! This teaches way more than hitting tab or prompting or whatever it's the trendy thing today.
IT objectives must, above all, be:
Gotta keep your project goal clear and measurable — otherwise you're just building tech tree nodes nobody needs.
Make it realistic, too; no point chasing pyramids when you don't even have the wheel yet.
And actually execute it — a "definition of done" beats a daydream every time.
One big milestone and little pebbles in between. Imagine that life is a river, and at the end, you have to cross that river using those very stones :-)
The tech tree analogy is spot on, in dev we do the same thing, over-investing in a path just because we've already started down it. The reframe that practice itself has value regardless of the specific technology is genuinely useful.
The procrastination point is underrated too. Starting early enough to discover what you don't know yet, missing permissions, blocked dependencies — is advice I wish I'd internalized sooner.
Here are some things:
This resonates Gaming taught me something that school never did failure is just data, not judgment In a game, you die, you restart you try a different approach No one shames you for losing. You just learn and move.
Programming felt the same way when I started bugs were puzzles, not failures. Somewhere along the way deadlines and expectations changed that. Reading this reminded me that the gaming mindset is still there. I just stopped using it.
What's one lesson from gaming that's made you a better developer? 🙌
The repurposing point is the most useful part. In Civ you switch from Pyramids to Great Library and keep the production. In real engineering, you abandon a half-built service and what actually transfers is the team's understanding of the problem domain. The code is sunk cost. The learning isn't.
Too many people celebrate finishing the work when they should be measuring whether the goal was actually achieved. Real execution is not about building, writing, or delivering—it's about ensuring the intended outcome becomes reality. The job is not done when your effort ends; it is done when the result is verified, accepted, and creating the value it was meant to create. Success belongs to those who follow through to the finish line, not those who stop at the first sign of progress.
I updated this post after I discovered that I hadn't actually finished and fixed typos and partially German notes within English sentence fragments. Thanks for reading and liking nevertheless already!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.