4 ms·

There’s an entire category of developer that concerns themselves with stuff like this, and I wonder if they know you can be a successful dev and not care one bi

by Zetice 4y ago

There’s an entire category of developer that concerns themselves with stuff like this, and I wonder if they know you can be a successful dev and not care one bit about taking your imports this seriously, and instead just grabbing libraries from npm. It strikes me as the difference between knowing why your role exists and not realizing you deliver organizational value, over engineering perfection.

HeavyFeather 4y ago
Speed brings value. Loading dash without optimizing it carries a huge weight. Weight can slow down users. Users leave the cart before completing a purchase. Lodash is engineered to deliver “perfection” and performance, to an absolute fault. Try `import {unary} from 'lodash'` and tell me how big the bundle gets. FYI unary should be `fn => x => fn(x)`. On the other hand, copy-pasting actually-useful utilities like groupBy from some random site defeats the purpose of npm. Luckily there are sane Lodash alternatives like Just: https://github.com/angus-c/just https://github.com/angus-c/just
- Zetice 4y ago
  > Loading dash without optimizing it carries a huge weight. This doesn't pass the smell test for me, considering how small the library as a whole is, and the many, many use cases that would not involve exposing the code to the user at all.
  - boredtofears 4y ago
    It's not that small: https://bundlephobia.com/package/lodash@4.17.21 https://bundlephobia.com/package/lodash@4.17.21
    - Zetice 4y ago
      Per your citation, at 875 kB/s it takes 28ms to download. I'm gonna leave that in the "small" category for now, considering 516.25 kB/s is about what Cuba averages on mobile, ranked last in the world. [0] [0] https://www.speedtest.net/global-index https://www.speedtest.net/global-index
      - boredtofears 4y ago
        28ms isn't small trade-off if you're pulling it in for a one off utility function. Not calculating these types of trade-offs is exactly how you run into mammoth bundle sizes when you're a year or more into development.
        Zetice 4y ago
        28ms is a small trade off. Sorry, but it is, and this is exactly my point; you don't have to give a hoot about 28ms and you can still be a very effective developer. In fact, I find it hard to think of an effective software dev who does care about 28ms without having specific reason to, due to a niche use case (not a generic web app for Internet things, like a hospital instrument that needs every ms).
        boredtofears 4y ago
        ..and when you've added a couple dozen of these you're sitting at half a second. Indeed, I guess we just develop different classes of applications. I don't know what a "generic web app for Internet things" is.
        Zetice 4y ago
        Who here is suggesting you add a "couple dozen" of dependencies like this? And you're on a "generic web app for Internet things". This page loading 27ms slower would not be perceptible.
        boredtofears 4y ago
        If you're not evaluating every package you're adding to your manifest how would you prevent that scenario from happening? Personally I've never worked at a product where response time wasn't an important metric.
        Zetice 4y ago
forgetfulness 4y ago
Considering that a bigger engineering and social problem in the Javascript world is the plague of micromodules of dubious provenance, arguing against using solid and trustworthy utility libraries is counterproductive, or even symptomatic. Using libraries like lodash, instead of adding 12 left-pads of different authors to the dependencies manifest, is an improvement over the status quo.
whstl 4y ago
An important role of developers is knowing which tools exist and what can be used to provide value. To use Lodash, a developer needs to know what is available there in the first place. You're taking it for granted, but everyone, you included, had to study its documentation and memorize which functions were there, even if it was only to "look it up" later. Someone like you could have said a few years ago about Lodash: "why do I need this stupid library, I will just use for loops everywhere, like I learned in college. They get the job done and my role is to provide value, not to care about libraries or code reusability". With this website, it's the same thing: it's there to teach you which things in Lodash aren't needed anymore and which are. Then it is up to the developer to use what's best. Not everything in the internet is prescriptive. Blind dogmatism shouldn't have a place in our profession.
- Zetice 4y ago
  That's kind of my point, though? Caring about "blind dogmatism", one way or another, is not required to be a highly effective software dev. For example with lodash, the process for deciding to use it could be, "Hey this looks like it could save me time, let's try it." That's it. You don't have to go on this large, multi-hour/multi-day journey discovering every little thing about it first. I'm arguing here that highly effective developers are able to use software to solve business problems favoring efficiency over correctness. And I'm not sure it's efficient to care much about whether or not lodash could be rebuilt internally.
  - whstl 4y ago
    You say "one way or another". What is the "another" way, and who's advocating it? This page is NOT an invitation to rebuild lodash on every single project. It is not a prescriptive website. It is teaching material. This page is here, for example, so that people who only know about Lodash can know how it's implemented. If they ever start working on a no-Lodash project, they might not need to import Lodash. This is not a call-to-arms to uninstall Lodash from all projects and replace with hundreds of functions. Why would it be?
    - 4y ago
usea 4y ago
You can be a successful dev without doing a good job. Many people just want to do a good job and don't particularly care about being "successful." It's not that your coworkers don't know you can get away with doing a bad job, it's that they're not motivated by the same things that you are. It's true that in some contexts, throwing npm libraries at the wall to see what sticks is delivering organizational value. In many others, it's negative value.
- Zetice 4y ago
  That's the point; there is no "successful dev" without "doing a good job". The folks who don't care about being "successful" are not "good devs", because they're not clear about why their job exists in the first place. You don't really get to define success for your role without your organization's input, and when you overly focus on the engineering to the exclusion of delivering value, you are not acting as a "good dev".
  - usea 4y ago
    Hitting metrics or whatever else causes you to be successful in your organization is not the same as doing a good job. It is possible, for example, to get raises and promotions while ruining your company and destroying all value for your customers. It is also possible to be the only one delivering any value, while actively working against organizational goals. Management, or whoever else is defining success for you, is not infallible. Intrinsic motivation is a real thing. You don't have to let your boss or your parents or your teachers tell you what it means to do a good job. You can decide for yourself. People who just grab libraries from npm and don't take their imports seriously are not the ones delivering value in the places where I've worked. Far from it. Those are the people whose "work" you have to re-do weeks or months later because it didn't actually deliver value. Often times it doesn't work at all, never worked, never compiled, etc. But those people are long gone because they're busy being "successful" and moving on to other roles, creating negative value in other parts of the organization. You say that only successful people know why their job exists, and unsuccessful people are blind to organizational value. In my experience, you couldn't be more wrong.
wellanyway 4y ago
[flagged]
boredtofears 4y ago
this attitude is how you get average client payload size measured in the tens of megabytes

by Zetice 4y ago

HeavyFeather 4y ago

Speed brings value. Loading dash without optimizing it carries a huge weight. Weight can slow down users. Users leave the cart before completing a purchase. Lodash is engineered to deliver “perfection” and performance, to an absolute fault. Try `import {unary} from 'lodash'` and tell me how big the bundle gets. FYI unary should be `fn => x => fn(x)`. On the other hand, copy-pasting actually-useful utilities like groupBy from some random site defeats the purpose of npm. Luckily there are sane Lodash alternatives like Just: https://github.com/angus-c/just https://github.com/angus-c/just

Zetice 4y ago
> Loading dash without optimizing it carries a huge weight. This doesn't pass the smell test for me, considering how small the library as a whole is, and the many, many use cases that would not involve exposing the code to the user at all.
- boredtofears 4y ago
  It's not that small: https://bundlephobia.com/package/lodash@4.17.21 https://bundlephobia.com/package/lodash@4.17.21
  - Zetice 4y ago
    Per your citation, at 875 kB/s it takes 28ms to download. I'm gonna leave that in the "small" category for now, considering 516.25 kB/s is about what Cuba averages on mobile, ranked last in the world. [0] [0] https://www.speedtest.net/global-index https://www.speedtest.net/global-index
    - boredtofears 4y ago
      28ms isn't small trade-off if you're pulling it in for a one off utility function. Not calculating these types of trade-offs is exactly how you run into mammoth bundle sizes when you're a year or more into development.
      - Zetice 4y ago
        28ms is a small trade off. Sorry, but it is, and this is exactly my point; you don't have to give a hoot about 28ms and you can still be a very effective developer. In fact, I find it hard to think of an effective software dev who does care about 28ms without having specific reason to, due to a niche use case (not a generic web app for Internet things, like a hospital instrument that needs every ms).
        boredtofears 4y ago
        ..and when you've added a couple dozen of these you're sitting at half a second. Indeed, I guess we just develop different classes of applications. I don't know what a "generic web app for Internet things" is.
        Zetice 4y ago
        Who here is suggesting you add a "couple dozen" of dependencies like this? And you're on a "generic web app for Internet things". This page loading 27ms slower would not be perceptible.
        boredtofears 4y ago
        If you're not evaluating every package you're adding to your manifest how would you prevent that scenario from happening? Personally I've never worked at a product where response time wasn't an important metric.
        Zetice 4y ago

forgetfulness 4y ago

Considering that a bigger engineering and social problem in the Javascript world is the plague of micromodules of dubious provenance, arguing against using solid and trustworthy utility libraries is counterproductive, or even symptomatic. Using libraries like lodash, instead of adding 12 left-pads of different authors to the dependencies manifest, is an improvement over the status quo.

whstl 4y ago

An important role of developers is knowing which tools exist and what can be used to provide value. To use Lodash, a developer needs to know what is available there in the first place. You're taking it for granted, but everyone, you included, had to study its documentation and memorize which functions were there, even if it was only to "look it up" later. Someone like you could have said a few years ago about Lodash: "why do I need this stupid library, I will just use for loops everywhere, like I learned in college. They get the job done and my role is to provide value, not to care about libraries or code reusability". With this website, it's the same thing: it's there to teach you which things in Lodash aren't needed anymore and which are. Then it is up to the developer to use what's best. Not everything in the internet is prescriptive. Blind dogmatism shouldn't have a place in our profession.

Zetice 4y ago
That's kind of my point, though? Caring about "blind dogmatism", one way or another, is not required to be a highly effective software dev. For example with lodash, the process for deciding to use it could be, "Hey this looks like it could save me time, let's try it." That's it. You don't have to go on this large, multi-hour/multi-day journey discovering every little thing about it first. I'm arguing here that highly effective developers are able to use software to solve business problems favoring efficiency over correctness. And I'm not sure it's efficient to care much about whether or not lodash could be rebuilt internally.
- whstl 4y ago
  You say "one way or another". What is the "another" way, and who's advocating it? This page is NOT an invitation to rebuild lodash on every single project. It is not a prescriptive website. It is teaching material. This page is here, for example, so that people who only know about Lodash can know how it's implemented. If they ever start working on a no-Lodash project, they might not need to import Lodash. This is not a call-to-arms to uninstall Lodash from all projects and replace with hundreds of functions. Why would it be?
  - 4y ago

usea 4y ago

You can be a successful dev without doing a good job. Many people just want to do a good job and don't particularly care about being "successful." It's not that your coworkers don't know you can get away with doing a bad job, it's that they're not motivated by the same things that you are. It's true that in some contexts, throwing npm libraries at the wall to see what sticks is delivering organizational value. In many others, it's negative value.

Zetice 4y ago
That's the point; there is no "successful dev" without "doing a good job". The folks who don't care about being "successful" are not "good devs", because they're not clear about why their job exists in the first place. You don't really get to define success for your role without your organization's input, and when you overly focus on the engineering to the exclusion of delivering value, you are not acting as a "good dev".
- usea 4y ago
  Hitting metrics or whatever else causes you to be successful in your organization is not the same as doing a good job. It is possible, for example, to get raises and promotions while ruining your company and destroying all value for your customers. It is also possible to be the only one delivering any value, while actively working against organizational goals. Management, or whoever else is defining success for you, is not infallible. Intrinsic motivation is a real thing. You don't have to let your boss or your parents or your teachers tell you what it means to do a good job. You can decide for yourself. People who just grab libraries from npm and don't take their imports seriously are not the ones delivering value in the places where I've worked. Far from it. Those are the people whose "work" you have to re-do weeks or months later because it didn't actually deliver value. Often times it doesn't work at all, never worked, never compiled, etc. But those people are long gone because they're busy being "successful" and moving on to other roles, creating negative value in other parts of the organization. You say that only successful people know why their job exists, and unsuccessful people are blind to organizational value. In my experience, you couldn't be more wrong.

wellanyway 4y ago

[flagged]

boredtofears 4y ago

this attitude is how you get average client payload size measured in the tens of megabytes