4 ms·

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. T

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 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