This post hit the nail on the head for me.

Having just finished up a 4-year contracting gig this week, I decided to learn Svelte and recreate a silly little music PoC I made about 15 years ago:

Demo: http://lets-make-sweet-music.com
Github: http://github.com/paulbjensen/lets-make-sweet-music

I started making it about 2 days ago - One of my former colleagues even managed to play the Jurassic Park theme song on it for a bit.

What I loved about working on that side project I think is a couple of things:

1 - I could have an idea, implement it, and push it up right away.

This is a breathe of fresh air compared to the coding process at my last gig. The client had a well-structured process of submitting pull requests which required a code review approval before being merged into the codebase.

That process meant that you essentially spent your day picking up tickets and moving them along, and because people wouldn't necessarily be immediately available to perform the code review, the PR could stay open for quite some time.

That delayed feedback loop and hoop-jumping process adds stop-starts into the coding flow state. You can never get into it the same way you can working on a side project.

2 - The tech stack choices are yours to make and quick to do

The tech stack choices used with the client were made by the tech steering committee and your job was essentially to implement the features required by your product team within the parameters of those tech stack choices. They do that to ensure that there is a consistent use of technologies within the company, to the extent that you can quickly swap say frontend engineers from one team to another whenever needed and they can be productive.

On one hand that is great, but on the other hand you don't have the freedom to try new technologies, or even introduce tooling that you feel is better suited for the requirement.

I even had to justify trying to use Sentry rather than ElasticSearch's Kibana for error logging, even though the client was using both tools within the business.

When you are working on the side project, you can make choices and decisions far quicker and easier - the feedback loop is just much quicker and progress happens faster.

3 - The scope of your input into the side project is far greater

When I worked with the client, I was effectively working as a frontend engineer, because they had a gap in a product team to fill.

However, my skills and experience in my career extended to being a full-stack developer who also liked to work on design work in Sketch and even knew how to deploy to VPS, not just work with a PaaS.

When you don't get to use those skills daily in your client work, they will wither, and you can end up becoming pigeon-holed and institutionalised into a narrow way-of-working, which is a danger to being able to apply the full extent of your capabilities.

So the side projects end up serving as a way to exercise those underused skills. Especially if you relish having creative freedom, which reminds me of something that Paul Graham said about developers - they don't do it necessarily for the money - they do it to have creative freedom.

I haven't found the link to the video, but he touches on it a bit in this post: https://www.paulgraham.com/really.html