4 ms·
The "other kind of fatigue" mentioned is that we have an overabundance of tools/interest in making ourselves more prolific, but a scarcity of tools/interest in
by matthewtoast 10y ago
The "other kind of fatigue" mentioned is that we have an overabundance of tools/interest in making ourselves more prolific, but a scarcity of tools/interest in improving our code's quality. We chase immediate productivity at the expense of longer-term survival (and happiness).
I agree with this sentiment, but the problem is barely tractable even at a small company working in a closed codebase.
The thing about those disregarded edge cases, which OP uses to exemplify the quality problem, is that there's always an opposite edge! Your fix might be a bug for someone else. There was one particular beautiful, high-quality, generalized, and case-covering npm module, but those very facts about it made it unworkable in one past project of mine, which had strict requirements around footprint size.
It's funny we use the word "ecosystem" to talk about this stuff. An interesting parallel is r/K-selection in ecology, where your species either favors nurturing a small few offspring, or churning out a big swarm and hoping that a few survive. Elephants vs. lemmings.
- innerspirit 10y agoAuthor here. Thanks for the input. I think in some cases it can't be argued that a change is only going to be an improvement, such as in the case of npm lacking proper caching of packages until very recently. In the case of package managers, there are a multitude of them and it's up to the user to figure out which ones have which features, and then go and learn how to use them. It can be time consuming, and I believe it's more important to improve this part of the user experience than to make it easier for people to share their own packages.