I’ve never really been great at side questing in video games.
In most games I play, I tend to lock in on the main storyline. The objective is clear, the path is defined, and progress feels measurable. Side quests exist but they get pushed off with the assumption that I’ll come back to them later.
However, more recently, I’ve started to notice the downside of that approach. By the time I reach the end of a game, the momentum is gone. The drive to revisit old areas, retrace steps, and complete scattered objectives just isn’t there. What’s left is a version of the experience that feels… incomplete. Not broken, but missing depth that was available the entire time.
The “Side Quest” Pattern in Software
That same pattern shows up in software development– while working through a feature, there are always small opportunities for improvement tucked alongside the main task. A function that could be refactored; a test that could be tightened up; a naming convention that doesn’t quite fit the rest of the system.
Individually, none of these will block progress. So they get deferred.
Some time ago, I was reviewing a code change for a teammate, and, in their description of their changes, they had a section labeled “side quests”. And although this was most likely meant as just a light-hearted word choice, it really resonated with me. Instead of treating these items as loose ends or cleanup tasks, they could instead be treated as side quests—small, optional improvements that exist alongside the main objective but still contribute to the overall quality of the system.
Why Side Quests Carry Weight
In games, side quests aren’t just filler content. They add context, introduce mechanics, and expand the world in ways the main storyline often can’t. They also tend to make the primary objectives easier by building up experience and familiarity over time.
The same can be seen in software: those small improvements force a deeper understanding of the codebase. They expose patterns, inconsistencies, and edge cases earlier in the process. Over time, they shape a system that’s easier to navigate and extend.
When They Pile Up
In games, uncompleted side quests tend to lose their appeal once the main story wraps up. They become disconnected from the experience that made them interesting in the first place.
In software, this shows up as technical debt. A handful of deferred refactors, or a few small fixes, don’t seem like much in the moment, but over the lifespan of a project, those decisions accumulate. Eventually, the system becomes harder to work in, not because of any single issue, but because of the volume of small ones left behind.
Unlike a finished game, this backlog doesn’t stay optional.
Doing the Work While You’re There
The biggest shift for me has been recognizing that these “side quests” are most valuable when handled in context.
When you’re already working in a part of the codebase, the mental overhead is low. The surrounding knowledge is fresh. Making a small improvement in that moment is significantly cheaper than revisiting it later.
This idea shows up in other parts of development, too. Small, structured improvements—whether in code or documentation—tend to be more effective when built incrementally, rather than deferred and tackled at once.
A More Complete System
Reframing these tasks as side quests has changed how I approach them. They’re no longer distractions from the “real work,” but part of the same system of progress.
Not every opportunity needs to be taken immediately. But consistently ignoring them leads to a familiar outcome: a project that technically works, but lacks the cohesion and clarity it could have had.
The same way skipping side quests leads to a thinner game experience, skipping small improvements leads to a thinner codebase.