[alwaysbeconsing]

Frankly I think everyone should have this attitude, seniors as well. (I try to) I am experienced but I know I write bugs and code that may be not as clear as it could be. We all do: we're only human.

Also depending on the codebase (and language to some degree), if someone senior writes a lot of overcomplex or abstract code that the rest of the team can't understand/maintain, that's just as much a problem as anything else.

[jvans]

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

[simplotek]

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

[konfusinomicon]

the rule of three comes to mind. cleverness is confusion

[moomoo11]

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.

[jvans]

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

[cwilkes]

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.

[Zanfa]

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.

[Aeolun]

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.