Software engineering in our daily job can sometimes feel frustrating. Developing a side project on your own time is a great way to rekindle your passion for development and make up for what might be missing in your day-to-day corporate job.
Maybe you’re tired of maintaining complex systems and writing countless http calls between dozens of microservices and want to return to writing application logic. Or you have a genius idea for an application that could sell and you want to develop it by yourself (or with friends). You might also want to try some tools and technologies that you’re not allowed to use at work, or you need to automate tasks in your personal life and haven’t found a ready-to-use solution…
Owning a development project is highly rewarding. In addition, it allows to showcase specific skills (to your current employer, or elsewhere) or demonstrate the feasibility of a solution you want to push at work. But it can also simply be a hobby, with no expectation, because you like it!
I’m writing this article because I’ve been longing to develop a new side project for months, and I’m finally making it happen! First step will be to choose the technical stack (programming languages, systems, services…).
Let’s see reasons to choose well-known tools or new technologies for your side projects.
Using a technical stack you already know
For the very first personal project I developed, I chose a technical stack I already knew. I wasn’t working in IT yet and had just completed a software engineering training program with a particular stack (Java, Spring Boot, Angular, PostgreSQL).
It made sense for me to continue with those technologies, for several reasons:
- Lack of experience. Obviously, without much experience in software development, I didn’t have the maturity to question my “go-to” stack.
- Applying my training. Just out of a training, it was a great way to apply what I had just learned and go deeper.
- Career focus. I wanted to specifically find a job where I would use that stack. Building an application with it allowed me to showcase my skills. In another article, I explained why I chose to stay super specific in my technological stack during my first years as a software engineer.
- Getting relevant experience. I transitioned from a non-technical career to CS, without a typical career path, so I wanted to get any hands-on experience I could.
- My toolbox was sufficient. In fact, the tools I learned perfectly matched my project. There isn’t a single best solution for any development project, and those tools were relevant enough not to require anything more or different.
- Time to deliver. I wanted my project to be done asap so I could use it as my portfolio.
- Maintainability assurance. I know those tools are here to stay, and that I will have no difficulty maintaining the app myself because I know them very well.
Using a new technical stack
After a few years on the job, I felt more at ease handling unknown technologies. I also wanted to develop new skills. Therefore, for any new side project -be it a project at work to support developers’ experience, or a personal project on my free time-, I try to use at least one new tool, service or language.
The reasons to go for something you don’t know yet:
- Functionalities. The stack you already know doesn’t meet your specific needs for that project.
- Training. You want to improve a weaker skill or learn something new.
- Challenging yourself. You’re bored with what you must use daily at work and want to explore new horizons, or you just like keeping your adaptability sharp by learning new tools.
- Career evolution. Showcasing your ability to adapt to unknown technologies, or skills in a particular tool required to be promoted (example: add CI/CD to your development skills), or apply to a new job.
- Advocating. You’d like to show your colleagues or technical lead that a different technical stack could solve a current problem, but you can’t just force-push your idea.
- Trying the new cool tool. Maybe there is a language or technology you’d really like to try out, but don’t have opportunities at work.
Criteria to choose your technical stack
Some of the reasons mentioned right above have more weight than others. The main question to ask yourself is “What is my goal with this project?“. If your primary goal is clear, it should be obvious either you’d go for known technologies or new ones.
In addition, there is no all-or-nothing choice. Maybe most of the services can be built with your favorite toolbox, but one functionality will require something different. Or you can rely mostly on your usual tools, but incorporate just a new one for your own pleasure. That’s the best setup in my opinion, it gives you comfort and opportunity for growth in a single project.
What I chose for my project
I imagined many recipes to develop the new project I’m starting. To be honest, at the time I’m writing this article, nothing final was decided yet, but I’m starting to see where I want to go and what I want to achieve, and I have an idea about the tools I’ll use.
This is an application I want to use myself, to help me in my daily life. I also think it will solve a problem many people encounter, so I have hope in making revenue out of it. The application is here to stay, it’s not a MVP or a Proof of Concept. In conclusion, I need sturdy tools.
I also want to learn new things with this project, but not at any cost. Recently I was really bored with writing CRUD operations in my backend. After some research, I discovered Data API builder on Azure, and I’m really excited to try it. That solution is supposed to create a simple CRUD backend without coding. Isn’t this lovely?
On the other hand, the application I want to build requires complex data transformation, that I don’t want to delegate to my frontend service. Therefor, I will develop my own backend and keep that tool for another time.
I found another new AND relevant tool to include in my toolbox for this project. I noticed that nodejs with TypeScript gained popularity as a backend stack over the last few years (many job offers mention it), so I might give up on the usual Java or Kotlin for my project!
Other considerations to choose your technical stack
Changing your mind
Some technologies and strategies are easy to replace later on (for example, how you’ll deploy your app). When it’s the case, you can make a bold decision and change your mind later with a low impact. However, other decisions are more difficult to change: moving from Micronaut to Spring Boot, or from nodejs to Java, would be cumbersome.
You don’t want to be stuck with the bad technology in the future (especially for applications that are here to stay), so think twice when you choose those “base” building block, and give yourself more flexibility for upper layers.
⚠️It could be tempting to give up on your project if it requires a heavy refactoring work, or redoing something from scratch.
Be curious
Except if you don’t have any previous experience, I would always advise to try to add at least one new tool to each project you start on your own. Look for alternatives of your usual stack, regularly check what’s new on the market, read job offers to see which technologies are often mentioned…
Dare to fail
Side projects are a great opportunity to test things without much (or any) impact and pressure. Take time to compare, start your project based on your assumptions, test early, and start again when necessary. Get your hands on a new programming language, quit after a few hours or days if you don’t like it. Adopt the “fail fast” approach to avoid putting too much effort in something and ending up disappointed (and discouraged).
Ready to start your personal project? What will you build? What tools will you choose?
