Somewhat agree, but the thing most forget when talking about abstractions is that the abstraction of the code depends on the abstraction of the domain.

If you're building cars, the abstraction is a car factory, but this depends on knowing that your domain can be abstracted to cars. If your domain is instead vehicles and you later need an airplane, your car factory was the wrong abstraction.

Abstractions are powerful tools in software, and they're mostly under-utilized because businesses largely do not understand them, and they tend to select engineers that would rather not abstract and instead duplicate code and logic all over the place. The main idea behind abstracting is leveraging the power of software to call an existing function. If you keep building on this "tower" correctly (albeit hard to do and requires specialization), you reap huge rewards by automating large parts of the pipeline.

Good thread. I like to pull bits and pieces out of different frameworks, and make them my own proprietary blend, based on cycles/where I'm at in life/goals.

And then that allows me to course-correct based on external events when need be.

So I completely agree: Being overly dependent on one framework leads to complacency, stagnation, plateau, etc.