On Side Projects

By Radosław Miernik · Published on 12 April 2021 · Comment on Reddit

Table of contents

• Intro
• Limited resources
• Giving back
• Once it’s finished
• Project X
• A year later
• Closing thoughts

Intro

Side projects are important. And while not everyone has the time or mental capacity to have one, I think we could do better at working with them. Mine were always strictly code-related – small scripts or PoCs of some functionality.

But the code shouldn’t be a limitation. Whether you need to solve an actual problem, verify a start-up idea, want to start with new technology, or spend some time – pet projects are often the way to go. As long as the goal is there and you want to, basically everything can grow and evolve into bigger things. And these tend to have a need for maintenance.

That’s where it gets (usually) far less interesting. Code ages on several levels, often faster than we’d expect and want it to¹. You do it almost automatically at first – covering corner cases, ironing bugs, and optimizing usual workload is technically a part of the implementation, right? But suddenly you feel the urge to throw it out of the window… Sounds familiar?

Limited resources

There’s a couple of types of maintenance a project may need. First of all, it takes time to make it work¹. This includes the implementation and the setup, varying between different types of projects (a desktop application will take longer than a Python script). Later, you’ll discover weird corner cases and find bugs. All this requires your attention, often an immediate one.

Obviously, not everyone is lucky enough to have both time and mental capacity to maintain anything while studying or being employed, even part-time. And as these two precious resources are often strictly limited – or rather “temporarily unavailable” – it may be crucial to make it possible. Such an “open problem” may lead to unnecessary stress, as you can’t complete it and don’t want to abandon it at the same time².

The way of dealing with such problems is completely personal. I have mine as well and some of you may find them helpful³. There are only two: define goals before doing anything and have both code and non-code tasks in your backlog. The former helps with the never-ending stream of fresh ideas – write them down instead of getting distracted. The latter is a means of mental balancing, as on some days you have “coded enough” and sometimes you miss your IDE.

Let me rephrase and sum up this section: you either have the means to have a side project or you don’t – simple as that. In case you don’t, it may be better not to start one. And if you do, being organized is crucial in the long run.

Giving back

Things may get complicated if you make the project public. Just don’t get me wrong – I’m all in for open source⁴. The thing is that now other people may see and use it – that’s the good part. But they may want to contribute, report bugs, and file feature requests. It may be wonderful, but it requires extra work.

I won’t go into details here (I’ll leave it for another post), but there are certain techniques and tools to ease this process. Just remember this one fact: making your code public does not oblige you to maintain it.

But does a side project has to be an actual project? Of course not – contributing to an existing one may cover all your needs. On one hand, it’s often harder to contribute than actually create something. And it’s even trickier if you’d like to try out something new. On the other hand, it may be far easier, as the setup is already done and you could focus on the task itself.

At the end of “non-project projects” scale, we have small-scale contributions. Maybe you are using a library and one of its features could be improved? Your favorite framework has incomplete typings? Or you’ve found an invalid link? It may be enough for a portfolio and more than enough to learn something.

Once it’s finished

A particular stage of your project is now complete – well done! You’ve hopefully managed to fulfill your goals; at least some of them. Objectively speaking, you could call it a day, right? Yes, but it’s hard, as the urge of rewriting has already struck you. Or soon will.

Let’s take a step back. Is it actually that bad? Do you really have to rewrite it? Or it’s all about the goals you’ve set? Maybe it just wasn’t meant to be. Actually, most projects weren’t. And that’s not a bad thing – just think about the journey. It’s all about experiencing. Not necessarily learning, but rather being stimulated.

I have an archive of some of my early programming projects⁵. Today, I could say that only two or three – among tens – are finished. They are not done, but I don’t see a point in going any further. At some point I realized, that the goals and plans we do upfront are effectively required not to lose motivation. But it’s completely fine to end up with an entirely different result.

It’s funny how self-aware this text is. I do consider writing as my (significant) side project, and I really enjoy doing it. I’ve tried it in the past, but it never came to the point of being “publishable”. What was different this time, was that this time my goal was not to create a text, but to actually write. It worked for me.

Project X

Back in June of 2017, a colleague of mine asked me, whether I know any decent software for managing test cases that I could recommend. After briefly discussing her requirements, I’ve started my research. We quickly realized that there was nothing that would cover our needs and fit within our budget. Most products were focused on rather enterprise-ish clients.

Let’s make one then! It took me two weeks to design some mockups and two more to implement a very basic interface prototype. In the meantime, another colleague of mine got interested in the project. And not because he needed this tool, but because we generalized it into a note-managing one. In the end, these two share similar concepts – text documents with tags and a powerful search.

About ten weeks later, the project was done. It wasn’t the most beautiful nor performant code I’ve ever written, but it was enough to use it. I even came up with a punny name⁶ and bought a domain. Technology-wise, I used my go-to stack: Meteor, React, and MongoDB. And as you expect, I wanted to rewrite it.

But this time was different – somebody was already using it. Nobody was relying on it, but I thought it might be a good occasion to learn something new. I never actually switched a critical piece of technology with no downtime. At first, I wanted to replace React with smaller Preact – this part was fairly easy and involved nothing except extensive testing.

A year later

In the following year, I’ve made a lot of minor improvements, mostly refining the code that was already there. And then I thought “How hard could it be to migrate off the framework?”. There’s nothing wrong with Meteor, really. To be honest, I wanted to make sure that, as a software architect, I can recommend Meteor, even if we’d need to migrate off to something else. So I tried.

Having the application running for over a year at this time, there were about a hundred users and a couple of thousand notes. I decided not to use any of the existing frameworks, but rely on a group of libraries instead. A month and one failed migration later, everything was running using Express and a custom replacement for Meteor Accounts. Everything was great. But I wanted more.

A few months later, I migrated from Express to Fastify. I wasn’t concerned about the performance⁷ – I just wanted to try it out. The abstractions I had in place for the API, SSR, and rate-limiting, made it far easier than I thought.

Also, did I mention that the project was using Flow? Well, not anymore – it got replaced with TypeScript. If you plan to do the switch as well, here’s a tip: use flow-to-ts and ts-migrate. It’s still time-consuming but easier.

It was a long and bumpy road. I learned a lot, especially in the DevOps sector. Based on Git history, every single feature was rewritten at least two times. And I’m definitely not done – whenever I want to try a new library, this project gets it first. It became the best code sandbox I’ve ever had.

Closing thoughts

The problem of (not) having resources, the dilemma of sharing it with others, the constant urge of rewriting everything all the time… I guess we could call these the four three horsemen of side project apocalypse.

As always, there isn’t one solution for everyone. You can try to find some time, at least once in a while. You can try to share it with others, maybe with close ones. You can try to tame yourself and not rewrite anything, this one time.

I’m trying as well. Failing too. Enjoy the journey.