Yeah had so many discussion with senior developers in my life to argue for just keeping things simple, but my god they love abstractions.
They are clearly always very smart and understand the code base well.
Maybe it’s their intelligence wanting to be more utilised or maybe they are bored and trying to over engineer simple problems
I would narrow this down further. Programmers (myself guilty) live abstractions they control. It gives them the ability to tweak little things and feel like they've done it in a more maintainable way.
Programmers HATE using other people's abstractions, which is why "mini frameworks" tend to tall apart after expanding to teams that don't have control over it. In my experience, this leads to new mini frameworks wrapping the first one, forever targeting a static version of the underlying MF, to allow for adding new appendages without going through a gatekeeper.
It is easier to write your own code than to understand someone’s else code.
It would be much better if we get more humble people who get down to work to understand why and how existing code or framework works instead of trying to work around it or simply throwing all away and writing their own code.
Thera are of course some exceptions - but those are like pro athletes - no you are not the one, learn existing code instead of making excuses about some edge cases you ran into so you have to rewrite all from scratch.
It's a mixed bag.. If you spend much time in a poorly reviewed ecosystem then you are quickly taught that if you try to make things work in their broken crap you will lose a lot of time and have no code to demonstrate you were working at all.
If you always inject the same repair layer approach of your own crap then you ship more reliably and have your pleased client and your lock-in. The pleased client then has to decide if they should listen to a replacement who says you are insane but can't seem to ship anything.
This view needs to be balanced. There's a lot of cases where the previous code didn't abstract the domain well, or the domain has changed (mostly at the application level). Fighting the ill-fitted abstraction is a real chore in this case and quickly lead to complex code.
I'm all for aggressive refactoring if it leads to something simpler.
It sounds like you are agreeing - that digging into the existing layers can be a good idea that is often neglected or resisted to a fault. That we should treat existing software less like black boxes.
There are caveats here too of course - forking every single thing and excessive NIH syndrome comes with their own costs and risks.
