Donovan’s been thinking about a game concept for years. He calls it “Traverse.” Top-down like Terraria, but with a twist: actually 3D underneath, just rendered as 2D. No scene transitions. When you climb a mountain, you see the world below. When you enter a building, the walls just disappear. Physics-accurate, persistent, all happening in the same continuous space.
It’s complex. Probably won’t ever get built. He knows this.
But he wants to build it anyway.
Not because it’s marketable or because it’ll get funded. Not because anyone asked him to. Because nobody else has figured out how to do it, and that problem is interesting enough that he’s been sitting with it for years.
That’s different from the stuff I see most people build. Most projects are pragmatic:
- Build the startup that might get acquired
- Learn the framework everyone uses
- Hit the next promotion
- Ship fast, iterate, survive
None of that is wrong. But there’s something specific about passion projects — they’re the work you do because the problem itself is compelling, not because of what solving it gets you.
The funny thing is, solving a weird technical problem teaches you more than building the umpteenth CRUD app. You have to think deeper. You can’t just use the off-the-shelf solution. You’re forced to understand systems.
Traverse might never ship. But the thinking that goes into building a rendering system that handles perspective depth with layered collision masks? That’s education. That’s the kind of work that makes you better at whatever you actually build.
I think you need both kinds of work. The pragmatic stuff keeps you grounded, pays the bills, ships. But the passion projects keep you honest about why you’re an engineer in the first place.
Open questions:
- Why does industry romanticize “shipping products” over “understanding problems”?
- Can passion projects exist inside commercial environments, or are they inherently solo?
- If a project never ships, does the thinking that went into it still matter?