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.
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.
*Junior devs
Senior devs are more likely to write one liners from their VIM window.
Don’t bet on it. Senior devs tend to know there is complexity and pitfalls over time, and hope that by using library X (or following pattern Y) they can future proof the product. So instead of writing 50 lines of self-contained code + tests, some people will happily write 60 lines of integration code + tests, and pull in a dozen dependencies.
However: With appropriate interfaces and a little forethought, you can start with the simple solution and extend it or complement it with libraries or needed abstractions down the road if and when the need arises.
Another bug-bear of mine is being asked to review/run over-engineered one-off programs (eg. simple ETL scripts). I remember replacing about 1000 lines of java (many years ago) with a 20 line python script, and passive-aggressively asking the senior developer to review the new script.
It’s called job security
I feel like true senior devs know this isn’t the way
Only some in my experience, in one place a simple API has 7 layers of handlers and managers. I took care of another project that should be in theory way more complex and got on board in a few days as compared to years.
Highest I’ve seen was 6 layers. Hats off to your team.
Ha ha ha ha, proper architecture is so exhausting.
Holy hell, I feel this viscerally. I recently inherited an enterprise codebase with a new job and that pic is exactly how I imagine the consulting company reacted after hand-off. The code is actually quite clean and mostly makes sense, but it’s completely undocumented (including a lack of specs and XML comments for endpoints). By and large, it’s mostly SOLID, but there are abstractions on abstractions, handlers for handlers for handlers. Configuring to run locally or against the dev environment is a huge rigamarole that I’m trying to simplify before trying to bring on any more SWEs. The bright spot here is that I’ve been given a long runway to come up to speed.
ha I’ll do that on a very large app because it pays dividends, but small apps I go in the complete opposite direction.
