What to do is harder than how to do

As a developer, I am constantly facing problems of all kinds. Learn a new framework or language. Decipher business logic from uncommented code. Encipher business logic into totally-readable doesn't-need-a-comment code. And I overcome them every day.

But the problem I have yet to find a solution to is the Problem of Problems.

What Should I be Doing?

Behind me is a long line of partially-finished projects, and those are just the most recent ones I can link to. From speaking to other developers, this isn't an uncommon thing, and, as I am designed to do, I have been pondering the common thread between them in hopes of possibly diagnosing the issue and submitting a ticket.

And the common thread that, when pulled, unravelled the tapestry, is that while I am well versed in solving problems, identifying problems and presenting them to be solved is an art form I am much less skilled in.

A Practical Example

My most recent shelved-project, a first-person RPG thing in es6, came into being when a few specific inspirations came together. At work, another team started using Babel/es6/7-stuff on an open-source project that piqued my interest in using those languages myself. I had tinkered with WebGL a few times before, and I was really hankering for some game development, as I'd let it slip through the cracks for far too long. And, I had just finished playing an Android game that I found surprisingly enjoyable, and I wanted to explore the design space of that genre myself. It all came together into a working, nearly-finished project.. and then it didn't.

When'd I stop? Right after all of the identifiable features for a game were implemented, but before a game was done. Right after all of the emergent problems were solved, but before it was finished.

My problem was that I ran out of problems.

The next step in the game would surely be to decide on some mechanics, make up a story, get the graphics together, and bang the thing out. It would take months, sure, at the schedule I have to work on it, but it would happen. But.. gosh, that's such a big, blank canvas to work on..and I want to work, but..on what?

The Answer

I've seen people approach this problem in multiple ways. For some, the answer is to work on reimplemented things that already exist so that the set of requirements are laid out for you from the get-go, and this issue never has a chance to arise. For others, it's taking on contract work to feed the developer without staring down existential walls - although those can fall into the same trap when the client doesn't have solid requirements.

I think, though, that like most of life, it's more about other people than it is yourself. Approaching a vast emptiness of possibility alone is intimidating, horrifying really, but with someone else, maybe even a team, on your side, it is very approachable. A friend of mine has been working on an interesting game for at least a year now, and regularly keeps me and others up to date on it, I'm sure as a way to keep himself motivated. I think involving others is the right path toward success, and while it gives up some of the freedom of going in alone, I think in the end it will result in more completed projects and less half-finished heaps of code on the shelf collecting dust.

It's not a solid answer, but it's a direction to search. So if you're interested, you know how to reach me.


Recent Activity: