4 ms·

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 bat

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.

deleted 4y ago
[deleted]
coffeebeqn 4y ago
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.
- fullstackchris 4y ago
  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
- DrJokepu 4y ago
  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.
  - coffeebeqn 4y ago
    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
kl4m 4y ago
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.
Akronymus 4y ago
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.

deleted 4y ago

[deleted]

coffeebeqn 4y ago

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.

fullstackchris 4y ago
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
DrJokepu 4y ago
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.
- coffeebeqn 4y ago
  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

kl4m 4y ago

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.

Akronymus 4y ago

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.