I haven't responded to your points because they aren't interesting or valid points. It is not true that using libraries with many dependencies comes with a (me

I haven't responded to your points because they aren't interesting or valid points. It is not true that using libraries with many dependencies comes with a (meaningful) cost. The idea that we would or even should build software that "lasts" is probably not right, either. The most effective tech is tech that begins its life with a specific set of criteria for when that tech will be rewritten. Often, specifically early on in a startup's life, that "shelf life" will be months, not years, because the problem you're trying to solve will change fundamentally in those ensuing months. If you're judicious about using dependencies, you are wasting the time of the people around you, full stop. The metric to be measured, as long as you're being paid to write software, is not "elegance", it's "number of problems you've successfully solved". Failing to realize this actively harms your team's ability to execute successfully, and a good team leader will recognize that and correct the problem, either by adjusting your behavior or removing you from the team, if you can't respond to feedback quickly enough. You don't get paid to create beauty, you get paid to provide functionality, and it's a mistake I see a lot of junior devs make.