Abstraction, when used well, is actually a tool that produces more simple code in the long run. It separates different concerns into different pieces of code, makes code readable by extracting common logic and giving it a recognizable name, and reduces boilerplate.
That said, OOP-style inheritance-based abstractions, while useful in some cases, quite often lead people down the complete opposite path - mushing together unrelated logic and then making call sites difficult to understand with a lot of hidden state that has to be kept in mind.
Ha ha ha ha, proper architecture is so exhausting.
The lore is that there was once a proper architecture but that it has been feature crept into oblivion and should have been refactored multiple times by this point. Now all that remains is technical debt.
No one likes you if you point out that the “proper architecture” was obviously inadequate. They also will never fund the rewrite.
*Junior devs
Senior devs are more likely to write one liners from their VIM window.
I’d have thought this a mid-level thing. Most seniors know the cost of complexity and KISS (Keep It simple Stupid).
In my experience, this happens in two ways. Yeah, sometimes a senior just overdoes it due to a lack of experience or shitty requirements or whatever.
But it also happens a lot that juniors just don’t understand why the layer makes sense to introduce. For example, juniors will readily intermix IO and logic, because they don’t yet understand that this makes code untestable and adds a load of additional complexity into already complex logic code. From that viewpoint, pulling all the IO code out will look like unnecessary complexity, when it’s not.
It’s called job security
Thanks Wally.
