How to choose a side project
If you’re a programmer just starting out you’ll often get told to work on side projects, beyond what you do at school or work. But there are so many things you could be doing: what should you be working on? How do you choose a side project you will actually finish? How will you make sure you’re learning something?
Keep in mind that you don’t actually have to work on side projects to be a good programmer. I know many successful software engineers who code only at their job and spend their free time on other hobbies. But if you do want to work on software in your spare time there are two different approaches you can take.
To understand these approaches let’s consider a real side project that managed to simultaneously both succeed and fail.
Long ago, in an Internet far far away
Back in 2000 my friend Glyph started a small project called Twisted Reality. It was supposed to be a game engine, with the goal of implementing a particularly complex and sophisticated game.
Since the game had a chat system, and web server, and other means of communication the game grew a networking engine. Glyph and his friends hung out on the Internet Relay Chat (IRC) Python channel and every time someone asked a networking question they’d tell them “use Twisted Reality!” Over time more people would show up needing a small feature added to the networking engine, so they’d submit a patch. That’s how I became a Twisted Reality contributor.
Eventually the networking engine grew so big that Twisted Reality was split into two projects: the Twisted networking framework and the Reality game engine. These days Twisted is used by companies like Apple, Cisco and Yelp, and is still going strong. The game engine has been through multiple rewrites, but the game it was designed for has never been built.
Approach #1: solving a problem
The difference between Twisted, a successful side project, and the game that never got written is that Twisted solved a specific, limited problem. If you need to write some networking code in Python then Twisted will help you get it done quickly and well. The game, however, was so ambitious that it was never started: there was always another simulation feature to be added to the game engine first.
If you are building a side project choose one that solves a specific, limited problem. For example, let’s say you feel you’re wasting time playing on Facebook when you should be doing homework.
- “Build the best time tracking app ever” is neither limited nor specific, nor is it really a problem you’re solving.
- “I want to keep track of how much time I spend actually working on homework vs. procrastinating” is better, but still not quite problem-driven.
- A good problem statement is “I want to prevent myself from visiting Facebook and other specific websites while I’m working on homework.” At this point you have a clear sense of what software you’re building.
Why a specific and limited problem?
- The problem statement will tell you whether you’re making progress: are you any closer to solving the problem? Is the work you’re doing actually related to the problem at all?
- By limiting the problem you increase your chances of successfully building something usable. If you finish it and want to keep going, great, add another problem to expand its scope. But start with something small.
Approach #2: artificial limits
How do you choose a side project if you don’t have any specific problems in mind? The key is to still have constraints and limits so that your project is small, achievable and has a clear goal.
One great way to do that is to set a time limit. I’m not a fan of hackathons, since they promote the idea that sleeplessness and working crazy hours is a reasonable way to write software. But with a longer time frame building something specific with a time limit can be a great way to create a side project.
The PyWeek project for example has you build a game in one week, using a theme chosen by the organizers. Building a game isn’t solving a problem, but it can still be fun and educational. And the one week limit will ensure you focus your efforts and achieve something concrete.
Software has no value
Whether you decide to solve a problem or to set artificial time limits on your side project, the key is having constraints and a clear goal. Software is just a tool, there is no inherent value in producing more; value is produced by solving problems or the entertainment value of a game. A half-solved problem or a half-finished game are valueless, so you want your initial goal to be small and constrained.
I’ve learned this the hard way, focusing on the value of my code instead of on the problems it solved. If you want to avoid that and other mistakes I’ve made over 20 years of writing software check out my career as a Software Clown.