I find that the first two points (Use Libraries and Write Libraries) in the way they’re presented conflict with each other and they also go against my personal

I find that the first two points (Use Libraries and Write Libraries) in the way they’re presented conflict with each other and they also go against my personal experience, at least when it comes to robust code. First, using libraries is great but it always comes at a cost so that I’m always performing a cost-benefit analysis before I choose a third party library. The best case is that the library is well-written, well-documented and close to authoritative, meaning it attempts to maximally cover the problem domain (and not just solve small parts of the domain, typically those parts that scratch the itches of the developer). A lot of libraries out there are far from the best case. Most Common Lisp libraries out there are very far from best case. Second, writing libraries or as the CL Style Guide puts it: “In short: write many small libraries (and I’ll add here the implied when solving a specific problem).” This sounds nice in theory but I find that it often falls apart in practice. Most developers that set out to solve a problem are focused on the problem and it’s hard to get them to decompose that problem into libraries that are best-case. Far more typically, if they do end up decomposing the problem into libraries, they will do so in haste and will only do the minimum. Or they may not yet possess sufficient understanding of the domain that would let them write a “best-case” library. This leads to a proliferation of libraries with similar functionality, with no clear “winner”. No clear “best-case” library for others to use. Thus we see the conflict between the two statements. I would reword them as such: + Use third party libraries but perform a cost-benefit analysis before doing so. + Only write libraries (meant for others to reuse) if you are willing to put in the best-case effort. If you are writing such a library, then do attempt to minimize third party dependencies. It makes it a lot easier for others to do a cost-benefit analysis and also more probable that your library will end up used. Choose best-case libraries to depend on. The things we’re trying to avoid are duplication of effort, expansion of the library space with similar libraries - no standouts - that end up confusing newcomers and dependency hell where it becomes expensive to do a cost-benefit analysis.