Weekend projects are a common occurrence amongst corporate programmers. These (often) nocturnal endeavors give us a chance to learn new languages as well as develop thingFinishing what you started: Completing (and Releasing) Those weekend projectss that aren’t otherwise “work approved. Unfortunately, despite a copious amount of caffeine and plenty of good intentions, many of these projects remain unfinished often weeks or months after we started them. So what, exactly, are the underlying causes of this code procrastination?
Problem: We Are Our Own Worst Client
We’re demanding, stubborn, and believe we’re always right. We change our mind every 10 minutes, altering the code and its purpose with every new idea that floats into our head. Developing for an ever-changing list of requirements, our application becomes a jumbled mess of half-baked ideas and half-finished features. We are our own worst client.
One of the biggest hurdles when it comes to finishing a project is often ourselves. We get started on one idea and then another pops into our head, causing us to abandon one project for another. When the dust finally settles, we’re left with several great, unfinished programs and not a lot to show for all our efforts.
Solution: Start at the End (And On Paper)
When you break it down, a program (or website) is just a collection of features that are designed to help the user complete one or more specific tasks. Once we figure out what our application is, it becomes much easier to develop what our application does. But what do we do about all those other ideas, The random features and bits of inspiration begging for our attention? That’s easy: document them with mock-ups and wireframes.
Wireframing has become a powerful and popular tool for application developers to completely flesh out an idea before writing any code. It allows us to explore all the ideas for an application quickly and cheaply (in terms of time). If an idea doesn’t pan out, we can simply throw it away without having already spent hours putting together a working prototype just to see if something “works.”
Problem: We Have All the Time in the World
Some people work best under pressure. Others like to have a little breathing room when dealing with deadlines. Some of us only know deadlines by the sound they make as they whiz by. For most weekend programmers, there is no deadline; we have all the time in the world, and that’s the problem: we set our own deadlines and have no qualms about asking for an extension from ourselves.
Solution: Set A Short Release Schedule (and Actually Release)
Setting a release schedule (and sticking to it) helps narrow our focus and our feature list to help us “ship” on time, even if the final destination is just GitHub or our personal website. By setting a deadline, we’re going to spend more time developing the truly important features and less time tinkering with new possibilities. And remember that a deadline for a weekend project often works best when it’s less of a date and more of a length of time. For example, I set my release date for this blog at “one week”: I have one week from the last entry to get the next one written.
When it comes time to release our code, I recommend we publish both the code itself as well as a short write-up explaining what the code does and why we made certain design decisions along the way. This servers three main purposes: It forces us to release code that actually freaking works. It may be easy to keep our crappy code in the closet next to our old DHTML and Flash books, but if we release our code into the wild there’s a chance we’ll be held responsible for it (reputation-wise) and therefore a better chance we’ll make sure it functions properly. Second, It teaches us how to better communicate technical concepts to a (potentially) non-technical audience and get them excited about what we’re doing. Just because our mom doesn’t know Ruby doesn’t mean we can’t write about our new program in a way that conveys it’s purpose and our excitement for it. Finally, releasing our code publicly not only supports the open source movement, it gives our program a sense of both version (as in ‘version 1.0’) and a sense of completeness. Once our code is public, it’s no longer ours to tinker with endlessly weekend after weekend. It serves a purpose and can be improved upon by other developers who find it useful.
Finishing a weekend project is a goal often just out of reach for many programmers. I hope you’ve found my advice both inspiring and helpful in your coding endeavors. Feel free to leave me a link to one of your finished projects in the comments, I’d love to take a look. And if you still find yourself unable to finish, you could always turn your source of frustration into a banner of pride and get the t-shirt.