Libraries (of code, not books)
I think maybe a million other tech people have written about this, but I'm going to go ahead and not read any of them and instead write my own right now. No offense intended though... Please send me yours if you wrote one.
Like a large number of us tech folk, I've "grown up" in web dev. Most web dev is like foraging for fruits and vegetables. We go out into the forest (npm, rubygems) and just start looking for fruit (libraries). Once we've gathered enough stuff, we stick it all into a pot (write glue code) and hope it all works out (people use the product). Sorry for the lame joke. All I mean to say is that a significant amount of the average web dev's time is spent gathering libraries and gluing them together.
Lately I've been thinking that a lot of the things we use libraries for are ridiculously simple to begin with. Not only that, but when you librarify something, there's often a lot of extra boilerplate involved in making a nice interface and accounting for weird input, etc. I haven't gotten scientific here (...yet) but I suspect that code bloat might have a real impact on the quality of our software. At the very least, I think we can expect longer build times because of it. Anecdotally, I've had several occurrences where a mysterious error is coming from a library, and I'm forced to dig into the source code to find that it's quite large and hard to tell what's going on. A slightly more concrete example is vue-i18n. I once had some trouble with that library, got fed up, and wrote a suitable 150-line replacement in a few hours.
Another thing libraries can do to us is make it easy to write really slow stuff. When something gets "abstracted away" by some interface, it means I no longer need to understand what the something is in order to use it. Like perhaps I don't need to understand relational databases in order to use ActiveRecord. However, that means that when I use ActiveRecord, I'm likely to do slow stuff (n+1 queries and such) without realizing it. Not to mention, I still have to learn how to use ActiveRecord. What if I just learned how to use Postgres or MySQL instead? Those databases are still pretty abstract, so I may still make performance mistakes, but the overall number of things I need to know in order to write good software seems lower than if I had used ActiveRecord, where I need to know how AR works and how the underlying DB works. The only real difference here is the amount of code in my codebase. Abstractions like ActiveRecord tend to produce less code in the main project than raw SQL queries.
Okay, so if we take everything I've said here at face value: abstractions are often slow, require more learning not less, BUT reduce code volume in your project. So that's the plus side - less code. But then remember from earlier if we start digging into library code then it's actually bigger. More code for the computer to chug through, but that's okay because computers are fast and humans don't want to look at code... But is that right? Why don't we like to look at code? I think a lot of experienced devs (myself included) get perverted by the idea of "clean code". We talk about code cleanliness a lot but have no way to define it. If I put SQL queries into my project... ohhh it'll be dirty. We do have stuff like "DRY". DRY's pretty good - we all know how it is when you want to change a piece of functionality but the method you changed is actually copy/pasta'd elsewhere and you didn't know or forgot. But then sometimes we change our mind and say that actually duplication is good because it's easier to read than heavily parameterized stuff. What's the difference? Well, you can find an endless stream of articles digging deep on the various differences. Yet we still write buggy software.
To wrap things up a bit... I think people are better at reading gnarly code than we give them credit for. If you're faced with a decision between pull in a random npm library (which itself relies on 10 more npm libraries) or write gnarly code, maybe try writing gnarly code and see how it goes. So what if it's dirty? You can understand it, right? Show it to a colleague. They might say "eww", but ask them: "you know what it's doing, though, right?" 'Cause that's all that really should matter.