As one of the generalists, I'd like to add to this comment. I see two kinds of problems: open and closed. Closed problems are sort of "traditional" engineering

As one of the generalists, I'd like to add to this comment. I see two kinds of problems: open and closed. Closed problems are sort of "traditional" engineering problems. They're math heavy, they have a precise, indisputably correct answer, and they probably require some kind of algorithm to solve. These are very challenging and interesting problems to dive into, and I certainly have some interest in them, but they are not my primary interest. I like to use software to solve business problems, which sometimes involve a closed element but more typically are open. They involve human beings and have fuzzy definitions of correctness. I like understanding my users and the weird little worlds they inhabit and how I can make their day a little better. To do that, I need the sorts of tools that the closed problem engineers provide. Now you can absolutely be a great open AND closed problem engineer. I'm studying some more math and algorithms to try to improve at that. I'm also willing to dive in and debug some complex messy library code when I need to, and I do agree it's my job to evaluate the maturity and reliability of a library before I add it as a dependency. All that said, I take issue with the notion that I'm not a good engineer if I choose to outsource some of my problems—especially these closed problems that require a lot of work and experience and attention. Software is not special. In business, every decision involves tradeoffs and opportunity costs. It's completely unhelpful to take potshots at engineers making a conscious choice not to tackle some problem when they can have it solved by someone else. All of that said, you're obviously correct that some people just paste together unstable things they have put forth zero effort to evaluate, and that's a problem.