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.