On your side-project it's also ok to ignore best engineering practice, reinvent the wheel because you feel like it or make decisions based on what seems most interesting even if it's not a 'good' decision.
The critical thing is what the author says:
> always make sure that you're doing them for yourself, and for the right reasons
For me my side projects are generally something to have fun with and something to learn new things with. When you're finding it a slog or you feel like you've learnt what what you need to it's fine to just dump it.
Actually finishing something is of course nice and for beginners in particular there's a lot of value in going from that it's mostly there just some loose ends to tie off stage to the actually done stage but you don't have to always do this (or indeed just do it in some select cases).
> On your side-project it's also ok to ignore best engineering practice, reinvent the wheel because you feel like it or make decisions based on what seems most interesting even if it's not a 'good' decision.
Pro tip for enjoying your life at work: this also applies to you work projects. Once you realize this, you can have a lot more fun at work and even coerce work projects to be more like your for-fun/side projects. Of course this is detrimental to the company as a whole, but your company almost definitely does not care about you and you might as well extract as much enjoyment as possible.
If your coworkers are actually passionate about programming (i.e. not drones or PM brains running flowchart to increase quarterly profit), you can even make work more enjoyable for them.
Things like unconventional language choices, over-engineering of systems, unusual coding styles, obscure protocol/library use, and of course a ton of NIH can really spice up a mundane codebase.
Even stretching an "easy" module into a masterfully crafted program and going 4x over estimation can be fun sometimes (without any of the bad design choices suggested above).
Yes I stand by this bad advice, and it's allowed me to play with so much technology I would never otherwise touch at day job.
I will use this when I need to explain the Chaotic Neutral alignment to my D+D players in the future. Thanks!
>> On your side-project it's also ok to ignore best engineering practice
> Pro tip for enjoying your life at work: this also applies to you work projects.
While this may be fun for you and your team, in my experience it makes maintenance more difficult for the next team that inherits the project.
If you're going to do this please consider if you'd find what you're passing on to be acceptable if instead you were inheriting it.
It might be more fun for you than your team, just saying
On the contrary, my side projects tend to have the most strictest linter, test and CI suites. Why? You may ask.
I'll tell you. I forget stuff.
So when I pick up that Openweather tool after three years of not touching it to quickly change the output a bit, I can be pretty sure the overly robust scaffolding around the project won't let me break anything.
That's the beauty of side projects, you get to decide and you don't have to care about working with others.
Really yearning for crafted code that meets every one of your perfect coding style guide and preference with green checks across a huge set of static analysis tools and a large test suite, go for it!
Tired of conforming to your ultra strict style guide at work and code reviews that go in endless circles nit picking about use of spacing or whatever? Let loose and stop having to care/worry so much about the details.