Having a side project (often called a “pet project” or “side hussle”) is a great way for every software engineer to improve existing skills or learn new technologies altogether. It provides a safe environment where you can experiment freely and iterate faster. You’re not bound by other people’s requirements so you can try this new cool-looking library still in “alpha” stage. Of course no one (except you) will be upset if things go wrong and everything breaks.

Following are a few tips to make the most of your side project and learn as fast as possible. If you don’t have a pet project yet these will serve as a guideline how to start one.

1. Complete

Whatever your project is, it should be a complete product. People often confuse “simple” with “complete”. A Calculator app is rather simple to develop, but will be incomplete unless it can perform at least the 4 main arithmetic operations. The goal here is to treat your side project as a real one in terms of requirement definition and lifecycle. This attitude sets correct boundaries for the conclusions you draw out of it (e.g. the things you learn). It’ll also save you from false positives – things often work in isolated cases, but fail when you want to have them in production-ready code.

TL;DR — you want your project to be both Complete AND Simple

2. Small

One of the benefits of a side project is to be able to test new ideas / libraries / design patterns quickly. You want blazingly fast compilation and test running times. Often this means keeping your project small (yet meaningful as per rule #1). Popular choices are a ToDo app, Birthday Reminder, HackerNews reader, Basic GitHub client, etc. Keep the features to the minimum set that allows you to test and experiment with all your hypothesis and things you want to learn. In practice a mobile app with 3-4 screens should be enough to experiment with different architectures, the most popular libraries and navigation patterns.

3. Isolate changes

Always experiment with only one change at a time. People often get in a rabbit hole by trying 5 new things at once. This way it’s much harder (and often impossible) to draw conclusions from your experiment. If you fail, you don’t know which of the 5 new things caused the issue. If successful, you know the 5 new things work good together, but you don’t know if they will work in isolation. Instead, make your changes in specific, isolated iterations. Try only one new pattern / library / idea each time. This will reduce your cognitive load and allow you to focus better. You will be more confident and you’ll gain deeper knowledge.

4. Stick with your pet

People are often tempted to change their pet project more often than needed. Or even to create a new project for each different topic they want to learn. This makes it harder to compare the impact of your decisions in terms of effort, time, performance, benefits, drawbacks, etc. I’ve seen comparisons of a library X in terms of a dynamic screen in App A vs static screen in App B. Of course such a comparison is based on gut-feeling and not a solid, data-driven benchmarking.

You should always compare apples with apples. When you pick a side project, stick with it for some time. Make your experiments based on exactly the same app, same screen and same data set (or as close to this rule as possible). If you want to try a whole new technology, build the same app using it. This also reduces the mental effort required to define a side project and its features. For example if you want to evaluate building a native app vs Flutter vs ReactNative – try to build exactly the same app and compare the 3 approaches. This way you’ll get the cleanest results.

5. Keep different versions

Often the experience you gained with a library / technology / pattern from your side project will become useful in your day job. It’s a good idea to keep different versions of major changes readily available, so you can tap into your findings quickly. This applies mostly to big technology / architecture / design patterns you’ve experimented with. GIT is your best friend here. A useful branch naming strategy is:

category-of-experiment/version-of-experiment

// for example

architecture/mvp
architecture/mvvm
image-loading/glide
image-loading/fresco
async/rxjava
async/coroutines

Summary

The above rules form a guideline to set your side project up for success. Be persistent and make use of it as often as possible – try out every new thing that seems useful, gain hands-on experience with every new architecture and design pattern you see. This will sharpen your engineering skills and increase your overall productivity. The goal of your side project is to stay ahead of the game at all times. This will often give you a stronger hand in discussions within your team, as you already have experience with a technology / library / technique.

If you don’t have a day job yet the side project counts towards your portfolio. It tells future employers you’re truly passionate for the profession and can showcase some specific skills you already have.

Lastly, keeping a well-rounded side project teaches you the essentials of project management – it’s something you have nurtured from the idea -> development -> evolution.

Happy coding!

P.S. The Android Architecture Blueprints project is a great example of a successful community “side” project. Although it has grown a lot bigger with the support of many different people, it still follows the same basic principles listed here. If you have another example for a great side project, please share it in the comments below.