5 ms·

So many of these points feel like superficial pains that are really quite optional. So many things don’t actually matter beyond offending our sensibilities.

nosefurhairdo 3y ago
They're painful because nobody is willing to argue the "business justification" for cleaning up tech debt, so your management asks you to hack away at the next feature instead. We've inherited a mess that slows us down in ways we can't produce metrics for, so we can't explain with pretty graphs how much more effective we would be if we cleaned up our config and tooling.
- Uehreka 3y ago
  At a previous job where I had to deal with this stuff, I was able to make the case for an “update task” every six or twelve months, where we’d update all of the dependencies, change the config files that needed to be changed, etc. This would require a full-regression test, but this employer was in the business of doing these fairly frequently since they were super risk averse, and so adding another full regression test that only happened every six months or so was no big deal. We’d update a ton of stuff, inevitably break some obscure feature when used in IE11 (which at the time, they still supported), so we’d add a polyfill or chuck a dependency through babel and problem solved. Then nothing for 6–12 more months. This was annoying, but not nearly as annoying as taking inventory at a grocery store or dealing with bad customers at a restaurant. It’s just work, and we were paid to do it.
ghayes 3y ago
I'm not sure if they are all optional, since half of the pain comes from dependencies of dependencies, where you have very little control (esp in the npm world where you can't override resolutions).
- dezsiszabi 3y ago
  You can override the dependency of a dependency in npm. https://docs.npmjs.com/cli/v9/configuring-npm/package-json?v=true#overrides https://docs.npmjs.com/cli/v9/configuring-npm/package-json?v...
james2doyle 3y ago
Not everyone has a choice to not make these decisions. They inherit a project that is already mired in scripts, tools, and dependency hell. If your CI fails because of eslint is it really something superficial and optional?
jfengel 3y ago
They become pain points when you didn't write them, which is implicit in the article. Picking up somebody else's code always sucks, but JavaScript has a way of making it so much worse. There are so many elements, many of which aren't libraries but instead transform your code. If you don't know any one of them you can be completely lost, especially if it is so outdated that you can't get it to work. You could write a similar story for any language, but JavaScript embraces all of them at once.

nosefurhairdo 3y ago

They're painful because nobody is willing to argue the "business justification" for cleaning up tech debt, so your management asks you to hack away at the next feature instead. We've inherited a mess that slows us down in ways we can't produce metrics for, so we can't explain with pretty graphs how much more effective we would be if we cleaned up our config and tooling.

Uehreka 3y ago
At a previous job where I had to deal with this stuff, I was able to make the case for an “update task” every six or twelve months, where we’d update all of the dependencies, change the config files that needed to be changed, etc. This would require a full-regression test, but this employer was in the business of doing these fairly frequently since they were super risk averse, and so adding another full regression test that only happened every six months or so was no big deal. We’d update a ton of stuff, inevitably break some obscure feature when used in IE11 (which at the time, they still supported), so we’d add a polyfill or chuck a dependency through babel and problem solved. Then nothing for 6–12 more months. This was annoying, but not nearly as annoying as taking inventory at a grocery store or dealing with bad customers at a restaurant. It’s just work, and we were paid to do it.

ghayes 3y ago

I'm not sure if they are all optional, since half of the pain comes from dependencies of dependencies, where you have very little control (esp in the npm world where you can't override resolutions).

dezsiszabi 3y ago
You can override the dependency of a dependency in npm. https://docs.npmjs.com/cli/v9/configuring-npm/package-json?v=true#overrides https://docs.npmjs.com/cli/v9/configuring-npm/package-json?v...

james2doyle 3y ago

Not everyone has a choice to not make these decisions. They inherit a project that is already mired in scripts, tools, and dependency hell. If your CI fails because of eslint is it really something superficial and optional?

jfengel 3y ago

They become pain points when you didn't write them, which is implicit in the article. Picking up somebody else's code always sucks, but JavaScript has a way of making it so much worse. There are so many elements, many of which aren't libraries but instead transform your code. If you don't know any one of them you can be completely lost, especially if it is so outdated that you can't get it to work. You could write a similar story for any language, but JavaScript embraces all of them at once.