Just do it - on side projects and the paradox of choice

On Saturday I was talking to a junior engineer who sometimes asks for advice and this time he had a few questions around a side project he is planning to start. He wants a blog with a portfolio and he wants to build it by himself, instead of using an off-the-shelf solution. His idea is to write a web app from start to finish, something he had not done yet. And while doing some work on a Ruby on Rails app, he is primarily writing C for embedded devices. His problem was that he did not know where to start, how to build it and at some point he sounded like giving up before even starting.

This turned out to be a longer conversation than I expected, but let me give you an idea what we talked about, what his thought process was and where he got stuck planning the project.

It started with picking a language and a framework. He knows enough Ruby and Ruby on Rails to do some tweaks on API endpoints and add a controller. So you might think he will just run rails new and starts hacking away. But he heard that RoR is a bit too old school and not used anymore. And that Ruby has problems scaling. Golang or Node might be better. People also talk a lot about Haskel.

Even if he would know which language to learn, how would he deploy it? Serverless? On AWS or Heroku? Maybe a simple virtual private server. Should he use PostgreSQL or MySQL? CloudFlare or CloudFront? Does he need any deployment script or automation?

We all love to play with new, shiny toys. Sometimes we are sick of them and just use the tools we know, because we can make an educated guess if they are capable of getting the job done. And if we are wrong we usually know how to correct our mistakes. But for someone just getting into this beautiful mess, all they see are blog posts explaining a brand new technology that will change everything and solve all the problems other stacks have. Also - obviously - blog posts explaining why the brand new technology is stupid and you should be using something else. You know the drill.

Real talk - it likely* does not matter.

*we are still talking about side projects not meant to generate any revenue or provide a service to a user base**

In this specific case we are talking about a personal website. What is the worst that can happen when it is down? Some people will not be able to read the content you spend a lot of time on creating. This obviously sucks. But you are not loosing revenue. You are not angering any customers. Downtime sucks, but you likely beat yourself up over it way more than anyone else will. We all had systems go down, we all did stupid at some point, but this does not mean you are any less of a professional, especially if you are building a project which is not production critical in your spare time to learn something new.

So which technology should you be using? The one you know. Spin up a blog in RoR, use SQLite and get the project online. SQLite does well for read heavy workloads. It will be fine. You do not need a CDN. If you are worried about server load put Nginx in front of your app and turn on caching. Latency might be a bit higher, but your RoR blog will most likely even survive unexpected exposure handling a few hundred or thousand requests per second. Deployment? `git pull` is good enough for one or two changes a month.

What is more important than getting every detail right, creating a project that represents the pinnacle of engineering, changing the way we think about blogging, is actually starting to build something and finishing it. Even mostly finishing it, but getting it online is a major step.

You can always iterate. Maybe out of necessity if your blog actually goes down way too often, maybe as a learning experience because you really want to know how to setup a load balancer.

But you will certainly have more fun and learn more doing something stupid that blows up than not doing anything.

Thinking about next steps, your stack and how to get from A to B is obviously a skill you should acquire and improve, but do not let it get in your way of actually doing things. Especially things you most likely take way more serious than anyone else who just enjoys them when they exist and / or work.

In retrospect it is easy to see all the things you did wrong and you would not do again. Usually we call this experience. But to actually be able to look back at something you have to start. So when in doubt listen to Shia LaBeouf.

>> posted on July 27, 2020, midnight in software engineering