[kkielhofner]

Often times the right answer is (and should be) "show me you can find and use a use license-compatible library that typically has orders of magnitude more testing in the real world than something you feel the need to re-implement from scratch right now".

The dirty secret is 90% of what happens in the real world (and on HN) is a solved problem that needs to be applied or re-applied. Someone has done it before and they've done it better than you will.

[sirclueless]

There's a difference between "I know how to do this but it would be a buggy mess and require a week or two of effort, therefore I shall use a library," and "I don't know how to do this but this library seems roughly applicable so maybe it will work."

The former is a healthy and pragmatic use of your most valuable resource -- time. The latter is a cop-out. If no one actually understands what is going on at a deep level in the library, the result is likely to be an over-engineered mess. It might be that you're doing the most efficacious and appropriate thing for the task, but it might not. And with many such decisions made over the course of a project, some of them are bound to be wrong unless someone can reason about them and explain their purpose.

I find this is most important when refactoring or updating code. Some junior engineer down the line will encounter some code he doesn't understand, and track down the guy who wrote it, and at this point there is a world of difference between that guy saying, "Yeah, we needed a data structure that does X and Y so we used that library," and "Uhhh, not sure why we used that library, does anything break if you remove it?"

[detaro]

Followed by "show me you can debug and fix said library when we find it it's slightly broken for our use case"