Cull your dependencies

The problem with libraries is that they often contain so much functionality while you yourself might only need a single thing (and don't even realise all the stuff the library is able to do). Whenever I had to patch systems due to some vulnerability my first thought was "Wait, why the hell is a library even able to do that?"

I don't think there's an issue with depending on libraries that are big. If the library is just a big bag of classes from which you cherry-pick the ones you need, then the extrapolation on the number of bugs as mentioned in the article under "By the numbers" is meaningless. Why care about bugs in code you don't use if it doesn't even end up getting linked into your program? In modern languages like Go or Rust, it will most likely not even compile the code you don't care about, assuming it lives in separate packages/modules.

What's a lot more problematic is if you use libraries that don't allow easy cherry-picking. For example, Log4j has a very simple API à la log.print(), but that thing almost acts like a portal into another universe. Strings can contain a whole bunch of modifiers or tags that cause the library to do many special things that are enabled by default. Those libraries are just poor in taste.

Good: Libraries are leverage; as with financial leverage, use wisely to optimize results. At best, a library will be well tested, heavily reviewed, battle-proven code, and therefore worthy of trust.

Bad: Sometimes we convince ourselves that because a library has a large download count, it must be of high quality, and written by people far more qualified than ourselves. Sometimes this is true; sometimes a popular library is written by whoever was willing to write it first (and therefore grow adoption), which might not correlate with the other desirable properties.

Ugly: library authors naturally tend to be quite pro-library, more than the average developer. So they tend to bring in dependencies in unexpectedly large numbers. Your transitive dependency graph can grow unexpectedly large (especially in the npm ecosystem!). Your project can turn into the xkcd cartoon we are all thinking of, a tall tower built on some fragile bits you didn’t even know existed.

Ever work in Finance before?

The first thing I look for when starting a new project is if I can't be served by the standard library in whatever lang I'm using, to find dependencies that don't also depend on a bunch of code that I will have to indirectly depend on. The code I wrote like that still runs like ten years later without much problems having to update it. The code I worked on which depended on whatever flavor of the year framework people were hyped on for no good reason is rotting.