Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The art of over-engineering your side projects

elsyms.com

Post reply on HN
Print view View original

131–140 of 272 posts

Re: The art of over-engineering your side projects

#131

Post by jcadam »

I absolutely use my side projects as a vehicle to learn new things... though I always try to pursue ideas that at least appear to have a possible path toward monetization at some point (though I haven't had much success with turning much of a profit from any projects thus far) :)

For my current side project, which I've been working on for a year (and is probably a month or two away from being "beta-able"), I've learned Clojure, Elasticsearch, ES6, mithril.js, Ansible, and have expanded/refined my skills with RabbitMQ, Postgres (or SQL in general), and distributed architecture (not to mention getting to figure out how systemd service and timer configuration files work).

I've really been working hard on it because my current day job doesn't involve any programming, and by the time I get home in the evening I'm really jonesing for some code.

Have my side projects made me a better developer? Without a doubt. Am I any more employable? No, not really - I still haven't figured out how to improve my 'Cultural Fit' via side projects.

Re: The art of over-engineering your side projects

#132

Post by godshatter »

I spent many years before I learned not to over-engineer side projects. I'm a c guy, mostly, so I don't have the stack issues (make and the standard c library and I'm g2g). Now I just start writing code to do the first basic feature, then refactor if needed to handle the second one, rinse and repeat. Once the project takes shape, it gets easier to predict what changes might be needed in the future, and what concessions I can make in the code for them now without slowing me down.

Working this way is much nicer for me. It's more organic. I end up with code that evolves, and takes shape of it's own accord. It makes me feel more creative. The best thing is, I have code that does things. It's not out in the wild, but when I come home from work I have a couple of projects that are coming along nicely to work on and play with.

Re: The art of over-engineering your side projects

#133

Post by kamikaz1k »

tmaly wrote: post #121

I have committed almost all of these mistakes with my food side project https://bestfoodnearme.com . Probably the best thing I have come to understand in building side projects is that you need to get it out in front of people as soon as possible. After that, just get feedback, use analytics, and iterate quickly to fix issues. Even more important, go look for existing problems, whether it be in online forums or talki…

Nice! I actually wanted to do something like for my own food obsessed self. Were you able to get good traction with your project? Or did you just do it for fun?

My biggest hurdle was friction between using instagram and my app. But may that's not what you're targeting.

Either way, I was just curious...

Re: The art of over-engineering your side projects

#134

Post by adventured »

masukomi wrote: post #82

> "Develop your project. Then, put it on the bare minimum architecture that it can run on (be that a 512MB instance from DigitalOcean or a medium instance on AWS). As you get more users, monitor, and modify the infrastructure appropriately to account for load and redundancy." That's a pretty ignorant and potentially short sighted statement. Look at what happened to Instagram. They almost lost it all because they hadn…

> Look at what happened to Instagram. They almost lost it all because they hadn't planned for the possibility of handling scale quickly

That's a problem that essentially nobody has. You're talking such a very small percentage of start-ups or projects, as to be meaningless as a reference point.

Simply put, that isn't a problem you're going to have.

If by some small miracle you have that kind of scaling problem, you can very likely fix it thanks to the fact that you've struck gold.

The number of homeruns that failed because they couldn't scale, is few and far between. There are so few of them, that you're naming one that became a huge success instead of listing some huge prominent failure. First, start with the fact that there are so few of these Instagram rapid hyper-scaling scenarios to begin with, then narrow it down to the percentage that failed due to poor scaling, then narrow it down to the number of those who failed due to poor scaling in the modern cloud era (ie not Friendster from 2004-05). You're very likely down to close to zero examples.

Re: The art of over-engineering your side projects

#135

Post by dev360 »

I've stopped the urge to create repos, buy domain names etc, and started just diving into Sketch to do mockups to flesh out ideas instead.

It gives me pause to think about features and to show people to get feedback. You can also use it as a sales tool to sell an app you are thinking of building without investing weeks and months.

Nowadays its so simple to do nice mockups its so easy to find stencils for SemanticUI, icons etc. Makes it a breeze to get an interface going and I have never been this productive in the 'idea' stage before.

Re: The art of over-engineering your side projects

#136

Post by funnyenough »

on point! cannot agree more - I have been down this road before with my last project - Jabid.com. We tried to boil the ocean even though that was not the goal of the project. This time around, for https://veganfutura.com, I am taking a complete opposite approach, that closely aligns with the list you have provided. Keep it simple, focus on the problem you are trying to solve and the user. Marketing and User acquisition > Tech initially.

Re: The art of over-engineering your side projects

#137

Post by beeforpork »

The best thing about side project is that I may be wonderfully inefficient, so I can do it the way I want and enjoy the way. Even mentioning the word 'deadline' or 'planing' or 'efficient' or 'customer' in the same sentence as 'side project' is contradictory to me.

E.g., I love to program in assembler. Preferably 8 bit SoCs like AVR. The point is not to finish the project fast or even at all by using a more efficient language that may have libraries for everything, but to enjoy programming in 8 bit assembler. Reading the absurdly detailed manuals. Comparing chips at register level. Obviously, I need to write my own libraries/frameworks, because, I want to do that myself, in assembler.

Even if not using assembly, I may still want to write the library myself in order to, well, do that.

Wood workers often seem to have similar ideas about side projects, like when they build a project without power tools, without glue, from old scrap wood, etc., just because. But for some reason, I seldom meet hackers who understand the fun in doing stuff from scratch.

Re: The art of over-engineering your side projects

#138

Post by markcerqueira »

alexandercrohde wrote: post #81
caleblloyd wrote: post #2

Lots 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.

Exactly. When I see a coworker start irrationally focusing on a new technology at work the first thing I think is "This person probably has no side projects to play with"

> "This person probably has no side projects to play with"

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?"

Re: The art of over-engineering your side projects

#139

Post by outworlder »

> 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!

Well, maybe not a 32 node k8s cluster. However, spinning up K8s clusters is so easy now, that it costs almost no time to deploy stuff there. And so many things are taken care for you: configuration, secret storage, networking, versioning, keeping services up, etc.

If on AWS, there's Kops. If on GCP, that's even easier, a couple of clicks and you have a cluster.

Post reply on HN