The Philosophy of Side Projects

Every developer knows the endless struggle of deciding their next side project. Deciding what you want to make is often about what grabs your attention and sounds exciting. I'd like to offer an alternative approach, side projects shouldn't focus on what sounds cool, but what instead will make you a better programmer. However, having a clear direction in your personal growth as a developer is more important than what that direction is. Here I want to walk through my philosophy, my direction for side projects and explain how talking about those projects is a reflection of my philosophy.

What's the Goal Here?

I always try to have a clear goal in mind when starting a new project. I find that having such a goal gives me direction, which helps with both the quality of my code and my consistency. It's much harder to get bored and leave a side project half-finished when you know there's something valuable to be gotten out of working on it.

Asking myself, "What does working on this project do for me?", is essential to working out that that goal is. Whether that goal for you is refining skills, building something practical, or something else, isn't as important as having a goal in the first place. However, my philosophy is that side projects are an opportunity to learn a new technology or skill.

For Me or for You?

There's definitely something to be said for making a project to be used by other people. However, focusing on a project for other people shifts priorities towards finishing the project, so others can enjoy it, as opposed to focusing on the learning process for yourself. There isn't anything inherently wrong with this mindset, but your projects are less "side projects" in spirit if many other people have stake in them.

If you want to build a project for personal use, use it as an opportunity to kill two birds with one stone. This is where the true value of side projects lies. Make that app to clean up an inconvenience in your workflow AND add a new framework to your resume.

It's About Finding that Balance

Sticking to what you're comfortable with won't make you a better programmer. The best way to maximize the learning aspect of a new project is to purposely use technologies you are unfamiliar with. It requires a leap of faith; take on things that are harder than you think! The internet is full of tools to help you learn: Stack Overflow, YouTube, tutorials, and even AI (but that's a topic for a separate post).

Everything in moderation, however. A common pitfall in passionate developers is always pushing for the next new thing, which easily sets up for bad habits. While something new may be interesting, the so-called "shiny object syndrome" can easily get you. Jumping to whatever project idea is the most exciting before finishing your current project in any meaningful way is effectively teaching yourself to leave projects incomplete. The final stages of projects aren't flashy and don't make as much progress, but often require a level of understanding of the fine technical details that will set you apart from the competition. The "side" part of side projects is crucial as well; they should never be prioritized over your primary work or school projects.

Why Should They Care?

Let's be pragmatic: there's not much of a point in improving your skills as a developer if you're not able to effectively show off those skills to potential employers or clients. So how do you describe your projects in a concise way that completely encapsulates the entire journey from start to finish?

The STAR-L Format

You've probably heard of this acronym before; this format is commonly used for answering behavioral interview questions.

• Situation
• Task
• Action
• Result
• Learned

While these exact terms don't line up one-to-one with coding projects, the idea is still great for showcasing the project in its entirety to interested parties. Following this format gives a template for talking about the project's journey from start to finish while giving full context to your audience.

Situation

• Start by talking about the background of the project. Where did the idea for this project come from? This is where you set the stage for the later parts of the story.

Task

• Given the situation you just described, what needs to be done to achieve your goal?

Action

• What did you actually do to accomplish the task you described? This is where you can really get into technical details of your project.

Result

• What happened as a result of the actions you took? Did your project successfully work out? If you failed along the way and had to backtrack some, mention it! Nobody is perfect, and showing how you handled setbacks and learned from them is just as valuable as showcasing technical skills.

Learned

• Bringing everything full circle, the point the side project was to learn something new. So, what did you learn from this project? Here you can really show off. Of course you should talk about tangible accomplishments, what your completed project does, but also spend time on the hard and soft skills acquired from the entire journey.

STAR-L is the approach I'll use here for blog posts on my projects. I'll try not to specifically call out each keyword of STAR-L in posts, it's meant to be used as an outline for what to talk about. At the time of writing I have a few projects completed that I'm writing posts for, namely SET and K-Puzz. Expect those and new posts when new projects are finished and released!