The Software Engineer’s Epic Career Adventure

Posted on In Views:

This is the career talk I often give to teammates — how we grow, prepare, and level up like in an MMORPG.

In my previous article, Why So Few Qualified Architects, I talked about how success often hinges more on luck than on hard work. But I also argued that effort still matters — because when luck does arrive, we need to be ready to catch it.

This new post is something I often share with my team at the end of a project cycle. It’s about how we, as software engineers, can grow and prepare ourselves for those rare moments — those windows when the opportunity to get promoted actually opens.

I recently created a slide deck around this topic, which is available here:

Software Engineer Career Presentation

Now let’s talk through it with a bit more fun — imagine your career as a classic MMORPG.

Novice

When we first enter the industry — fresh from school, or after a career change — we become junior engineers. In RPG terms, we’re just starting out as adventurers in the beginner village. There’s not a lot we can do at this point, but everything we do brings back noticeable experience. It’s the fastest growth phase in our career.

Our daily routine? Fighting slimes, collecting herbs, and doing quests. In real life, this might mean writing basic features, fixing bugs, or learning how version control works.

Some engineers choose to stay at this stage — and that’s totally valid. The tasks are familiar, the pay is decent, and the return on investment is high. Once we reach a certain level, slaying slimes doesn’t take much mental energy at all.

But if we want to go beyond this comfort zone and reach the next stage, we’ll need to think about class-changing.

Just like in a proper RPG, we don’t get to become a Mage by slaying slimes forever. At some point, we have to:

  1. Equip better gear — like a Mithril Staff
  2. Learn real spells — maybe Fireball or Chain Lightning
  3. Improve our playstyle — hit, run, combine abilities

And in engineering, we do something similar.

We begin to explore new domains, learn new paradigms, and get comfortable with complexity. We realize that doing what we’re already good at — over and over — won’t carry us further. That’s when we make the decision to grow.

That’s when we start preparing to class-change into a Mage.

Mage

At this stage, we start making deliberate investments into our toolkit and thinking. We might buy books (gear), attend workshops, or practice our skills after hours. It’s where we shift from being reactive to becoming intentional learners.

We study software engineering fundamentals, database design (SQL/NoSQL), refactoring, design patterns, and other best practices. In reality, a lot of this stuff doesn’t show up in our backlog. Especially not in smaller teams, where we’re always shipping and rarely have the luxury to explore architecture or scalability problems.

So we end up doing the real leveling after hours — reading random tech blogs we bookmarked months ago, joining meetups even when we’re exhausted, poking around open-source codebases just to see how others think.

Once in a while, something we saw out there clicks. We bring it back to work, try it in our codebase, maybe even propose a small shift in how our team does things. If we saw an interesting caching pattern in a talk, we experiment with it in our own stack. These small experiments help us build impact and credibility.

When those moments accumulate, the chance for a promotion often appears. That’s when we “class-change” into a Mage — an engineer who not only builds but also drives improvements.

At the same time, many people pause here too — and that’s okay. Often this is the stage when life outside work demands more attention: marriage, kids, health, responsibility. If we’re no longer able to keep investing in growth at the same pace, that’s simply a trade-off.

But if we decide to push forward, we’ll need to aim at the two endgame classes: Archmage or Grand Sage.

Grand Sage / Archmage

Mages can handle mid-bosses solo — giant spiders, cave trolls, chaotic outages. We learn to kite, stun, AOE, and recover on the fly. With the right spells and tools, we hold our ground.

But eventually, we set our eyes on a world boss. An Ancient Dragon.

These aren’t fights we solo. Now we’re in raid mode.

We start thinking like a strategist:

  • Who’s tanking the critical path?
  • Who’s buffing the deployment pipeline?
  • Who has aggro on leadership expectations?

We prepare mana potions (resources), stack buffs (team rituals), and fine-tune our battle plan (roadmaps, RFCs, OKRs). We aren’t just casting spells — we’re orchestrating the whole raid party.

This is the shift into senior IC roles:

  • Staff Engineer
  • Principal Engineer
  • System Architect

Our job isn’t just to solve problems. It’s to see problems before they exist, to align teams, and to guide the group through the dungeon, even if we’re not the party leader.

But just like endgame raids, this tier is hard.
 Progress is slow.
 Feedback is vague.
 And the gear we need often doesn’t drop on the first clear.

So we keep reading papers. We explore other guilds. We grow our technical judgment. And when the next window for promotion appears — we’re already buffed, geared, and ready to go.

Wrap Up

This is what I often remind myself — and my team:

Just shipping features has no value.
 No value means no XP.
 No XP means no level-ups, no class changes, and no promotions.

It’s just like in an RPG:
 We don’t beat an ancient dragon by slaying slimes for a decade.

That’s how we grow. Not by repeating the same dungeon, but by stepping into areas we don’t fully understand. Sometimes that means fighting monsters we’ve never seen — and yes, sometimes we wipe. But we respawn smarter. Sometimes it means leading the raid.

But most of all, it means preparing for that one window — when luck shows up.

And when it does, we better be ready to roll.

Originally published on Medium