3 ms·
Huh. Experience has taught me the opposite, that any code written in-house is more likely to be undocumented, untested, or buggy than a library used by many oth
by nikisweeting 9y ago
Huh. Experience has taught me the opposite, that any code written in-house is more likely to be undocumented, untested, or buggy than a library used by many others. Especially in the case of a small team that has grown over 5+ years, where things devs write early on quickly become technical debt that few others can understand without the original context. Contrast that to using an import to a documented library where any new dev can quickly go and read the docs & examples and know exactly what it's for. The few cases where a package upgraded something which broke our code have always been easy to resolve by just downgrading the package.
- psyc 9y agoIf this hypothetical library is that good, then it probably meets your version of the general criteria I sketched. One problem is that it isn't always obvious what the quality is at the time you make the decision to take the dependency. I use size/complexity as a proxy for how much trouble it's likely to be.