According to Larry Wall, the creator of Perl, one of the three virtues of a good programmer is being lazy. In this regard, he means they look for ways of getting the effect for the least amount of code. The isolation of the library also means that individual components can be tested for correctness and any dependent package on it can be ensured that it “just work” as intended.

That is why we use libraries. Even something as simple as “left pad” can be implemented in many different ways in code when the standard library doesn't provide it. Elegant implementations still add a cognitive load when reading the code:

var leftPad1 = "0".PadRight(5);
var leftPad2 = ("0" + new string(' ', 5)).Substring();

The first example above is more precise, says what it does, and then no more effort needs to be spent on it because that isn't the point of the code. The second, while it also implements a left pad, takes a bit longer to understand and is harder to use.

The same thing happens with using libraries to figure out ANSI codes, handle screen sizing in a console, implementing SSL, or hosting a SSH server. We use libraries to isolate distinct portions of code to make our code more effective by only focusing on what is important.

In my case, the bulk of my development work is putting different concepts (libraries) together into something I think is interesting and useful. A “new” pattern is hard and requires thought, composition is much easier and where the ideas really shine. I also think that most other coders are the same way, we put together blocks.

The drawback of this that we build up a tree of dependencies. In some languages, it can get very deep where a “simple” library ends up composing hundreds of other dependencies—directly or indirectly. When a language doesn't provide a good support, the number of indirect dependencies increases exponentially. When we have different implementations of the same thing, like logging or REST calls, then we also increase our dependencies.