We've accepted specialization in most aspects of modern day society as a good thing. I fail to see, outside a small subset of programming, how you will always be able to write better code yourself for whatever domain you're working on.
> 5) I have a much better sense of what the code is doing this way.
This is not scalable.
It's strange that using fewer third-party dependencies has to be defended on a site called Hacker News.
Also, the code you NIH doesn't have to be superior to the third party code. It merely has to not get in the way for what you're doing. This is different from being "better," which has many dimensions to it. Example that comes to mind: I could reach for something like libuv, or I could just use POSIX for synchronization primitives. I'd prefer to the see the latter in most code unless there were explicit reasons for libuv, such as cross-platform support.
Through practice.
But also, through realizing that when you look closely, many libraries are crap inside.
> This is not scalable.
I specialize in things which do not scale.
To the uninformed what your are doing looks insane. I think people project their fear of the "black box" that is "libraries" and forget that mere mortals like themselves wrote these tools to begin with.
The hard part is knowing when / what to re-use, and most importantly when you are ACTUALLY skilled enough to do it better and it makes sense to do so. There's a confluence of prevailing winds that makes this strategy possible or not possible.
This is what expertise looks like: it isn't Googlable, nor is it ChatGPTable.
You can get a rough idea of the quality of most libraries in about 10-20m typically, usually by playing with the library or browsing the code. Some red flags I look for: lack of tests, excessive number of commits, excessive number of dependencies, lack of focus in scope, etc.
One alternative I use frequently: lock dependencies up in a module, and write some glue code intended to act as the interface to that dependency. It is sometimes the case in which you have to use a library but it is not very good, or it has a horrible bug you can correct by exerting more precise control over how the library is called.
You need to have a working model of how a library works to use it in a performant way, which is why most libraries document their architecture, and have usage guidance.
And you'll find bugs, because there are always bugs. You need some strategy for what to do when that happens.
Fix them, I imagine. Which is easier if you're better at writing code than the author of whatever someone threw on (package manager of choice).