Side-projects are important to every programmer I admire. Google’s much-publicized 20% time is a corporate codification of the importance of side-projects; even a company that’s worth billions knows that you can’t keep good people working on the same thing all the time.
Side-Projects and You
There are lots of good reasons to always have some side-projects going:
- Projects keep you learning. New programming languages, new technologies, new ideas.
- Projects are mentally refreshing. Taking a step away from the problems you normally deal with is relaxing, and can lend a new perspective on how you work.
- Projects can be fun. Fun is fun.
- Projects can be profitable. Little ideas can turn into products and services that people want to pay for (or at least click ads on). Unusual ideas can forge new markets.
- Projects make you friends. Getting involved with a community is rewarding personally and professionally.
All that may seem obvious if you’ve made a habit of having side-projects, but I’m always surprised by how many people don’t bother. But then, you don’t hear about those people because they don’t blog, attend meetups and conferences, or generally do things that would make them visible. Side-projects are a sign that you care. They’re something we ask about when interviewing at Twitter.
Side-Projects and Me
I’ve had two side-projects on my to-do list for ages. The first and oldest is Peeramour, which is more or less a dating site for bloggers that emphasizes one’s existing online presence rather than requiring yet another half-baked profile. I’ve been wanting to build this for about the last three years. Peeramour was conceived to scratch a personal itch, but I think there’s a business opportunity there too. It’s also something that I think would make people happy, and I feel an obligation to give something back to the web community that’s been so good to me. Peeramour isn’t hard to build, but I want to build it right, both aesthetically and technically.
The second project I’ve wanted to work on is Quotidian, a Mac OS X (Cocoa) application with which you can store, tag, and organize your favorite quotations. I’ve also considered building a web compliment to Quotidian that would allow you to share your favorite quotes with friends and interested strangers, but Trsly pretty much gets this job done to my satisfaction. My goal for Quotidian is mostly educational: I use a Mac every day, but I have a relatively limited sense of how I’d build a native Mac tool for myself to use. I’m also concerned that too many of my eggs are in the web-programming basket. Web apps may be vogue, but desktop application programming isn’t going to disappear any time soon. It’s tough to be a skilled generalist, though, and while I’ve learned a bunch of theory about how to write Mac software, I haven’t had time to get into the nitty-gritty with this project. Once again, the difference is between doing it and doing it right, and the latter requires a ton of knowledge about a development platform with a nearly 20-year heritage.
One of my old side-projects, acts_as_sanitized, has been forked and surpassed (with my hearty blessing) by xss_terminate, written by Luke Francl, who’s blogged about it here. acts_as_sanitized was released just before I got swamped by work on Twitter, and I owe Luke for making it something useful again. It’s a lesson in the value of open-sourcing, and it leads me to what follows.
Side-Projects and Twitter
Working at Twitter is more than a full-time job. As I mentioned in a previous post, we’re still a very small technical team (presently five people writing code and two looking after servers). There’s always something work-related I could/should be working on, which means that there’s basically no room in my life for guilt-free side-projects. No surprise, right? We’re a startup.
One of my goals is that Twitter gets big enough that we have room for side-projects. Right now it just doesn’t make business sense. We barely have time to open-source projects like Starling that can benefit from the community’s support, much less to code up our own off-the-wall ideas. Compared to our peers in the Bay Area Ruby community we open-source a pathetic amount of code, and I’m eager for that to change. Part of making that happen is approaching our internal goals with the idea that the solutions need to be generic enough that they can be readily opened-up to outside contribution.
The people I’m really excited about working with are all big open-source contributors, and I don’t think I’m alone in that. As part of scouting for talent becomes evaluating open-source work, it’s going to become a standard part of every good company’s growth to standardize policies around open-source contribution and side-projects. After all, Twitter started out as a side-project, which pretty much says it all.