Having worked on a few side-projects, and not having shipped any, I decided to analyze why that is and how to ship my next side-project. The problem for me is that I get excited and start putting in lots of work at the start and slowly get tired and move on to the next interesting idea that I have. Then it eats away at me in the back of my mind, because I wasn't able to finish the project.
With my current project [https://github.com/loaves-and-fishes/community-groups], I decided to change things, because doing the same thing, hoping for different results is literally the definition of insanity. I've had this project idea on my mind for the last several years and it has grown in scope over that time. I hope to ship this project, so I have primarily written this for myself. Having said that, I do hope that it also helps you in your side-project journey.
Do Only One Project If things were going to be different, I'd have to forget about all other projects on my backlog, and be focused on this single project. This means no going after any new shiny ideas, or resurrecting old projects. All other projects are on hold while the current one is active. This will help my mind and my time to be focused.
Make It Manageable My idea started out small, but has grown over the last few years. If I was to tackle that whole idea as my side project, I'd be completely overwhelmed. So instead I've segmented my idea into 3 parts, and chose one of those parts.
Even one of the parts is big enough to overwhelm. Now it's time to trim down and see what is the smallest app that I can ship that would be a useful tool for my audience. This step is important, because products always have more work than you expect.
Keep Experimentation Minimal Every time I start a new project, I want to try some new tech. Usually this keeps compounding because I try to experiment with multiple areas of the app. For example, my main expertise is in Ember.js [https://emberjs.com/], but I wanted to try Polymer for a side project. I realized pretty quickly that I should not experiment at such a big level, because I don't know the tech and will spend more time learning then building my app.
For my current side project, I decided to experiment with functional/utility CSS, i.e. TailwindCSS [https://tailwindcss.com]. This has worked out well so far. It lets me move fast and not have to go all in if I don't want to. Plus the core is still CSS, so I'm not learning something huge.
Gate Keep Scope Creep As I build the app, I will see small issues that could be addressed to help the experience. These small fixes or enhancements will only grow the size of my project, growing the distance from where I am to where I need to be to ship this project. My goal is to ship something, after that I can reevaluate.
For example, while building a members list I saw an opportunity to add a multiple tab UI to help distinguish/filter members that were pending on invitation. This is probably something that will eventually make it in, but at this time it's only distracting from shipping my first version. It's better if the users driver that development, or once the app is established.
Set Personal Checkpoints It's very easy to lose track of when I last worked on my side project, especially I didn't record anything or set any expectations. All of a sudden a year has gone by and I have little to show for it. The first step is to set an internal deadline that I will try to reach. The second step is to split up chunks of work into checkpoints of sorts. With this kind of setup I'll have an end in sight and stepping stones that will help me track your progress.
I'm going to start doing that by using the "Projects" feature in Github. This doesn't introduce any new tools to my workflow, which I think is important to keep the overhead small.
Work In Public When no one knows what I'm up too, it's easy to just give up or move on to the next big thing. Once I'm accountable, things change, because I've involved others. It's a form of internal motivation, as well as external. For programming side-projects this usually starts as working in public with an open repository right from the beginning. I can also choose to share my work on social media (like Twitter) or record/stream videos on services like YouTube or Twitch.
For my project I'm recording videos on YouTube (here [https://www.youtube.com/watch?v=EXvT4bUZqHg&list=PLfQwL10yab39zHh-4Ub-u9IqwS5C0yHsE] ) and posting on Twitter. I also have it public on Github (here [https://github.com/loaves-and-fishes/community-groups]). Beyond that, I also included it in a blog post (this one).
Ship It This might sounds silly, but this is probably the biggest step to have a focused side-project. If I never ship my side-project, then I don't really know if I enjoy the full process. Plus preparing my project for shipping is much more involved then I might realize, and if it's skipped, I miss a big portion of the full process. After shipping, I can decide if the project is finished, or if I want to continue.
If I've been working in public, then I will probably have at least a small audience, and have some potential users. Shipping will bring on new eyes and feedback. Maybe I'll have clients or maybe learn that the project was a good exercise and nothing more. Even if I end it here, I'll have gone to the end, and now have a portfolio item, and the experience that I've gained.
Summarize Your Learnings Now that I've shipped (and maybe iterated a bit more), it is important that I sit down and write my thoughts out regarding this process. What did I enjoy or maybe not like one bit? Were there struggles along the way, what were they? Will I build something like this again? Was it worth it? I should write this down and maybe share it in a blog post (that's up to me). Next time I decide to start a new side-project, or maybe consider investing more time into this one, I'll at least have some idea of what I enjoy building and my strengths and weaknesses. I'll know where to spend more time to improve or what areas to avoid all-together.
By finishing a side-project, I'll grow and learn about myself. But I must also remember, sometimes an idea just doesn't work out or I might learn early on that it's not right for me. In a situation like this, I shouldn't feel guilt/shame for not finishing the project. Make a clear break, write down my learnings, and move on.