Side Projects Are Your Playground
I love side projects.
They let you learn new things, have fun and experiment.
Unlike a typical day job, you get to be in control. You get to do what you want to do. No clients. No managers. No bureaucracy. And you get to ship your own product.
“…you should be hacking at projects, building apps, websites, and tinkering away at things you love to build outside of work.” — Ximena Vengoechea
Ximena makes some great points in her post “Side projects are the new resume”. They’re a great way to help benefit your personal career, but they can also be a huge benefit to your day job and company.
A playground to experiment with new things
These days there are a lot of new things to keep up with. Online services, new or updated languages, new techniques for doing things.
As a company, how do you decide what to use? What if you start using a service but it doesn’t work as expected? What if everyone wants to use something different? Is it worth the time and resources?
That’s where side projects come in handy.
Take a side project of mine for example. Flask.io is a simple to-do list website. There are lots of these out there, but it still gets a decent amount of returning daily users. It’s small, light weight and easy to maintain.
One of the reasons I developed it is to experiment. I decide what tools I want to try. I use them and determine if they are useful. I don’t need to train anyone else. I don’t need to ask for permission. I don’t need to hold a meeting. I just do it.
I’ve used side projects to experiment with a bunch of awesome tools in recent years including Mixpanel, CrazyEgg, Optimizely, Qualaroo, Segment, Airbrake, Intercom, Heroku, Typekit, Sass. If I liked them and got value from them I introduced them at the work place and used them on bigger projects at the company or client I was working with.
Lots of companies aren’t built for experimentation
Think of a company that has 2,000 employees, and someone wants to introduce a new analytics service. This would involve a meeting, or a series of meetings. It would have to get approved by multiple people. It would then have to be fitted into a sprint somewhere, then assigned to a developer or team, QA would test it, then it would go into a release, and training would follow.
Depending on your release cycle it may take days, weeks or months to validate if it’s actually useful or not. Plus there’s more risk, and if it fails it’s on your shoulders.
Now what if you wanted to try the same thing on your side project. Integrate the service and ship it.
Having a side project with active users is extremely valuable. Even if you don’t make money from it, or actively develop it, just having it there to play with gives you an environment to try and learn new things. And who knows where it will lead to. Lots of great ideas and companies start off on the side, and as you learn from your users you can grow it into something bigger. The important thing is to ship something.
Always be shipping. Always be learning. Always have a side project.
You should follow @leemunroe on Twitter.
