When I home-roll I have less downtime usually than relying on a vendor solution. But I have been doing this a very long time so maybe it is an unfair comparison; of course, I’m not so gauche that I am prefixing Dr in front of my name on Twitter.
She co-authored Accelerate: https://www.amazon.com/Accelerate-Software-Performing-Techno... . She is also currently at Microsoft Research and was previously at Google and GitHub. This may be a hot take you disagree with, but she's no newbie.
I took her point to be "make sure anything you build is a lot better than anything you can buy, because there are a lot of unexpected expenses in building".
I haven't read any of them, nor done a google scholar search to see how many were cited, but it sure looks impressive to me.
> I’ll add “if you are inexperienced” to that quote and agree wholeheartedly.
100% agree that experience matters and can teach you when to ignore rules of thumb such as "prefer buying to building." But I've seen experienced developers succumb to the siren call of building their own, say, database pool, when they should not have.
The same thing works the other way as make sure anything you buy is a lot better than anything you can build, because there are a lot of unexpected expenses in buying".
Maybe I'm doing it wrong, but when the software I'm using, bought or built, goes wrong, my customers are mad at me, and look towards me to fix it. I might get sympathy if I claim it's a vendor problem, but they still want the problem fixed. The vendor may or may not be willing or able to fix the problem in a reasonable amount of time, regardless of if they're being paid or not.
My philosophy is not necessarily to avoid using outside software, but to be careful about what to use, because at the end of the day, I need to support the whole system, not just the parts I write.
Nicole Forsgren is legit.