The art of over-engineering your side projects

Lots of times I use side projects as a way to explore new stacks, deployment approaches, etc. The goal of the project is not to deliver anything, it's to learn so that when I go to do my next "real" project at work, I know what works well and what doesn't.

There's probably another reason hidden in the first sentence, which is that there's a transition from building the product (engineering) to shipping the product (marketing, customer development, sales) that requires different skill sets and experiences. Was just discussing this with a software engineer friend of mine who realizes that he "has no clue how to market my product the right ways."

If your goal is to make money on something, then yes I agree with the author's points. However the whole goal of side projects is to have fun with new languages, frameworks etc.

When I first read the title, I had thought that this would be a humorous example of a delightfully over-engineered side project. It turns out that this is instead a list of 5 common mistakes of over-engineering with some commentary.

> 4. Use frameworks and customise them – only refactor/build your own when absolutely neccessary.

> 5. Build your project first – then worry about continuous delivery.

These contradict each other. Building your own deployment system is just as much of a distraction as building your own CSS framework.