Exploring new technologies that could be beneficial (or harmful) to the company shouldn't be a side project. Perhaps we can shift the thinking from "this person doesn't have time for side projects" to "how can we make exploring new technologies a part of the job?"
Start the day with a "not really a standup", where people can quickly explain what they want to accomplish in the next four hours.
Once a month, you spend a couple of hours of the time demoing the work you have done for each other, explaining the technology and what you have learned, and then discussing and evaluating our individual technical weaknesses and deciding what to do next. This rest of this monthly meeting could also be spent improving social coding skills - code and commit hygiene, team processes etc.
Not only would this keep people technically sharp but it keeps them from playing with toys in production and breaks up the work week, while still fulfilling company goals.
Last week I wrote a utility in Python to parse a configuration file that we had so far been editing by hand, or with bad, slow and cumbersome tools. Now our Linux guys can make the changes is seconds across multiple machines, and the parser is much safer than the bash hacks we had been tempted to use before.
Point being, development time can be great! More companies should embrace the idea of letting their employees improve their own workflow. Some of our best ideas were just that: a little spark that an employee had the opportunity to actually explore.
Part of that is support (though about half of the jobs I've had involved little to no on call duty), part of it is training one self, in addition to everything I have to do during the day.
Let's call it discretionary overtime baked in pay since we're usually salaried.
We know about lots of best practices but if no one is advocating for them at their companies those practices we'll just be shining cities on a hill that we look to from a deep, dark valley.
My side projects are absurdly over engineered and I get nothing done. But I learn what not to do when it matters.
I had a lot of fun doing it, and indeed learnt to not do it in prod, the compiler errors are a nightmare to read and good luck maintaining that in the long run.
There are two types of side-projects though: one such as yours, where you try and understand a concept or engineer something just for the fun of it.
And there is second one: a game that will mature into something; a hobby project that will actually develop into a company. I think it's good to disambiguate these two as the OP was more about the latter where you may never get to a point to see it run or build let alone flourish into something meaningful - as overengineering kills the fail fast fail often mentality and the project itself.
Still, I completely agree with the point that "experiments" should be kept off the critical path as much as possible. It all depends where your risk/reward is, though. The people that took the risk on a stack and got rewarded with success are highly visible. Just as many took the risk and failed. (Probably more?)
Lately I'm pulling back from technical deep diving at work. A lot. My role as an enterprise architect (bleh, don't judge too much plz) means I necessarily have to shift to big picture guff and stop spending time on the details pieces. In short, I don't really get to engineer as much as before.
Of course, I'm an engineer at heart so the idea of ignoring the details is anathema and it frustrates me. When I'm deep in whiteboards, board meetings and shitty powerpoint at work, the side projects and home lab become my release valve. It's a coping mechanism, I think.
Likewise, when I'm sucked into low-level grind at work which happens from time to time, side projects stagnate. I don't need them for a while.
Most of the stuff I've seen done at typical development companies are intellectually interesting maybe to people who really started learning to code on the job, and generally don't have much experience. They're discovering new things every day, so it's fun! However, if someone has already few languages and various types of projects behind them, then the job becomes much less technically challenging and much more repetitive.
But there are also some side projects where you just want to get your hands dirty with some different tech, if you do deliver something then you can showcase it on your portfolio. I know when the app store gold rush first started a lot of people did this as experience to get iOs dev jobs.
More often than not the skills I learn doing this kind of thing end up being very useful to me in the day job.
I'd like it if the side project was successful enough to justify all of that yak shaving, but I don't really expect it to be and I'm not that fussed when it isn't.
But if your primary goal is that your side project should become your day job then the article is pretty good advice. Leave your yak unshaven :)
99% of the time, if you want to go pragmatic, you should buy a ready-made solution (and then possibly adapt it to your use case). It's efficient (especially if you need the problem solved to make money) - but it's no fun.
Considering this is only a side project, you have a high likelihood of abandoning it out of boredom, lack of traction or simply burn out. However, if your side project is "interesting" to you because you are experimenting with various tech, you come back to it because it is fun and it will keep you motivated.
It is totally cool to build something to learn and throwaway, but why not build something to learn that might also generate some income in the future?
Actually starting to livestream them now as I figure if others can see what I'm trying to do I might be able to get instant feedback on how to do things better - crowd sourced learning :)
That's not a problem, that's the goal!
I can't imagine not over-architecting this kind of stuff. I know I'd be in a world of pain several times if I hadn't.
One thing I do not do, is just rebuild something someone else has already done in a new "stack", just to see if I can. Any project I undertake is a new idea I've not seen done, or with features I want.
Should've been titled something like "Don't Over-Engineer Your Side Projects" or "How to Make your Side Project Resemble Your Day Job (If You Work for Sensible People)"
Any kind of project has a "risk budget". If you have few other risks, then you can spend your risk budget on new tools. If you are facing high risks in other directions, it makes sense to stick with what you know.
This article feels like it's written from the perspective of using a side-project to bootstrap a business rather than as a learning experience, hobby or toy.
For a side project, pick one on that you're interested in on each side. For example, maybe try out CircleCI and deploy to Google App Engine. Then you'll learn two new things, maybe one is great but the other is a pain in the ass. You can take the one that works well to a "real" project and talk knowledgeably to the architecture.