Hacker News Reader

Comment by khaledh | Hacker News Reader

YAGNI and KISS.

When I was a junior developer I used to overthink and overdesign solutions, most of which was never needed. It took many years and a lot of battle scars to realize that less abstraction is more. Today I see a lot of juniors do the same mistake and I ask them to revise their designs to keep it simple.

View on HN

I use the rule of threes to kill off any premature abstractions. ie. Don’t think you need to make this generic if you have one or two different variants of it. Most often it’s one- so it’s very easy to see that you’re just solving imaginary problems at this point.

Each abstraction has a mental cost for reading and understanding the code so I try to be sparing. Too many code bases in my youth were a nightmare to navigate because I could never find any actual concrete code.

Also don't forget that code (including the complexity you want to add to it) will probably have only something like an aggragate ~1/3 chance of still being used in a production scenario 5 years or so away anyway (for any number of reason, product change, feature removal, company bought / sold, the list goes on and on...) of course these numbers are anedotal but the point is it can be detrimental to think your code will run as is for the next million years, especially after the first draft

That being said, sometimes a good abstraction can really simplify a complex problem by dividing it up to a set of smaller sub-problems. In such cases, the abstraction is worth it even if there is no reuse. As always, rules like this have to be interpreted in a context.

It’s certainly a rule of thumb, I also prefer to break things down but I try to use functions as the basic units as they’re the easiest to keep in your head when it’s clear what they do

My boss constantly repeats that an 80% solution is what we should strive for, for the most time. It has to be good enough, but not perfect. It's easy to get bogged down by trying to make it the best it can be.

My personal trick: as long as I'm confident that I will be able to refactor in the abstraction, I don't bother. I may or may not ever revisit that code.

Reply on news.ycombinator.com