undefined | Better HN

0 pointsjvans3y ago0 comments

> if someone senior writes a lot of overcomplex or abstract code

For me this is a much bigger concern than subtle changes to method names. My biggest headache digging into new codebases is when I run into layers and layers of abstraction that save 3 lines of code but force me to construct an entire mental map of the codebase before I can understand how anything works.

Any tips for giving feedback to senior people here? A lot of the complexity from abstraction is very hard to quantify and experienced people can have arguments that sound reasonable.

0 comments

simplotek3y ago

> Any tips for giving feedback to senior people here? A lot of the complexity from abstraction is very hard to quantify and experienced people can have arguments that sound reasonable.

Perhaps a starting point for this discussion is to point out that the DRY principle is nice and all, but there is also WET. Premature abstractions are bad code, a liability and hinder development. It's always better to have two independent but mostly similar codepaths than a strategy pattern with two concrete implementations. If it's cleaner to copy/paste a method and do some tweaks, do that instead. It's not like you can't refactor it when additional use cases emerge, and if they don't emerge then the abstraction wasn't needed to begin with.

Plenty of people believe that being senior is being clever with complex stuff. It isn't. Being senior is to know you don't need complex stuff, and be able to keep as simple as possible. Abstractions go against that.

konfusinomicon3y ago

the rule of three comes to mind. cleverness is confusion

moomoo113y ago

Is the abstraction so that they can easily swap out pieces of the system without a single headache, or write effective tests, or to make it easy to operate in a soup of services? Because then it makes complete sense.

Like dependency injection is something that a lot of juniors struggle to understand. Or in larger applications DDD and all the crap that goes along with it.

jvansOP3y ago

There's a long list of things that I think are abused in an effort to save on some vaguely defined future cost that never seems to materialize. Some things off the top of my head:

* Interfaces(particularly in java) that have 1 implementation.

* Interfaces with many implementations but where each implementation is used in exactly 1 place.

* large inheritance hierarchies with generic type parameters. I'm sure there's a good use case for this but it's usually a pain.

* Writing "generic" code in an effort to make something re-usable when in reality the code has knowledge of every location it is used in and tightly couples all implementations

cwilkes3y ago

I actually like the “one interface with one implementation” as it makes for less surprises.

With an interface I know that only that method can be called. If a class is passed in i have no idea what methods going to be used. It also gives me a better feeling that the coder has in mind what they need a parameter to do without worrying that they are going to rely on a couple of othogonal methods to be called.

Zanfa3y ago

The "death by a thousand abstractions" problem must be one of the most difficult ones to solve. Each abstraction in isolation makes sense and looks like an improvement, but given a few years, the overall code becomes an inscrutable mess of layers upon layers of complexity, hiding away what it actually does.

Aeolun3y ago

Huh, I have the opposite experience. Any time I push for a little bit more abstraction a lot of people have good arguments for why not.

j / k navigate · click thread line to collapse