Finish It.

I was recently talking to a friend and former colleague about work feedback, and the most important piece of advice I could think of was to be a finisher. It's easy to start things, and also really easy to get things to a certain point. This is why R&D-type work is kind of fun - you figure what's possible and give it a boost and then start something else, but at some point there is a finish line, and to be effective you have to cross it. In the case of R&D, perhaps to finish you have to write a feasibility study, or present findings on the topic - without that, you just have a half-finished something that nobody really knows how to use.

The world of software is littered with half-finished things. Programs that were the result of a good idea or a real business need, but that end up languishing in the sad limbo of incompleteness. Incompleteness has many forms. As it relates to software, it could be in any state (not fully coded, not tested, not documented, not turned over, not marketed) that means that it can't be used to its full potential. I am no stranger to unfinished stuff. Somewhere out there on the web, there is a Subversion repository with a bunch of code, mostly written by me, that does a little bit of stuff, but not nearly enough to be a product. It's unfinished, and essentially useless, and represents a bunch of wasted time. When I left Blackboard, I was struggling to hand over four separate unfinished projects to different members of the development team. Each could have been useful had I finished them, but when explaining them half-finished people really didn't get it or see what its potential really was.

We are only given 168 hours per week on this planet, of which we have to sleep for almost one third. That leaves us with 110-120 hours. Now you take away mundane stuff like commuting, eating, getting dressed, etc, and you are down to about 80 hours or so. You have 80 hours every week to finish things. It's not a lot of time, and you have to use it pretty wisely if you are going to be even remotely effective.

This seems like it's pretty tough from some folks standpoint, but compare it to something like a an auto mechanic. I was rear-ended two days before Christmas, and while fortunately everyone involved was unhurt, my car's rear-end took a bit of a beating. I dropped the car off at the body shop today to be repaired. Imagine that I was called by the shop, notifiying me that the car is finished, then going to the body shop only to find that you only have half a bumper. Would that inspire you to recommend that shop to someone you knew who needed auto repair? That auto shop would go out of business because nobody would hire them to fix a car. Similarly, if you as a developer can't demonstrate a finished product to their manager, or to a prospective employer, why should he or she give you a raise, or believe that you are capable of doing anything good for them in the future?

Finishing is also important to your confidence as a developer. If you have taken something from start to finish, you know that you can do that. That's no small feat. Like I said, there are many unfinished works out there. That's a lot of stuff that hasn't been done. You will learn all the things there to learn in the home stretch - things you would never learn unless you tread in that area. You learn about how to verify the quality of something, about how to ensure that a user can use what you have built, how to document what you have built so that you can explain it to someone who uses it, or better yet, how it can explain itself. You may even learn how to 'sell' it - to convince others that it is worth using, and to get them to adopt it. These are things you can never learn in full by going half way, or even three quarters.

Working at a small company has taught me to finish. I am certainly no expert, but I have become much better at it, because if I don't finish, nobody else is going to finish it for me, and we can't afford not to finish things with such a small team. 2009 is a year where I hope to do a lot more finishing at work and on my personal endeavors.