How to Approach Side Projects

Almost everyone has great ideas for side projects. Over the past 3-4 years, I have had numerous good ideas, but have only started on a fraction of them, finished even fewer, and been happy with maybe 1 or 2 out of 20. This post is an attempt at crystallizing what I’ve learnt about making it easier to start on your side project ideas, making it more likely that you finish them, and how you can actually be happy with the end product. If you’ve been meaning to start on a side project for a while, maybe you can find some value in this!

At the heart of it, any side project is a 3-step process:

1. Understand what you’re making/doing

2. Specify what constitutes a finished project

3. Implement your idea

I’m going to use 3 side projects to elaborate on each of those steps. The 3 projects are a music and video project that took under an hour to make, a semester long technical project, and an ongoing project: this website! Let’s get started.

1. Understanding what you’re making

This step is all about putting your abstract idea into words. You’re trying to answer the question “what am I making?”. The goal is to add more clarity to your idea. I suggest putting this into writing. There have been multiple situations where I had an idea that made sense to me in my head but looked questionable when put onto paper. At this step, there is no need to be overly specific. Just answer the “what am I making” question. Here’s how I did it for 3 of my projects:

1. Tiny music project: a random video with some original piece of acoustic music

2. Branch predictor project: functional level models of 2/3 branch predictors in C++

3. Personal website: a website that can be a home to all my work and also act as a blog

2. Specification:

You have an idea of what you’re making. Now, specify details before you get started. Answer the question: ‘what constitutes a finished project?’. The goal here is to remove any vague descriptions and set concrete expectations from the project. I like to be as objective as possible here. ‘Specification’ calls for specificity (wow). Be specific! For my projects, I like to make a list of outcomes that need to be done to call the project ‘finished’. Here are some of my lists:

1. Tiny music project:

   • A chord progression

   • A video

2. Branch predictor project:

   • 1-level predictor functional level model

   • 2-level predictor functional level model

   • Binary instrumentation tool

   • Everything parameterized and extensible

3. Personal website: a website that can be a home to all my work and also act as a blog

   • A main home/landing page that holds links to all my work

   • A blog page with hero image support

   • A first post with a vision for the website

The point of making these specifications is so you know exactly what you’re trying to build. In my experience this step also makes it more likely that you will be happy with your finished project, but your mileage may vary.

3. Implementation

You now have an exact idea of what your project involves. Time to work on it! You’re looking to answer the ‘how do I make this’ question and then follow through. The goal is to start working on your project, deal with problems, and keep going until you finish. In my experience this step is made infinitely easier when I do steps 1 and 2 well. Otherwise, the lack of clarity is demotivating.

This is also about 80% of the total work of the project, and involves dealing with problems that you don’t foresee. For example, here are problems that came up when I implemented my projects:

1. Tiny music project:

   • I’m very new to writing my own music. I got stuck many times and changed up the progression at least 3 times until I had something I was happy with.

   • I had some technical difficulties with recording as my mic just stopped working. Did not see that coming.

2. Branch predictor project): functional level models of 2/3 branch predictors in C++

   • There were parts of the code that required C++ tricks I hadn’t worked with before. Reinterpret casting, compiling Intel’s pintools, issues with huge Makefiles and writing and debugging code.

3. Personal website:

   • This was my first time being exposed to any sort of web development. Setting up and learning Jekyll was a big task.

   • I also ran into issues with GitHub pages

And that’s mostly it! Here’s some final things to note:

It’s okay to abandon projects if you don’t think they’re working, but abandoning something because it’s too much work just doesn’t feel right (I’ve been guilty of this a lot: my YouTube channel still is a good idea in my head, but just too much work so I don’t get around to it).

The whole process is iterative! During implementation you may realise your spec needs to change a little bit. Do it! If you think something is too difficult and needs to be made easier so you can finish it, that’s a great call.

At the end of the day, side projects are voluntary. I abandon side projects if I stop enjoying the process and ‘finishing the project’ is the only motivator.

There are so many more details that I wanted to talk about in this post, but there just isn’t any room. If you want to talk about any of your side projects or if you have an approach that works well for you, let me know! I’m always willing to talk.

See you next week for a new post!

Thanks for reading! You can always email me to chat about this post - or anything else.