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

141–150 of 272 posts

Re: The art of over-engineering your side projects

#141

Post by jpfed »

karrotwaltz wrote: post #118
shados wrote: post #104

Earlier quoted context omitted.

100% this. My side projects are absurdly over engineered and I get nothing done. But I learn what not to do when it matters.

I recently built a C++ meta-programming monster for a side project. I want to make an article about that in the near future, and I am somewhat afraid that some people might think of reusing it in a real project. 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.

Maybe the real lesson here is that the last open task on your project is something that can present human-readable digests from parsing the compiler errors...

Re: The art of over-engineering your side projects

#142

Post by nathan_f77 »

I'm currently working on a side-project, and I think I've figured out how to beat over-engineering and just launch a MVP which is actually a "minimum viable product". I'm building the product for my own use, and I'm just building the bare minimum that I actually need to complete the task. After that, I'm planning to bring on my first 10 customers and be available 24/7 to answer any questions and build the features that they need. But only if they're going to pay me money to use those features.

I've often fallen in the trap of "oh that would be cool", but this time I'm going to try to only build the necessary features that actually bring in customers, instead of wasting time on a bunch of useless stuff.

> Over-architecting infrastructure

Yep, I think it's a good idea to just put everything on Heroku until you're spending at least $100 per month. It's just so easy to get up and running.

Re: The art of over-engineering your side projects

#143

Post by outworlder »

majewsky wrote: post #60
elsyms wrote: post #15

Earlier quoted context omitted.

"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".)

> Well, it still takes absurd amounts of memory for what it's doing

Does it though? There's a non-trivial amount of data being loaded (and generated) all the time.

You have mentioned modpacks. Those can be HEAVY. And a single not well programmed block can bring down and entire server.

Re: The art of over-engineering your side projects

#144

Post by patrickmclaren »

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"

IMO, there's room for both approaches, perhaps with the exclusion of the most the irrational situations as you describe. It's unreasonable to expect engineers to bring battle-tested solutions to the table 100% of the time.

Re: The art of over-engineering your side projects

#145

Post by cryptos »

bpicolo wrote: post #24
dtzur wrote: post #16

"Continuously Delivering Nothing" is a mission statement for several companies I know.

Tar it up, cat it to devnull

It is important to compress it with bzip2 or your even better custom algorithm before finally archiving it in /dev/null

Re: The art of over-engineering your side projects

#146

Post by ukd1 »

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.

Boom. This. I wrote a response to this in a little more detail - https://rsmith.co/the-actual-art-of-over-engineering-your-si...

Re: The art of over-engineering your side projects

#147

Post by closed »

markcerqueira wrote: post #138
alexandercrohde wrote: post #81

Earlier quoted context omitted.

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

Agreed. It seems like side projects for work are basically research (and research is important!).

Re: The art of over-engineering your side projects

#148

Post by mark-r »

scott_karana wrote: post #125
kerkeslager wrote: post #49

Earlier quoted context omitted.

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 p…

Those are all client usability concerns, and none of them are stack intrinsic.

I think the point was that user doesn't care about your stack, but they care about the consequences of the stack you've chosen. It's a subtle but important distinction.

Re: The art of over-engineering your side projects

#149

Post by bitwisebob »

hamvocke wrote: post #46

Good 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 t…

Agreed. Having a deployment pipeline in place dramatically reduces the friction of returning to an old project.

I have a back-burner project that touch very infrequently, but I can jump in, make a quick change, and have it deployed to "production" in just a few seconds.

Re: The art of over-engineering your side projects

#150

Post by PaulHoule »

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.

When you are doing a side project you typically have a number of risk factors such as: (A) using new tools, (B) working in a new area, (C) building a new type of application, (D) uncertain marketing, etc.

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.

Post reply on HN