If I on-the-fly estimate that implementing x feature takes too long* and if this seems like a problem others might have solved, I go for a library pretty fast.

If I on-the-fly estimate that implementing x feature takes too long* and if this seems like a problem others might have solved, I go for a library pretty fast. Basically I don't want to implement and maintain something if others have done it for me. Example: I need to parse excel-files in python => straight to looking for a library, I don't even want to start looking into excel-format specs. Example2: I need to parse JSON in Java. First look if Java have this natively (I don't write too much Java) and then go look for a lib. Others must have had this problem, and they most likely solved it as good as or better than me - the surely devoted more time to it, if the bothered to publish a lib. I review if the library project seems alive and being updated. I review if it is super easy to use. Then I include it, no more fuss. Most time I end up checking out 2-4 libs to compare ease-of-use and liveliness etc. I admit that I could do a lot more on security review. Most of the time I fallback to the thinking that this is OSS and/or a widely used lib, and if there was a security issue that I would be able to find, others would have found it by now. *: What too long is varies I guess, but you always have a gut feeling of how troublesome something is to do. Maybe compared to the value of x feature. Thats how it is for most all hobby projects. If it is projects for a client, I worry a bit more about security, but the primary driver for decisions are that others must have solved the same problem and most likely better. And of course in some organisations you'll find it-policies, security policies, dev guidelines etc. that you just need to follow. Then you do that - the client is paying for slow then, by their own choice.