Live data from Hacker News

The art of over-engineering your side projects

elsyms.com

71–80 of 272 posts

Re: The art of over-engineering your side projects

#71
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 only because java has no value types/struct like data structure.

the reason why this makes memory so heavy is because even a simple int list, needs boxing. So you end up with a big chunk of garbage which you don't need. On the server, this is not a problem because most of the time the list is a young gen object and die really fast, so G1GC solves most problems. The problem of course is really big, because arrays are a pain to work with and not many people do that.

However as soon as java 10 hits, we might get value types and maybe this changes the game (but we will see, since it would've taken way to long for that thing). Also there are more and more types inside the standard library who would be great value types, i.e. LocalDate/LocalDateTime, but at the moment they take way more memory than needed, especially since they only contain 2 immutable shorts and 1 immutable int.. in the perfect case it would be something like 8 byte, however it takes way way way way more. (basically a simple class at least takes 16 bytes, which is already double the field size, so you end up with 24 bytes [probably more due to various other stuff])

btw. for a game like minecraft you probably have a lot of types that follow the same stuff like LocalDate, small class with immutable int's/short's for position, etc. these have the same problem and will fill the memory more quickly than needed

Re: The art of over-engineering your side projects

#73
post #66

I believed over-engineering IS the point of personal side-projects.

I'm in the opposite camp - personal side-projects are where you can safely implement the MVP and/or ruthlessly chop things/ideas that never* get used without people harassing you about bells and whistles.

Re: The art of over-engineering your side projects

#74

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

> "[...] when there is nothing left to take away"

I've always taken that quote to apply only when you have been taking things away; not when you've ended up with a colossal complex monstrosity where removal of any single strand would cause total collapse.

Re: The art of over-engineering your side projects

#76
post #42

Related 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/

Sounds good. Early on, a quick list of bragables should be able to tell you how awesome the idea is. Have new bragables for the next version. If its not awesome at some stage (and the bugs are fixed) you are probably done?

It reminds me of many release notes describing a ton of work without any woah.

Re: The art of over-engineering your side projects

#77
post #28
post #11

Earlier quoted context omitted.

Why do you need a deployment system if you have nothing to deploy? Build the project locally, then use continuous delivery when you have something to deliver.

"Build the project locally" implies some kind of pipeline system, even if it's not "deployment" or "delivery". Triggering that pipeline from a commit trigger instead of manually just means copying the build command into a config file. It pays for itself in the first hour.

`git push deploy`

You can get quite far without any kind of "pipeline system" nor does building imply a pipeline.

Re: The art of over-engineering your side projects

#79

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.

I often explore new stacks by building a product that already exists complete with identical css! For example: Wanna try out aiohttp, vue & css grids? Let's build a Slack clone!
Post reply on HN