Enthusiasm is a resource

Programming ?? Comments Tue 25 June 2013

I've been reading a lot of Coding horror and Joel on Software recently. I was reading this article and it got my thinking about motivation and enthusiasm. When you, or a team, are working on a project you must budget for enthusiasm. Drive might be a better word but the word you use is ultimately unimportant. What is important is that if you are a creator of some kind (be it programming, writing, carpentry, etc.) then you must realize what your limitations are and that drive is a limited resource.

In the last five years I have started many more projects then I have actually finished and sent out into the world yonder. My bitbucket, google drive, and gmail account are graveyards for half-baked concoctions. Someday I’ll be taken before the International Code Council for idea genocide. These projects aren’t even in a finished enough state that I can use them as a learning experience. They’ve been left malnourished and forgotten.

I’ve been making things for a while now (programs, websites, dance classes, plastic armor, headphone modifications) and I’ve run into this problem a lot. I start working on something, get half-way through it, and never finish the project. It wasn’t until I read a blog post talking about creating a game in a week or less that I realized what my problem was--or that I even had a problem.

“If your motivation is rocket-high when you start the project, but dies off in 3-4 weeks, then you can only tackle games that can be done in that timeframe!“

This quote finally forced my goat of a brain to understand most of the projects I’ve been starting and stopping are simply too large for me. I’ve been telling people “don’t bite off more than you can chew” since my first day as a tutor. My glass house was so close to my face I’m surprised I didn’t touch it.

That said, now that I’ve come to this epiphany, what am I going to do with it? This is the part where I don’t follow through and correct my hypocrisy, right? Luckily I’m a bad politician, so I can acknowledge a problem and actually try to fix it.

The most effective things I’ve done so far are to experiment with self-imposed deadlines on my projects and to match up project types to my findings. It’s not enough to have a minimum project estimate, you must have a project cap as well. I’ve also just started to accept that the really great projects get more of my time. I feel less bad about starting something and leaving it to die, it’s just a thing you need to do in order to feed the beast.

For example, my deadline for writing this article was four hours. My next article is probably going to have a three hour deadline. When it comes to writing I seem to have a max of 3-4 hours that I can spend on something before I lose interest and when I have an idea I need to write about it the same day that I get the idea. I’m the equivalent of a writing goldfish.

I can be much more lax with programming projects then writing projects. I’d been thinking about making a resume website for half a year before I actually got around to doing it. Another coding project involves a screen filter that takes all the current onscreen colors and changes them to look like what a color-blind individual sees. My hope is to take this program and make a website that takes a URL as input and outputs what the given website looks like to a color blind individual. I’ve been working on this filter for about 40 hours now which is much longer than any of my writing projects. This is more in line with my standard goat-like tendencies.

Another useful change has been compartmentalizing projects. I’ve been breaking larger projects into smaller beasts and hunting them down. In algorithm analysis classes one of the first things you drink from the fire hose is the concept of divide and conquer. Invaluable for a programmer but the bugger is damn useful for general use cases.

For example, on my resume website I have a bunch of URLs which all lead to different pages. Rather than thinking about working on the entire website, I’ve started working on individual sub-pages. I’ve also been using websites like trello and pivotal tracker to break projects up into manageable chunks.

This applies to more than just tech projects. I’ve found this to work on physical objects. The most recent case is a redesign of my aluminum kite shield. The components were: strip handle, strip siding, remove paint, cut size down, attach new handle, attach new sidings. This helped in two ways. The first is that I no longer saw the project as one giant monolith that required an entire weekend to finish. I knew I could do a section in manageable chunks. The second way this helped out is that I now have evidence of a forgotten step next time I have to do something like this (paint the shield).

For me personally, this change in perspective has made me immensely more productive in the last two months.

Tags: Programming PeopleManagement