Naturally, like all engineering, its a balancing act with tradeoffs. We are responsible for all the code that runs in our application, but we are also responsib

Naturally, like all engineering, its a balancing act with tradeoffs. We are responsible for all the code that runs in our application, but we are also responsible for shipping. It doesn't make sense in this day and age to write every line myself, but at the same time it is irresponsible to include buggy dependencies. One of the first things I do when asked to solve a problem or implement feature X is to check around to see if there is an existing solution. Its very likely that I will find something that at least is close to what I want, and from there I evaluate the library, and ask these questions: 1) how complex is the problem that this library solves? How difficult would it be to implement it in my app? 2) How close is this library to what I want? Is it easy to integrate or do I have to jump through a lot of hoops? 3) How bloated is the library? Do I have to include a bunch of stuff in the production build that I'm not using? (not always a problem depending on how the language imports libraries) 4) Is it well written? Is it actively maintained? Github stars and issue backlogs don't say everything but can provide good heuristics. 5) Do I expect that I will need to customize or optimize the underlying behavior in the future? Ultimately, I think the biggest question here is "Is the library working for me, or am I working for it?" If the latter, maybe its worth considering writing it yourself. It also depends on the language and ecosystem for me, not to mention individual libraries. I'm working with javascript primarily right now, and there are a lot of npm libraries that are so small it makes more sense to just copy/paste the code into a utility (after doing due diligence it of course) and iterating on top of it. But it doesn't make sense to rewrite, say, JQuery, or React. edit: grammar