Side Projects Make You Better At Your Full Time Job
In 2014, I had been hearing a lot of talk about Go. It sounded like a really exciting language that I wanted to try.
Having learned to code in Java and spending my early career working in Java, I was used to complex inheritence hierarchies and many many layers of abstraction. The notion of NOT having inheritence was so out there. My gut reaction was to dismiss it.
Yet, I knew at least two devs who I considered better devs than I who loved it. They recommended that I read the Go white paper and I did. It was eye opening. While I was used to complex inheritence hierarchies, I also suffered with those hierarchies for years. I was constantly chasing the perfect way to build a hierarchy. Reading the Go white paper made me realize that there wasn’t one. The composition pattern has its faults, but it seems cleaner 95% of the time.
I didn’t need to write Go to use composition, but I did want to try the language to experience what else it offered.
Unfortunately, there was no good opportunity to do anything in Go with my full time job. We had PHP projects and Java projects with no room to add more.
I decided to take on my first side project. The notion of working without pay was an anathema to me at this point (despite all the overtime I put in my career), but this seemed like a fun project. I enjoyed investing in stocks and always wished I had better tools to manage the data I was consuming. This was the perfect opportunity to try learning Go.
The project itself didn’t get very far (I stopped contributing in 2015), but I learned things that I still use today. I learned how effective the composition pattern was. I learned the handful of cases where composition is actually really painful and having inheritance is easier.
Most importantly, I learned that you can build complex applications without a bloated framework. Never will I have to suffer another Spring upgrade.
Even though I mostly work in Python instead of Go these days, I’ve opted for using Flask which is more like a library than a framework. My experience with Go taught me that life without a framework is simpler. You spend a little more time upfront bootstrapping a project, but your long term development goes way smoother and way faster. Any time you “waste” writing boilerplate code is saved by not having to debug some weird issue with the framework’s abstraction layer. Or dealing with upgrade incompatibilities.
I have worked on a side project ever since then. Every project has given me new lessons that I can apply to the work I do. Let’s look at some of them.
If you have only written code at work, then you’ve probably always inherited a code base. Despite all the contributions and improvements you may have made, there is almost certainly some part of the system that was written for you that you have never touched. That is a gap in your ability to start a project from scratch and launch it. An example for me was login. I had worked on countless web apps. I’ve even improved the login flow for a bunch of them. But I had never built my own login system (or picked a viable third party) on my own. There was a whole host of things to learn.
I had also spent most of my career up to 2015 as a backend developer dabbling in devops. That’s why my first side project only had a CLI instead of a GUI. Frontend development always seemed like a mess to me. It’s also filled with a lot of differing opinions. Working on side projects gave me the freedom to learn frontend development on my own at my own pace with all the noise filtered out. I could try any framework I wanted (Vanilla JS is still not at a point where you can survive without one sadly). I could experiment with the patterns to find one that I liked. In fact, I could rebuild an entire project just to try a new way of designing it.
There is very little chance you can justify doing a full rebuild of an application at your full time job just to learn something new.
Yet iterating is part of the learning process. The core structure of an application is both the most important part to learn to do well and the hardest part to iterate on. Side projects give you the freedom to iterate. Sign up for Dynomantle and you’ll see how far I’ve come on the frontend.
This is also true for automated testing. I’ve worked at plenty of places that had some automated testing, but it was always lacking in some way. Selenium test suites run really slow. Unit tests provide code coverage as a vanity metric, but are insufficient in getting real coverage. No one really knew how to do integration testing.
The project I worked on before Dynomantle was an email client called Maleega. I rebuilt the entire test suite three times. I rebuilt the entire test suite for Dynomantle twice. Each rebuild took many many weeks. Once again, there is almost no way you can justify doing that at any job.
Yet, I have finally come up with an automated testing strategy that works really well (though it has some gaps with testing CSS styles. Does anyone know how to effectively test styling?) I’ve used that strategy for my full time job and it has worked out phenomenally.
Most importantly, if you are in management, side projects keep your programming skills sharp. One of the biggest issues I see in engineering managers is when they have low confidence or certainty in how projects are progressing. Some of them aren’t close to the code anymore and they haven’t kept up to understand much of it when they look at it. The result is a constant need for status updates, which distract your developers, as well as a need to add a heavy handed process in an attempt to get accurate estimates. A lot of mistrust gets developed between the manager and the developers.
There are many ways to mitigate this, but I enjoy working on side projects and one of the benefits is keeping my programming skills sharp. I don’t contribute to the code base at work because my responsibilities make it difficult for me to have any reliable time. That would make being reliant on me for code a liability as we would never know when I could get anything done. Side projects let me code at a pace that fits my schedule without worrying about timelines or meeting company goals.
One thing to clarify is that I’m not saying you have to have a side project. Working on a side project when you don’t want to or will enjoy it is a recipe for burnout.
What I am saying is that if you’ve wanted to work on something but needed some extra motivation, hopefully this post provided some. And if your company is against employees working on side projects, hopefully this post gives you some valid arguments.
If you did, I'd appreciate it if you took the time to check out my product: Dynomantle
Do you struggle with organizing notes, thousands of bookmarks, emails, or other digital stuff? Do you feel bad because you can't copy the habits of "productivity gurus"?
Dynomantle can help. It is a knowledge management tool designed to work with your existing habits. You don't need new habits. Dynomantle works around you rather than have you try to force yourself to work around a tool.
Signup for free!