One of the most common things I hear when talking to other programmers is that they struggle to finish their side projects. Many have multiple apps that have gotten about 50% of the way completed, and then were abandoned for the next side project. If this is starting to sound familiar don’t fret — we all do this sometimes, and while I haven’t solved this issue for all of my programming projects, I want to tell you what I have learned to help me start to fix things.
1. Figure out your motivation for building what you are building.
We build side projects for many reasons, so it’s best to always keep in mind what our end goal is with the side project. Are we trying to learn a new language? Automate a task to make our lives easier? Win an argument? Get job experience in a certain technology? Work with a friend on something cool? Depending on what our answer is, our definition of “completing a project” will differ, as will our motivation to actually complete the project.
An example I can recall is a small website I was building to win an argument. It was a neat concept, and novel, but my motivation for building the site stemmed mostly from trying to convince a few people they were wrong. By time the I was about 30% the way done with the project, however, the argument had been rendered moot, and people had moved on. I could have finished the website fairly quickly and re-brought up the argument, but at that point it felt like a pyrrhic victory at best — the time I would have spent building it would have been wasted on an argument that had already been decided. Even if the site was somewhat cool, novel, and possibly profitable, my motivation for building it hadn’t stemmed from any of those things. Where it had stemmed from, instead, was the argument, and when it died so too did my primary motivation.
I’ve seen this many times with inexperienced entrepreneurs as well – they are motivated by either profit or success (or both), and that drives them to build an application and launch it based on its “hotness”, “ease of profit”, etc. When that site they build does not see instant success, however, the entrepreneur shuts down the website almost as quickly as they launched it, and starts over again. Why? Because their motivation isn’t tied to the actual usefulness of the product itself, they have no qualms immediately dumping a product they don’t care about. What they care about is the fame or fortune that comes with that app, and the ability for them to achieve that as best as possible.
Once we figure out what the primary motivation for what we are building is (there may be plenty of secondary or tertiary motivations), figuring out what “complete” means will let us know when to stop. If our motivation is winning an argument, “completing” that project might mean when the argument is moot or already won. If our motivation is learning a language, “completing” that project might just mean getting down the basic fundamentals. If our motivation is to launch a startup, “completing” a project would be getting to the point that you have an MVP ready.
I feel like too many people think “completing” a side project means having a working, functional app that does something marginally useful. Not so! If your motivation was to learn Meteor and you learned enough syntax to do a couple basic things, but you didn’t finish the “Todo” app or “Twitter” clone, stop kicking yourself! You learned enough to know what was going on. Your goal was to learn, not to launch a basic application. By setting the bar further than what our motivation actually was taking us, we sometimes mentally doom ourselves to failure. Don’t do it.
2. Pick a technology to build your project in, then stop worrying about it.
Even from the very start of a project, dealing with indecision about the tech has prevented me from completing side projects. It manifests itself in a few ways:
When I first start a project, I’ll obsess over which language or technology to write it in
- Should I use a tried and true language I know?
- Maybe I should do it in a language I’ve been meaning to play around with for a while?
- Perhaps I should find a language best suited for the challenge at hand?
Even after deciding a language/tech, I’ll get about 30% the way through and run into issues, and wonder if I chose properly and should start over.
- Sometimes I’ll read a news article, blog post, or forum thread relating to a new technology or library that came out that seems to fit my side project perfectly, and I’ll wonder if I should rewrite it.
To be fair, having the right tools to build something is an important piece! But when we obsess over our tools at the expense of actually building something with those tools, we lose out, and what we actually wanted to build falls into disarray.
My advice: look again to the motivation for why you are building the project. If the point of the app is to get something up and working fast, work with a language you know you can write quickly in. If the goal is to build something in a new language, stick with that new language even if something “better fitting” comes along.
3. Figure out the first thing you want your project to do, and do that before anything else.
Many project ideas start off with a fairly simple concept, but end up getting bogged down in scope creep when you actually start building it. The train of thought usually looks something similar to this:
- I want to build a script that will check me in automatically 24 hours before my flights on South West to get the best position to board (initial ideation)
- I should really make this a website, so that way I can access it from anywhere
- A website needs a fun domain, so let me buy one (flightcheck.in or something)
- If I’m creating a website for it, I should probably add in a responsive web design so that way it looks good on mobile as well as desktop.
- I really should build user accounts for the website, so that way people can see the status of their check-in and history of checked-in flights
- If I add user accounts and history, I better add SSL, so that way I can protect user’s data over unsecure networks (flight information and passwords are important personal data features!)
- What about other airlines besides South West? I should probably support them, because who knows when I might use another one. I’ll just support the major ones though, to keep it easy (South West, Delta, American Airlines, United, Spirit, Virgin, and JetBlue)
- I should setup SMS/email notification after the app successfully checks me in, so that way I don’t need to go to the site afterwards to find out if the app successfully checked me in
- (etc etc)
I went from building a quick five or ten minute script into building an almost feature complete application! While there isn’t anything wrong with adding any of the features above (in fact, many of them would be quite useful), I tired myself out just from thinking of all the work I would need to do to get the site off the ground.
Don’t build a mountain in front of you to climb! Instead of thinking about every feature you’d ever want with your project, think of the only feature (or features) you’d need to get it to work. This is very similar to the lean startup methodology, but the goal here is to not quickly get to market to test, but instead give you smaller, achievable goals to finish. Once you build that very first feature, you can say your side project is complete! Stop here if you want, or, decide to keep going and add a feature from your wishlist, but at least with this way, you feel a sense of accomplishment knowing you finished an important piece of your project, rather than feeling like it was one of a laundry list of things needed to be done.
4. Resist the temptation to rewrite too early.
A large problem I know I struggle with is that I end up rewriting my code much earlier than needed. Perhaps I learned a new technique that would help optimize one piece, or maybe I’m not happy with how something was written and want to start over fresh. This is a tempting road to go down, especially when rewriting feels like progress — and if the essence of great writing is rewriting, by rewriting time and time again, we should soon have written the equivalent of a bestseller. Despite this, it ends up feeling like we haven’t made much progress at all. Why?
The problem becomes we keep rewriting the first chapter without ever finishing the complete rough draft! It’s easy to see why this is so tempting — in the beginning, we have limitless possibilities, and there is no “wrong” answers. But as we get further into writing a book, we have to make actual decisions, which become harder and keep track of and manage depending on what we had done previously.
Many times, with code, we will get to our first “blocked” point and think to ourselves “ah, I didn’t account for this one piece in my previous code. I should go back and rewrite everything to fix this”. Then, we get a little further down the line, and find out there is something else we forgot to account for, and we go back and rewrite again to account for that. And as we continue along our project, we rewrite and rewrite again and again based on where we get blocked.
I talked to an entrepreneur once who had gotten a friend to develop a project for him. The friend got about 50% the way through the project, and then had to move on to other things. The entrepreneur then hired a new developer to finish the rest of the app, who took one look at the code, and decided it was awful and that he would rewrite it from scratch. He got about 50% the way through the project when he started realizing why things had been done as they were, and he quit the project. Then the entrepreneur hired another developer to finish that application, at which point the entrepreneur was convinced again to rewrite the application from scratch, at which point the developer got about halfway done, realized why certain decisions had been made, and again bailed on the project. At the end of the day, the entrepreneur spent about $80,000 on the application, and had nothing actually complete to show for it.
I get why we rewrite code so early — we know what decisions we would make different for the pieces we would need to rewrite, and we might not know the decisions we need to make to move forward for the pieces we haven’t written. But rewriting code at this point is almost a form of procrastination — we are putting off making the hard technical decisions for things we may not know by fixing the easy things we know we can fix.
Instead, what if we had just done our best to complete the application first? By completing the app, warts and all, we get the full scope of the application, what it needs to do, what we didn’t account for, and what needs to be pruned. Then, we can go back and fix things. And if we aren’t happy after fixing things, or we find new mistakes, we can go back and fix them again. And no one will know but us.
5. Don’t feel bad when things get too hard
Unlike #3, sometimes we start off with ideas we believe are fairly simple, then find out how difficult they actually are and realize the rabbit hole we are getting ourselves into. This realization hopefully comes during the research stage, but can many times come halfway through a project when you finally come to terms with the fact that you are way over your head.
The advice I would give is to look back on your motivation for starting the project again. If you have a true passion for what your doing, but you feel things have gotten way over your head (or are impossible), chip away at your idea until you get to something that is possible, and work from there. While it might not have been exactly the road you wanted to go down, that doesn’t mean it might not possibly still take you to the place you want to go.
For those who aren’t passionate about the idea, don’t feel bad just walking away. Who knows – maybe six months from now you’ll find a fresh outlook on the idea and take it back up, or use the knowledge you found out to educate others. While it’s tough not to think of this time as wasted, you’d be surprised when the knowledge you learned from a “failed” project ends up helping you succeed somewhere else down the road (parable of the farmer’s son and all that).
This is not a complete list of what it would take to finally finish a side project, and I’ve nowhere near “perfected” the things I talk about above (I have about half a dozen side projects that need fixing).
But it has helped me realize why I build the things I try to build, and at least helps me know what I should be doing, above all else. And if it helps another person, well that sounds good to me as well.
Comments are closed, but trackbacks and pingbacks are open.