When that library is, e.g., numpy: absolutely. God help you if you think you're better at linear algebra than BLAS or LAPACK is.

There is only one Kazushige Goto[0].

[0] http://www.nytimes.com/2005/11/28/technology/writing-the-fas...

I am usually in favor of imports over writing my own code, but the honest answer depends on a number of other factors. I don't think there is a "best practice" in this area.

Does the imported function do exactly what you need? No not quite - maybe write your own. Is it a complex function that will require a lot of testing? yes - an import is probably best. Are you likely to use other parts of the imported library in the future? Yes, then import may be a better choice. Will it look good on your CV? Lets face it everyone does it.

Yes, because the primary cost to the company is the cost of developer time, not the download bandwidth cost or the power cost for increased utilization level of the user’s CPU.

The craftsman cares they can accomplish the task without needing a large library. The business cares that it can get to market quickly and profitably at minimal cost. “I prefer your competitor because their code was lovingly hand crafted instead of being shipped quickly with the features I need” said no customer, ever (witness that we all use compilers rather than hand-coding the machine code in an assembler... all the same arguments were made against compiled code back in the day, and compiled code was the right answer, then and now).

This is actually a problem that will fix itself in time. Soon the customer won't be able to run your quickly shipped product because his computer is not powerful enough to run more than 5 electron apps. If we take a browser, a text editor, and chat software as a given, only two more electron apps will be able to compete for the customer's remaining resources.

At which point the customer blames Microsoft for making Windows too slow. The chain of events between your app and their computer’s speed is sufficiently nebulous in the mind of your customers that it’s impact on your success will objectively be zero. I get that you hate Electron apps, and I understand why, but the reality is Slack and VS Code and others have been wildly successful. You might not use them, but millions of others do, and they were fast and cheap to develop.

> The business cares that it can get to market quickly and profitably at minimal cost.

And then the successful business, in contrast, actually looks at total cost of ownership.

We are completely on the same page there, though I would say “care about the risk adjusted total cost of ownership.” Early on, the business doesnt know if the product will succeed so the risk is high and any developer time/dollars invested are disproportionately high risk adjusted TCO. Once the product is successful, the operational costs dominate and the risk factor of time/dollars spent on dev time to optimize the code falls, justifying time spent to improve the efficiency across many measures, but those things don’t kick in until there is some measure of success in the market. Until then, risk adjusted TCO for dev time is very very high and needs to be aggesssively minimized to achieve that minimum risk adjusted total cost of ownership.

The point is that cloud computing costs are small compared to labor costs, so it's a waste of time to make a 0.005% cost optimization that takes a week of work.

I would also love to see some examples of a 2G (!) library that people are casually importing. Where have you had this problem?

Labor costs are capital expenses; computing cost is an ongoing operational expense.

In the end, it depends on return on investment. If it is something which will be deployed on running for years, it may worth the effort.

It's not about developer time. Get over yourselves. It is about how long the user has to wait for a page to load or a compute to finish.

And for that matter, it can take as long to select the library and learn the API as it would have to write the function to begin with.

You say:

> said no customer, ever

and then:

> witness that we all use compilers

Well, strictly speaking, developers are also customers for programming tools' company, and there the tidiness of the code is important. I'm sure there are many other domains where writing your software well is actually encouraged by economic factors :)