by Greg Murray
last updated 7 months ago
We all know how often things can change in software development, particularly web development. Slick new patterns make you want to refactor your last project and the latest framework inspires your next great idea. I don't think I am alone when I say that it can be a daunting task to choose which technologies to use in your next side project. There's always the feeling of wanting to use the right tool for the job, not to mention the dread of coming back to an old side project and wondering why you chose to build it with the tech stack you used. It can be hard to balance trying the latest and greatest with using something a little more familiar. In this blog post we will dig deeper into this and at the end I'll include what I personally have started doing to make picking a tech stack easier.
As people in tech and especially as software engineers, the desire to choose the perfect tools for the job is completely natural. The internet is full of articles, blogs, and Reddit posts about why insert JavaScript framework here is best for insert project type here. There is this constant need to search for the latest and greatest to either do something entirely new or improve how you did things in the past.
The dynamic nature of this industry is one of the best parts about it, but what if we are getting too caught up in all the excitement? How important is practicality when it comes to choosing your tech stack?
I want to challenge the idea of the "ideal" tech stack. Not to say that it is inherently good or bad, but rather to say that it just depends on what you are trying to do. Sometimes the ideal tech stack is actually the industry standard. Other times it is a rabbit hole of endless possibilities and decision paralysis. Let's look at how you can decide what fits for your next project.
The first thing I like to do when I am beginning a new project is to ask myself "why am I doing this?" Before I can even consider what I want to use to build, I need to figure out why I am building. What is the purpose of this new project and what am I aiming to achieve? Let's consider a few scenarios.
These are just a few examples yet they may all demand completely different things in a new project. The scope and complexity may vary, as well as the intended consumer. You might want more polish for something that you hope millions of users will use one day than something that will never leave the confines of your personal computer.
It's easy to see how these factors can affect how you choose your tech stack. Maybe you have used PHP as long as you can remember and want to try out a .NET application? Or maybe you've always built things on a server and want to see what this whole serverless thing is about. Either way, the tech stack you choose is the whole point of the project. If you want to learn .NET, you probably won't choose to use an ExpressJS server.
Conversely, if your goal has more to do with the output of the project (a new web app that others want to use, for example) then the tech stack can be seen as a means to an end. It may be less beneficial to spend a few hours reading documentation on a new auth provider when you already know another one well enough and auth is just a part of the bigger picture.
Sometimes it can be a combination of the two. For example if you just want to test out how to use Redux with React, that part of the stack is important but other parts could be more of a distraction from the goal of learning. In that example, you may choose a CSS library that you feel comfortable with rather than picking up a brand new styling framework since you'll have to spend time learning that in addition to learning Redux which was the whole point in the first place.
Ultimately, every web development project you begin is unique so the goals should be unique too. By defining those goals from the start, you lay the foundation for a tech stack that serves the project's requirements and your aspirations as a developer. Now that you have a goal in mind, it is time to start your project.
When you have your goals in mind, starting from scratch is the next logical step. If you're in web development this will most likely mean picking a framework for your language of choice and creating the project.
If your goal is to learn a new language or framework, this will be a somewhat predefined decision. What language or framework did you intend on learning? Now is a good time to also consider why you want to learn this piece of technology.
If your goal is to learn how to do something using a language or framework you already know, you will most likely want to pick something comfortable here. Don't let this decision be a barrier to the actual goal you set for yourself.
From here, you can continue making tech stack decisions based on what you want to get out of each decision. As I have mentioned, these decisions often come down to wanting to learn something new or wanting to build something specific. Here are a few other considerations:
As you continue to make decisions about technologies you want to use over the span of several different projects, you may find yourself reaching for the same tools time and time again. This phenomenon is what led me to think about this blog post in the first place.
I had a realization that the goals of many of my side projects had shifted from being learning-focused to output-focused and that is not a bad thing.
For example, I had the idea of making a web app to keep track of various places such as restaurants, coffee shops, or museums that you may want to visit in a given city, state, or country. The whole point of embarking on the development of this app was to build this app that I can personally use and share with anyone else who may be interested. I started thinking about the business logic and how things should look and feel in the app then realized that if I couple all of those factors with a new React component library or a new backend technology, I would just be distracting myself from what I actually wanted to do: build something.
So I stopped and looked at the last few projects I had made and noticed that while the purpose and functionality changed, the technologies I was using became constant. I was using the same React framework with the same component library and the same auth provider. These tools had become familiar to me and I enjoyed using them so why should I switch it up just for the sake of using something different?
This anecdote may be unique to me or common to many out there but I bring it up just to say that ultimately it is important to recognize the benefit of finding consistency in your tech stack. It can save a ton of time when you know exactly how to set up each component of the stack and this can be removed as a barrier to actually creating what you want to create. We all know the feeling of having a great idea and then getting stuck in hours of config files that look nothing like the fun you had previously envisioned. If that is how it feels, maybe it is time to isolate the tech stack or even create an individualized tech stack template for future use. That is what I have done recently and I will be sure to cover it in a later blog post.
Selecting a tech stack for your side projects is an important decision that can significantly impact development speed, project success, and personal growth. Exploring new technologies is quite thrilling, but so is seeing your project to completion and not just leaving it as a half-baked idea. Ultimately, these are just my opinions, and there is no right answer. Side projects should be fulfilling to you in some way, and I believe if you start with that goal in mind, then choosing the perfect tech stack can come naturally.
As I mentioned before, I will be following up on this blog post with a summary of a template I made for myself to make answering some of these tech stack questions a little bit easier.