4 ms·

I cannot imagine how projects with hundreds to thousands of dependencies get supported long-term. I think the answer for things built on npm is that it's someo

I cannot imagine how projects with hundreds to thousands of dependencies get supported long-term. I think the answer for things built on npm is that it's someone else's problem and the projects tend to have short lives unless they are super successful to afford constant churn maintenance. There's parables here to fast fashion and all the other crappily made stuff that sells well but end in landfill way before it should, destroying our planet quicker.

TameAntelope 5y ago
I’ve found building “high quality” things is an exercise for people with too much money who don’t really care if what they build helps people. It’s a lot faster and more effective to use free labor from open source projects if what you care about is building useful things quickly.
- hackerfromthefu 5y ago
  Again, the point I am making is short term vs long term. Also I don't believe that e.g. Node is actually faster than more robust alternatives, with large, well designed, stabler, battle tested, base class libraries, that come with consistent homogenous licenses that won't be deprecated. If you are actually skilled at e.g. C# .NET you can go as fast or faster in my opinion, yet still have much better long term maintainability. Respect for avoiding dependencies is the sort of thing you learn when you get longer experience supporting not just initially building systems, and culturally I think the javascript ecosystem attracts people who are junior in terms of that experience.
  - TameAntelope 5y ago
    People who avoid dependencies are, in my experience, junior devs who forget why they get to write software for a living. Senior devs understand the value of delegation, especially outside of the company, for work that isn’t your core competency. You aren’t often allowed on successful and productive teams for very long if you just throw out an entire category of efficiency. I know no dev would last very long on a team I run if they wasted my team’s time rewriting something we could pull off the shelf.
    - hackerfromthefu 5y ago
      You haven't responded to my points about the long term vs short term tradeoffs with dependencies, at all. That is an efficiency tradeoff, with externalities. To be clear of course use of dependencies makes sense according to the situation, with consideration for the tradeoffs of the system. If it's write one and never maintain then use whatever works in the moment. But npm style solutions come with hundreds to thousands of dependencies, which has a real long term cost. Left-pad e.g. is real. You don't seem to be addressing the long term cost at all in your comments. Hammering on people who are judicious about using dependencies, sounds like an application of when all you have is a hammer, everything looks like a nail.
      - TameAntelope 5y ago
        I haven't responded to your points because they aren't interesting or valid points. It is not true that using libraries with many dependencies comes with a (meaningful) cost. The idea that we would or even should build software that "lasts" is probably not right, either. The most effective tech is tech that begins its life with a specific set of criteria for when that tech will be rewritten. Often, specifically early on in a startup's life, that "shelf life" will be months, not years, because the problem you're trying to solve will change fundamentally in those ensuing months. If you're judicious about using dependencies, you are wasting the time of the people around you, full stop. The metric to be measured, as long as you're being paid to write software, is not "elegance", it's "number of problems you've successfully solved". Failing to realize this actively harms your team's ability to execute successfully, and a good team leader will recognize that and correct the problem, either by adjusting your behavior or removing you from the team, if you can't respond to feedback quickly enough. You don't get paid to create beauty, you get paid to provide functionality, and it's a mistake I see a lot of junior devs make.
        hackerfromthefu 5y ago
        It sounds like you've only been exposed to a specific niche of a type of software ala move fast and break things. It seems you're engaging in poor faith discussion here so I'm not going to bother engaging further in this discussion. 1) strawmanning about beauty, a new topic you've introduced to argue against. 2) introduced new things to argue against re whether software should last 3) stating vague things by assertion e.g. interesting/valid instead of discussing the specifics that a meaningful conversation can be made from

TameAntelope 5y ago

I’ve found building “high quality” things is an exercise for people with too much money who don’t really care if what they build helps people. It’s a lot faster and more effective to use free labor from open source projects if what you care about is building useful things quickly.

hackerfromthefu 5y ago
Again, the point I am making is short term vs long term. Also I don't believe that e.g. Node is actually faster than more robust alternatives, with large, well designed, stabler, battle tested, base class libraries, that come with consistent homogenous licenses that won't be deprecated. If you are actually skilled at e.g. C# .NET you can go as fast or faster in my opinion, yet still have much better long term maintainability. Respect for avoiding dependencies is the sort of thing you learn when you get longer experience supporting not just initially building systems, and culturally I think the javascript ecosystem attracts people who are junior in terms of that experience.
- TameAntelope 5y ago
  People who avoid dependencies are, in my experience, junior devs who forget why they get to write software for a living. Senior devs understand the value of delegation, especially outside of the company, for work that isn’t your core competency. You aren’t often allowed on successful and productive teams for very long if you just throw out an entire category of efficiency. I know no dev would last very long on a team I run if they wasted my team’s time rewriting something we could pull off the shelf.
  - hackerfromthefu 5y ago
    You haven't responded to my points about the long term vs short term tradeoffs with dependencies, at all. That is an efficiency tradeoff, with externalities. To be clear of course use of dependencies makes sense according to the situation, with consideration for the tradeoffs of the system. If it's write one and never maintain then use whatever works in the moment. But npm style solutions come with hundreds to thousands of dependencies, which has a real long term cost. Left-pad e.g. is real. You don't seem to be addressing the long term cost at all in your comments. Hammering on people who are judicious about using dependencies, sounds like an application of when all you have is a hammer, everything looks like a nail.
    - TameAntelope 5y ago
      I haven't responded to your points because they aren't interesting or valid points. It is not true that using libraries with many dependencies comes with a (meaningful) cost. The idea that we would or even should build software that "lasts" is probably not right, either. The most effective tech is tech that begins its life with a specific set of criteria for when that tech will be rewritten. Often, specifically early on in a startup's life, that "shelf life" will be months, not years, because the problem you're trying to solve will change fundamentally in those ensuing months. If you're judicious about using dependencies, you are wasting the time of the people around you, full stop. The metric to be measured, as long as you're being paid to write software, is not "elegance", it's "number of problems you've successfully solved". Failing to realize this actively harms your team's ability to execute successfully, and a good team leader will recognize that and correct the problem, either by adjusting your behavior or removing you from the team, if you can't respond to feedback quickly enough. You don't get paid to create beauty, you get paid to provide functionality, and it's a mistake I see a lot of junior devs make.
      - hackerfromthefu 5y ago
        It sounds like you've only been exposed to a specific niche of a type of software ala move fast and break things. It seems you're engaging in poor faith discussion here so I'm not going to bother engaging further in this discussion. 1) strawmanning about beauty, a new topic you've introduced to argue against. 2) introduced new things to argue against re whether software should last 3) stating vague things by assertion e.g. interesting/valid instead of discussing the specifics that a meaningful conversation can be made from