Succeeding at Personal Programming Projects

December 25, 2013

Every software engineer has one (or many) projects they want to work on, but never seem to find the time to do. As someone very dedicated to my craft (at least at this point in my life), taking a week off work for the holidays means cranking code at my mom’s house while my family thinks I’ve lost my mind. “Get off your computer! What’s the matter with you?” *sigh*

Anywho, my successful side projects go through several stages, and neglecting steps leads to failure. Most people start a series of projects and never finish. You need to follow through, stick to your goal, and find your passion in order to succeed where many have failed.

The Idea

Good ideas come from everywhere. I will write a future article about coming up with ideas, but with practice, you should have at least one good idea every day. Some of these ideas are massive projects that require funding and building an organization. This article is not about those. Those ideas should be saved and analyzed later.

Other projects can be done in an afternoon or weekend. A good personal project has realistic goals, and can be done within the time frame available (note: all projects take longer than expected).

You need to believe in the value of your project in order to have the passion required to finish it. The value can be for yourself, such as learning a new language or design pattern. The idea could be something that provides value for others, such as an open source project or useful tool. Personally, I’m very focused on projects that generate revenue, because I love passive income. It feels good to have projects that, 1) People use, and 2) Generates you a constant flow of money long after you finish working on it. One example of this is Best Hanging With Friends Cheat, a tool to cheat at a semi-popular Zynga app, that I built in a weekend of non-stop coding and has made me hundreds of dollars. I built it because I wanted to design a mobile-optimized website and write an algorithm for solving an interesting word-anagram problem.

You could also do extra projects for your company. My recent four-day coding bender over this holiday vacation was for them, because it was both interesting and useful for our clients (automatically injecting code into Android applications so an administrator can remotely control it from a web browser).

The point is, find an idea you can be passionate about, because finishing a project takes so much effort that only good ideas will inspire you to finish. For me, learning something new, helping people, pleasing my company, and making money are the factors that can get me fired up.

The Execution

Of course, planning should happen before execution. However, once I have a good idea, I’m constantly working it over in my mind, thinking about what the final product should be, the features, etc. Some people may feel that formal planning is essential, drawing UML diagrams or whatever. I’m skilled enough now that generally well-written code flows out of me, and I naturally organize code in a way that suits my personality, so coming back to it later feels like putting an old shoe back on your foot. Therefore, I’m not too worried about a detailed plan, especially because the code will only be developed by me.

This is the most fun part of the project. You’re using your favorite tools and technologies, and probably coding the most interesting parts of the project first. You will be researching and experimenting. Your output will be high, and before you know it, the fun part will be over. This will take about 20% of the total project time.

The next phase is getting the code useful. Maybe putting a UI on it, or extending the API of the SDK you are writing, or making it easier to test than having 5 terminals and clicking 6 buttons. Clean up the glaring, mission critical bugs. Getting the code useful will naturally result in more features you ‘just have to’ add, which also takes more effort. This phase will take 40% of the time.

The Execution ends when you have a usable product that accomplishes your goal and provides real value. Congratulations, 60% of your work is complete. Now, if you have the time, relax for at least a day to clear your head. Productizing and refactoring code is always better after stepping away from it for a while.

The Product

The final 40% of the project is the most critical, and also the hardest to get through. Everything interesting has been completed, and your passion is much reduced.

This is the most critical phase of the entire project.I can’t emphasize this enough. The success or failure of your project lies in this 40%. As a perfectionist, I get sick pleasure from this phase, but it is still difficult to motivate myself.

Any project released publicly, whether for the world at large or internally at your company, will at the bare minimum be used by them, if not analyzed at the source code level. People love to critique, and small issues get blown far out of proportion and threaten your project with failure and possibly humiliation. I feel this is universal to any creative professional or artisan- so much effort and passion can be wasted if there are even small imperfections. For me, my code is an extension of myself, and I want my products to be polished and professional.

Thus, you’ll need to refactor your code. Get rid of all the magic variables, take the classes that became large and unwieldy and break them apart, add comments that were missing, and make the code ‘look good’. I know poorly written code when I see it, and I don’t want my code looking like that, and neither should you.

You need to make your project shine here. If there is a UI, it needs to be clear, well designed, free of grammatical mistakes, and elegantly themed. Take the time to find a decent color scheme. If you built a house, would you neglect to paint it? You want to be proud when you show it to people, without needing to prep them with “I was going to fix this” or “Ignore this button” comments beforehand.

All bugs that have the potential to negatively affect user experience should be fixed. These bugs often take lots of time and provide little benefit, especially compared to bugs fixed in The Execution section, but are nevertheless essential to success.

If the tool is to be released publicly, you’ll need to decide how you will release it and market it. This might be purchasing a new domain, or making a github account, etc. You’ll need to write appropriate documentation. Unfortunately, you *really* can’t half-ass this part. If you don’t make a clean website, no one will use it, and then what was the point? Engineers often neglect this stage because it’s not interesting to do. If you want to successfully release small projects, completely by yourself, you’ll need to embrace the many talents required and follow through with all of them. Successful professionals are rarely talented in one field- you need to become skilled in many. Use every task as an opportunity to improve yourself.

Conclusion

Release the project. Monitor its success and tweak it if necessary. Pat yourself on the back for a job well done, and feel free to show it to other people. Most people don’t have a portfolio of projects to show people- you just put another one on your resume.

Getting to this point is difficult, just remember to follow your passion and see the value in your idea.