[yen223]

That's a good default to start with, but that's not the whole story.

Every system has its own sets of constraints, and its own sets of goals. Those constraints and goals don't necessarily align with the assumptions made in the library you're using, because it's rare to have a library that does precisely what you need.

When you can't find a library that meets your needs, you have two choices: 1) roll your own solution, or 2) find a library that does something similar to what you want, and coerce the library into a form that suits your needs.

Neither are pleasant options, but I find #1 tends to give a better outcome in the long run. You know what your system constraints are, so you're in a better position to design around them.

[jamra]

I feel like the problem comes down to people not willing to read the docs. Reading the freaking manual helps understand if your tools are precise enough or configurable to solve your problems. Then reading the source code (if possible).

Then, assuming it’s still not worth extending, inventing it yourself isn’t such a bad idea.

[Risord]

On the other hand time required to read and _understand_ the source can be often very compareable to writing specific solution to your problem. Which all comes down to one biggest bottle neck of our industry: sharing understanding of solutions.

[ng12]

In theory, you're absolutely right. In practice, this is the argument used to defend egregious NIH syndrome.

[sanderjd]

And this is the argument used to defend the opposite. Personally, I've found egregious NIH more pleasant to work with than dogmatic anti-NIH.