Finishing Projects is Hard
Finishing side projects is hard. Actually, completing anything is hard, not only software. But I'll focus on the software case; otherwise, this post would be long enough to be published as a self help book, and I probably wouldn't finish that.
This spring, as summer crept towards me (or perhaps I towards it), I envisioned reclaiming all of the free coding time that I've relished during previous summers. Time that I have previously used to tackle tutorials, build my first iPhone game, try out new frameworks, and learn unusual languages, all without the nasty obligation of homework. Summer is marvelous.
But as I took a second, closer look at my imminent freedom, I realized that this summer would necessarily be different. All of the exciting projects that I worked on this school year, last summer, even the one before; well, not all of those projects are finished. Even worse, some of them need to be. And to top it all off, most of them aren't exciting to me anymore.
Somewhere in this fog of doom and gloom, there lies a new skill for me to acquire: The focus to finish a side project.
This is no easy feat. Tying your half finished, hacked together, once exciting monthlong project up with a complete feature set and pretty bow (aka README.md) can be agonizing. All that refactoring, and incessant, prescribed bug testing... the horror! And just to release a few thousand lines of code? No thanks.
Nothing in the world is worth having or worth doing unless it means effort, pain, difficulty... I have never in my life envied a human being who led an easy life. I have envied a great many people who led difficult lives and led them well.
Theodore Roosevelt
Teddy isn't my favorite historical character, but in this case, he's right. Leaving unfinished projects lying around is accepting defeat.
A few of my own projects that are still lying around: Sudz, the aforementioned iPhone game from last summer... not released; Attrition, the previously blogged about machine learning project... not learning yet; the shell I wrote in Haskell... buggy and disorganized; Dockerizing the VandyApps forum... you get the picture.
And there are so many more areas outside of personal projects that I wish I had made more progress on. From Project Euler to SmashTheStack, all of these little ventures into massive time commitments give me the ghastly feeling that I haven't finished anything in the last year.
But here's what I realized.
Nothing is wrong with leaving some things incomplete.
Imagine for a moment that I set out to finish every ideated feature of each of the aforementioned projects, ventured through even a quarter of Project Euler, and hacked into every level of only the IO portion of SmashTheStack. A liberal estimate would guage that undertaking at a year of unadulterated work - the pessimist would prescribe more.
And guess what? I wouldn't have any fun in my free time. That is a no-good solution.
With that synopsis in mind, it's tempting to abandon all of my projects and relieve myself of the stress of so many unfinished ideas. Start anew. Seek new ventures.
Wrong.
The lesson of summer 2015 is a compromise: Some projects are worth finishing outright, some must be set aside in their current state, and for most, I must settle on finishing a project with drastically reduced scope.
In the first category falls Sudz, the iPhone game. I made a commitment to finish the game, with all of its features, and I will stick to that commitment. It will be tough to finish, but it will be finished. Similarly with the VandyApps forum.
In the second group is all of those little ideas I've spent a day or two on, but never completely hammered out. Project Euler and SmashTheStack are in this category for the moment. I will return to them at some point. Maybe on a lazy Sunday like this one, but I must accept that they will likely never be finished.
Most everything else exists in the third category. In fact, most side projects for all programmers begin must eventually fall into this category. Demanding that every ideated feature be included in the final release is a recipe for disaster. Isn't it ironic that in a business setting, we programmers we are often the first ones to carefully restrict the scope of a project; yet, in our own creative work, we easily fall for the same ruse? Perhaps we should take some of our own advice and be more careful with our commitments.
This summer is going to be a summer for finishing things - just not everything. Some projects will be nicely wrapped up to be shown off on Github, while others will lie in waste, never to be seen again. Fortunately, only I know what was released and what was left behind.