Being skeptical of abstractions is something I have been adhering to for a while in my career, and I have found it to be a successful strategy for long term project health.
This passage really connected with me:
> Asymmetry of abstraction costs
> There’s also a certain asymmetry to abstraction. The author of an abstraction enjoys its benefits immediately—it makes their code look cleaner, easier to write, more elegant, or perhaps more flexible. But the cost of maintaining that abstraction often falls on others: future developers, maintainers, and performance engineers who have to work with the code. They’re the ones who have to peel back the layers, trace the indirections, and make sense of how things fit together. They’re the ones paying the real cost of unnecessary abstraction.
I find this mentality to overlap with (the resurgence of?) discussion on DRY vs WET principles, with some other good links on this including:
It is an abstraction, it's DRY. /s
When I see these kinds of 'refactorings', I ask the author, what are the factors? If they can't immediately answer they didn't have them in mind and were mindlessly refactoring. Common with devs who learn the rules but not the whys.
Refactoring is sometimes what gives tech debt a bad name, you trade one for another without the promised gains. Just because certain divisions were made with seams separating them, what indicates they were the right ones? I prefer to call it factoring (possibly with different factors) with stated factors.