Everyone loves a good side project! It's your chance to actually work with the shiny new technology you've read 12 tutorials about, to add some real code to your resume to show your proficiency with the shiniest new technologies, and re-learn just how difficult it can be to step outside your coding comfort zone.
It's common for coders to have a big barrel full of abandoned side projects. Each one is a milestone in a way. I personally have some concepts I've started from scratch on 3 or 4 times.
Much like the first few levels in World of Warcraft, the first few hours of a new project are full of excitement. Anything involving a package manager gives you those first moments where you watch things fly by in the console and feel like a master hacker as you sip on your beverage of choice. Then you plug in the example code and see it work like it did in the example! Just like that! Wow!
Eventually the joy ride ends as you come to terms with the vast gulf that spans between where your project is now, and its completed state. Invoking the magic words "mimimum viable product" can only do so much to reduce the scope of your dream when you're hoping to do something amazing. The rational part of your brain knows that spending an hour a day on this will get you to the finish line eventually.
That would be all we need for motivation if humans ran entirely on rational thought! Alas, most side projects do eventually fizzle out as we tire of using our spare time to bang our head against the wall in frustration. Even with a mild concussion, the dream that sparked the side project's creation never dies.
When you're ready to dive back into things, it's easy to feel overwhelmed by re-acquainting yourself with your old code. It's like loading up a game you almost beat six months ago and trying to remember what you were supposed to be doing.
How do we make the most of our fizzled-out projects to make the most of these bursts of renewed motivation? Here are a few suggestions from someone who has plenty of stalled projects to experiment with:
Document the heck out of them#
Write up rough design documents. Map out what classes or functions you think you'll need to make things happen. You could even write tests for them that roughly describe how you expect them to work. These don't need to be detailed or fancy - they're just for you.
This does a few things for you:
- Just like in "real" software projects, you'll be able to reconsider architecture and design decisions before you're halfway through implementing your first guess at how things should be. It's so much easier to draw a new diagram than it is to refactor your app from the ground up.
- If (when?) your motivation for working on the project dries up, you can take a break and easily jump back in when you're ready. If you kept track of your progress too, you can just jump back in from where you left off.
- If you want to start from scratch, your planning docs won't be tightly tied to specific code, so you can use a fancy new framework instead of the old framework you were excited about the last time you started things up.
I just did this in the aftermath of my most recent project hiatus. I wrote out a rough outline of the type of data the most complex objects would need to hold onto, some pseudocode for the most complicated functions, and a few basic unit tests. I found that it's easier for me to come up with unit testing ideas on paper than in the IDE - maybe because I don't get hung up on getting the syntax perfect as I'm trying to come up with them. What will you find easier to plan on paper? Only one way to find out!
Use what you've learned for next time#
So... you didn't write up any design documents. That's okay! You moved fast, broke things, and got out of there. We've all done the same. Chances are good that you got stuck on a hard problem. In web development, running into one of those usually means one of three things:
- The real problem is that you don't fully understand what's going on, which makes a small problem seem like a huge problem.
- You're going to learn that someone solved that problem for you in a library - thanks, open source software!
- You are a pioneer staking your claim on something that, truly, no one has done before. If you solve this, you can become the hero in the last scenario.
The first two situations are pretty common, at least in my experience. I've come back to projects before and found that the biggest problems had melted away.
The third scenario is why people say things like "the things worth doing in life are hard." If you run into a truly unique problem and keep puttering away at it, you'll become a master of that problem's domain before you know it.
No matter what stopped you in your tracks, your experience taught you something that no tutorial was going to show you. Maybe you learned the limits of the shiny new technology that looked so effortless in the demos. Maybe you found the edges of a library's helpfulness, or a bug you can report. No matter what happened, you learned something from it, so the next time you start a side project, you'll be that much more knowledgeable about how to make it work.
Like I said before, these are the practices I'm working on for myself in order to make the most of my personal programming time. What do you do to improve your chances of taking a side project to the finish line?