This morning I read this post — “The art of over-engineering your side projects” — and I think it’s missing a few things. Liam’s post covers (imho) what it takes to have a successful side project that-might-be-a-actual-thing-one-day, but not necessarily a fun one.

Think about why you’re doing a side project. Is it for fun? Learning? Shipping something that might be an actual thing? Depending on why you’re doing it depends on how you should approach it. Most of mine are for fun and learning. So with that my rules for side projects;

Keep them fun Keep them simple Be different to what you do day to day (aka, an excuse to try that new-shiny-thing no one at work would love you for)

Lets break down Liam’s post a little.

Mistake 1 — Project managing

Unless you’re actually trying to ship something, avoid this. It’s a waste of time, and normally not fun.

Mistake 2 — Over-architecting infrastructure

So many people are guilty of over-architecting their application’s infrastructure before they even have that application in a state for it to be deployed!

Turns out, this is fun and a good way to experiment with ideas. For instance; if you’re not allowed to use Docker at work yet, why not see what it’s like? It’s not the same as running in production, sure, but next time your boss asks about it, you can give some better feedback about what sucks (or doesn’t). Perhaps you’ll get that project too.

Mistake 3 — Worrying about “tech stacks”

The majority of software engineers seem to be under the illusion that potential customers care about the stack they are running. They don’t. A customer will not know or care if you are using Ruby, Go, PHP or any other language as long as what you have written is performant and is fit for purpose (which all modern languages are). Solution: Write in a language that suits the task at hand and one that you are comfortable/experienced with.

If your goal is to get it done fast and on some kinda actual timeline, sure. But where is the fun in that. It’s true, customers don’t likely care what you’re using…(unless it’s downloaded…).

For this, I’d encourage you to mix it up once in a while. Using a new language is good for you. I’ve recently fallen in love with Crystal (https://crystal-lang.org/) through a side project. It was the same with Go a while back, and we now use that extensively in production at Rainforest QA. Same with Elixir. In-fact, even Ruby.

Mistake 4 — Creating custom frameworks

Bootstrap? Too basic. Materialize? Too fat. Foundation? Nah. Better create my own. A made up statement, but relatively common nevertheless. I have many-a-time started a new project, thought the statement previously and set out writing my own framework. By the time I had completed it, I no longer had any desire to work on the project I had thought of in the first place. Solution: Use frameworks and customise them — only refactor/build your own when absolutely neccessary (and when you have appropriate metrics).

I kinda agree. But; I’ve made this mistake before end turns out it’s fun and you learn stuff. So…eh.

Mistake 5 — Continuously delivering nothing

Similar to the way you can easily over-architect your infrastructure, it’s extremely easy to over-architect your continuous delivery practices before you have anything to deliver! Jenkins, Drone, Travis are all great tools — but you shouldn’t spend time configuring them until you have a working MVP. Solution: Build your project first — then worry about continuous delivery. It’s easy to believe you’re doing the best for your project by doing the above things but you aren’t. The best thing you can do for your project is to market, market, market, and then do a bit of development.

Meh. CI is super easy to get setup; it’s a one time thing and stops you falling (inevitably) into shitty habits you’ll have to fix later. Just use Circle CI and Heroku unless you can’t or you don’t wanna spend $7/mo.