I recently had this with a html5 project. Thought it would be nice to use es6 and transpile, then disappeared down a hole of gulp and webpack.
Eventually backed up and used Make to run Babel and then cat the files together.
The art of over-engineering your side projects
41–50 of 272 posts
Re: The art of over-engineering your side projects
#42Related to this, I've been following a practice I call "Release Notes Driven Development", which is perfect for side projects. Don't worry too much about technical debt (although, keep it under control), but focus on the little time you have and how to make that as efficient as possible.
I wrote about it here; https://ma.ttias.be/release-notes-driven-development-rndd/
Re: The art of over-engineering your side projects
#43#3 hits home. I've been "working" on my side project for 3 years now with almost no progress because I'm constantly intrigued by new frameworks and BaaS. I spend all my time tinkering with them until I get bored with it all together. If I had just built the thing in Rails from the start I'd probably have a solid app under my belt by now.
Time for a new branch with rails then!
Re: The art of over-engineering your side projects
#44Oddly enough, I would apply some of these practices to real projects as well.
Re: The art of over-engineering your side projects
#45Re: The art of over-engineering your side projects
#46Good points in there. I have a little trouble with "mistake #5" though.
I found that worrying about deployment automation early on is immensely valuable, especially for side projects. I don't always find time or interest to keep working on side projects after a regular day of work. Quite often there are weeks or even months where I abandon a side project only to come back at a later point when motivation is back or things have settled down and leave more time for my side projects. If I didn't take the time to automate testing and deployments (which makes a lot of what continuous delivery is about) I find myself struggling with getting things up and running and become frustrated before I even get started.
Then there's only one way to make sure that my test and deployment automation keeps working: running it regularly, e.g. in a pipeline.
So, yes, don't over optimise your deployment pipeline early on. But having one in place early can pay off really soon -- and maybe even keep your side project alive.
Re: The art of over-engineering your side projects
#47I can tell this article was written by a very wise man who wasted time on lots of projects or saw a lot of other people waste time on projects. He's described behaviors I have dabbled in many, many times.
In fact, I have a side project currently where I just needed to fabricate a tiny fixture for a physical device. I caught myself over-engineering the prototype, went to sleep, woke up, saw this article and came to my senses. Consider this article bookmarked!
Re: The art of over-engineering your side projects
#48Man, I think this article is dead on, except it doesn't identify the original reason, for me at least. In a normal environment, there are constraints on time, money, goals, resources, etc. Suddenly, when there are no constraints, a side project, you try to do everything perfectly, which leads to the issues in this article.
Re: The art of over-engineering your side projects
#49“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…
Potential customers do care about the stack you're running. They care if they have to download Java or Flash. They care if they have to be connected to the internet or can use your product offline. They care if your program starts quickly. They care if your program runs quickly once started. They care if your program has bugs (let's not pretend different languages aren't more or less error-prone). They care if your program is cross-platform. They care if your UI is consistent with their platform. They care if your product releases new features quickly.
All of these are stack-related.
Re: The art of over-engineering your side projects
#50For 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.
That's a thing. Expressing in public your desire to achieve something makes you less likely to deliver. http://www.psych.nyu.edu/gollwitzer/09_Gollwitzer_Sheeran_Se...
The weird thing is the same situation works in reverse as well.
Publicly declaring your intention to quit a habit or lose weight has also been shown to increase success in some instances.
I think it depends on whether people reward you with positive regard for stating an intention to do something, and whether you look foolish if you don't do the thing you stated. When you can get the reward just for the statement and there is no consequences for failure, pre-stating your intention seems harmful. On the other hand, if you are not rewarded for pre-statement, and failure is embarrassing, pre-stating your intention seems helpful.