3 ms·

I agree with her that lots of libraries on the internet are bad. But expecting companies to write their own is worse. I remember years ago that everyone wrote t

by _wldu 6y ago

I agree with her that lots of libraries on the internet are bad. But expecting companies to write their own is worse. I remember years ago that everyone wrote their own C string libraries. There were hundreds of them. Most were bad. Then C++ matured and provided a pretty good (and safe) standard string class. Having that standard library was way better than everyone writing their own (mostly bad) string solutions. So it is OK to use libraries, but use well regarded ones that have large, established communities. And don't use libraries for simple small things that your team can do themselves. Her point about depending on others to get your company's work done is a valid one and should be minimized as much as possible. This is why I prefer open source, standard languages and why governments still use C and C++. They are ISO standards that will be around and stable for decades.

fractionalhare 6y ago
I think what it comes down to is the way these libraries are used. In my experience, the trend of software development over time is division of labor into specializations for hard engineering problems, while creating paved roads and happy paths for good generalists. I use the term "generalist" charitably here, whereas the author's description feels (to me) to be a little disparaging. To your point, I think it's good we have this trend in software development. Having all these libraries is a net good which saves time and results in fewer footguns. I believe the problem she is describing is more productively considered by looking at it as a problem of using a vendored library in a way that it isn't designed to be used (i.e. "driving off the paved road"). There are often good reasons to drive off the paved road, but you need to really understand your problem and the solution space to pull it off competently. I think the author's experience is therefore caused by two things: 1. Businesses which are not at Google and Facebook scale, and thus can't afford to build much in-house from scratch. 2. People who try to duct tape APIs together without a strong understanding of the underlying limitations of each library, and the design boundaries of each.
- ilonski 6y ago
  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.
scarface74 6y ago
I remember years ago that everyone wrote their own C string libraries Microsoft by themself have at least 8 types of strings for their various libraries... https://docs.microsoft.com/en-us/cpp/text/how-to-convert-between-various-string-types https://docs.microsoft.com/en-us/cpp/text/how-to-convert-bet...
erichocean 6y ago
> Having that standard [string] library was way better than everyone writing their own (mostly bad) string solutions. The string library in C++ is literally one of its worst libraries. Neither LLVM nor Clang use it.
- tonyedgecombe 6y ago
  You can see this by the number of alternatives, I counted 14 different string implementations in one project I worked on.

by _wldu 6y ago

fractionalhare 6y ago

I think what it comes down to is the way these libraries are used. In my experience, the trend of software development over time is division of labor into specializations for hard engineering problems, while creating paved roads and happy paths for good generalists. I use the term "generalist" charitably here, whereas the author's description feels (to me) to be a little disparaging. To your point, I think it's good we have this trend in software development. Having all these libraries is a net good which saves time and results in fewer footguns. I believe the problem she is describing is more productively considered by looking at it as a problem of using a vendored library in a way that it isn't designed to be used (i.e. "driving off the paved road"). There are often good reasons to drive off the paved road, but you need to really understand your problem and the solution space to pull it off competently. I think the author's experience is therefore caused by two things: 1. Businesses which are not at Google and Facebook scale, and thus can't afford to build much in-house from scratch. 2. People who try to duct tape APIs together without a strong understanding of the underlying limitations of each library, and the design boundaries of each.

ilonski 6y ago
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.

scarface74 6y ago

I remember years ago that everyone wrote their own C string libraries Microsoft by themself have at least 8 types of strings for their various libraries... https://docs.microsoft.com/en-us/cpp/text/how-to-convert-between-various-string-types https://docs.microsoft.com/en-us/cpp/text/how-to-convert-bet...

erichocean 6y ago

> Having that standard [string] library was way better than everyone writing their own (mostly bad) string solutions. The string library in C++ is literally one of its worst libraries. Neither LLVM nor Clang use it.

tonyedgecombe 6y ago
You can see this by the number of alternatives, I counted 14 different string implementations in one project I worked on.