Doing #5 is chronic because I'm too lazy to handle my own deployments and it's easier to copy paste a generic firebase deploy.
Then you can send the link to anyone and it always just works.
The art of over-engineering your side projects
51–60 of 272 posts
Re: The art of over-engineering your side projects
#52Lots 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.
I learned how not to over-engineer specifically from learning from my mistake of over-engineering my side projects. :)
Re: The art of over-engineering your side projects
#53"Continuously delivering nothing" – exactly what I'm doing, building a product no one will use.
Re: The art of over-engineering your side projects
#54Side projects are meant to be challenging because they are a learning opportunity so it's possible that they end up over-engineered sometimes.
You can always refactor the parts that are over-engineered. There's a very fine line between highly-engineered and over-engineered.
One of my favourite projects is Kubernetes; some might consider it over-engineered but it's extremely powerful.
"Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away"
Re: The art of over-engineering your side projects
#55For the record (it's not mentioned but a lot of time it happens): security (e.g. password storage) should not be something left for later. Do it or use a framework that does it for you.
Re: The art of over-engineering your side projects
#56This makes a lot of sense -- and makes me feel like I'm guilty of over engineering a non-side project I started working on at work ...
I'm always looking to make the code as easy to change as possible -- the idea being that change is a precondition for any form of improvement ... Reading this article makes me wonder if I've turned that pursuit into an anti-goal
Re: The art of over-engineering your side projects
#57Setting up a CI on AWS using git, CodePipeline, Code Build, and elastic beanstalk takes no more than a few hours. It's worth the few hours. Otherwise you're manually pushing builds out which wastes more time in the long. In the beginning your CI should be nothing more than ==> I check in code, it deploys to environment. Later on you can worry about triggering tests and preventing builds for deploying if they fail. Also if you use elastic beanstalk, you can scale as necessarily with a few configuration changes.
Re: The art of over-engineering your side projects
#58I have a personal Jenkins that's been running for years. Adding new jobs isn't yak shaving; it's a two minute task that gives me CD.
Same with my AWS "framework". And my CSS "framework" and my React component superclass and lots of other stuff I carry from one side project to another.
Some would (and have) accused me of over engineering; but I can discover my project is pointless very quickly.
Re: The art of over-engineering your side projects
#59For me it's very important that I don't discuss projects with friends / family / colleagues etc. until I really have something to show. I have always found it very easy to talk all the energy out of a good idea before I've even got any real work done.
I find that exclaiming publicly what it is I want to do has a level of gratification (hey, look at this cool idea!) that would otherwise turn into excitement/anticipation during development. That initial gratification might be enough to stall/kill the project.
To say it another way maybe you didn't actually want to build it just think it through. Rubber duck design and realize it's not the greatest idea
Re: The art of over-engineering your side projects
#60“I know: I’ll create a triple zoned redundant architecture with pub/sub database replication, a 32 node Kubernetes cluster and private networking across all regions – that way, I can handle anything!” The good news is, once you've done that, you can get a pretty decent job. The majority of software engineers seem to be under the illusion that potential customers care about the stack they are running. This is not enti…
"A customer will not know or care if you are using Ruby, Go, PHP or any other language as long as what you have written is performant and is fit for purpose (which all modern languages are)." Where games are concerned I'd tend to agree (though Minecraft was built in Java and was TERRIBLE for the first couple of years, now look at it).
> Minecraft was built in Java and was TERRIBLE for the first couple of years, now look at it
Well, it still takes absurd amounts of memory for what it's doing, which I guess is on par for Java. (On my notebook with 4GB RAM, modpacks fall into one of three categories: "works well", "have to shut off as many OS services as possible before starting" and "forget it".)