You sit down to finish a feature. An hour later, you are tweaking a physics system. By evening, you have a character moving around a test level. The feature has not moved.
It is easy to call this procrastination. Sometimes it is. But there is another explanation. Game development gives developers something product work often lacks: clear ownership, quick feedback, and a problem they can shape themselves.
Now compare that with: “Make the player jump.” You write the first version, run the game, and see the result. The jump is too high? Change one value. Too slow? Try another. Five minutes later, you have something tangible. That immediate interaction is part of what makes digital play compelling. When you want to play, you Click Here For play.
The Work You Avoid Is Not Always the Hardest
Developers do not respond to every task in the same way. A 2022 study, Like, dislike, or just do it? How developers approach software development tasks, examined interviews with 32 software developers. The researchers found that task perception depends on personal preferences, technical conditions, organisational context, and how work is structured.
That explains a familiar situation. A developer may happily spend Saturday solving a difficult programming problem, then postpone a seemingly simple ticket on Monday.
Take a ticket that says: “Add data export.”. You might spend the first hour asking:
- Who can export the data?
- Which fields belong in the file?
- What format should it use?
- What happens with a million rows?
The code may be straightforward. The uncertainty is not.
An industrial study analysed 1,000 hours of activity from six developers and found that executing the system after code changes was a recurring part of development. Developers needed to see how their changes affected behaviour.
Games make that feedback especially obvious.
Autonomy Changes Everything
There is another difference: who decides what happens next. A product feature usually arrives with a purpose, priority, deadline, and acceptance criteria. A personal game reverses that relationship.
You decide whether the character needs better movement. You choose the architecture. You decide whether the next experiment takes twenty minutes or two days.
Imagine a developer working on an internal dashboard. The ticket is vague, the existing code is messy, and stakeholders disagree about the expected result. Instead of untangling it, the developer starts experimenting with an ECS architecture in a small game.
The ECS work may be genuinely useful. But ask:
Why does this problem feel easier to start than the problem on the ticket?
When the Side Quest Takes Over
The most dangerous developer procrastination can look exactly like engineering. You start building a game. Then you decide it needs a better engine. The engine needs an editor. Soon, you are designing infrastructure for a game that barely exists.
This is yak shaving, a software development pattern in which one technical task leads to another until the original objective disappears.
Developer Evan Ovadia experienced an extreme version. He started with a game, then built a custom engine and eventually Vale, his own programming language. The process lasted about eight years. By the end, he had about 6,000 lines of Vale code for the game. Ovadia estimated that focusing directly on games could have produced three or four games instead.
His work was not necessarily wasted. He was genuinely interested in the language and created something valuable. That is what makes yak shaving difficult to spot. Every individual step can be technically legitimate.
Building Games Can Still Be the Right Choice
Game development is not automatically wasted time. It can provide practice with systems design, graphics, physics, networking, optimisation, and tooling.
Game Software Engineering is also an established research area. A 2024 systematic literature review examined 98 studies covering software engineering for industry-scale computer games.
The useful questions are:
- Am I deliberately learning, or avoiding something?
- Does this project have a defined outcome?
- Would I still choose it if the feature were finished?
If the answers are clear, keep building.
If they are not, the side project may be an escape from work that feels ambiguous or difficult to own.
Make Important Work More Visible
Large features become easier to engage with when progress is visible. Break “build the reporting system” into smaller outcomes. Get the first API response working. Render it. Add one filter. Test a realistic dataset. Each step gives you something concrete to inspect, shortening the distance between writing code and seeing evidence that it works.
The warning sign is not that you are having fun while programming. It is that the work you enjoy has a clear feedback loop, while the work you avoid has an unclear finish line. You do not have to stop building games. Just notice what the game gives you that the feature does not, and try to bring more of that into the work that actually needs to ship.
Comments
Loading comments…