4 ms·

Also the "developer's time is expensive" belief pushes developers to reuse layers and layers of packages and libraries whose behaviors are not well aligned with

by ww520 4y ago

Also the "developer's time is expensive" belief pushes developers to reuse layers and layers of packages and libraries whose behaviors are not well aligned with the goal of application, but hey, it's cheaper to just slap something on the existing packages and ship it. The "expensive parts" are pushed to the end users.

andrekandre 4y ago
> developers to reuse layers and layers of packages and libraries whose behaviors are not well aligned with the goal of application, but hey, it's cheaper to just slap something on the existing packages and in many cases those layers and layers actually slow development long-term because of that mis-alignment and needing to untangle/manage the mess of dependencies over time...
userbinator 4y ago
It's ironic when the end users of the software are themselves developers. "Reap what you sow."
spaetzleesser 4y ago
The funny part is that often interviewing is about knowing algorithms. But then it's frowned upon if you actually implement one.
- gfaster 4y ago
  "Dammit, I went to school for the whole algorithm, I'm gonna implement the whole algorithm!"
- tuyiown 4y ago
  While you are right to an extent, I'd rather have someone that can check if the implementation is correct for the use case, wether it's theirs or someone's else, and settles for someone's in first when it fits.
- loup-vaillant 4y ago
  "Don't roll your own… anything"
BuyMyBitcoins 4y ago
Adding on to that, “QA time is expensive” too. I’ve learned from experience that trying to tweak well established repos/libraries rarely gets management’s approval because the extra time it would take to QA and regression test is considered pure loss. Better to leave it be and force the new code to work with the old stuff. That way it is at least billable.
jjav 4y ago
> Also the "developer's time is expensive" Agreed. I really dislike this excuse for sloppy slow code. Yes, developer time is expensive, need to keep ROI in mind. But if the expensive developer spents a week optimizing the function to make it 1 second faster, is that worth it? Too many people will respond "developer's time is expensive" without thinking beyond that. But of course, it depends. If that function is being invoked millions of times per day by hundreds of thousands of people, it very quickly becomes totally worth it.
kaba0 4y ago
I don’t know, should I really reimplement that graph lib in a buggier, slower way, over choosing a battle-tested one that may also contain some additional features I don’t need? According to Brook’s famous paper, code reuse is the only way to significantly improve programmer productivity. No new language will suddenly make you 10x faster, and even that would be meaningless against all the quality code bases out there.

by ww520 4y ago

andrekandre 4y ago

> developers to reuse layers and layers of packages and libraries whose behaviors are not well aligned with the goal of application, but hey, it's cheaper to just slap something on the existing packages and in many cases those layers and layers actually slow development long-term because of that mis-alignment and needing to untangle/manage the mess of dependencies over time...

userbinator 4y ago

It's ironic when the end users of the software are themselves developers. "Reap what you sow."

spaetzleesser 4y ago

The funny part is that often interviewing is about knowing algorithms. But then it's frowned upon if you actually implement one.

gfaster 4y ago
"Dammit, I went to school for the whole algorithm, I'm gonna implement the whole algorithm!"
tuyiown 4y ago
While you are right to an extent, I'd rather have someone that can check if the implementation is correct for the use case, wether it's theirs or someone's else, and settles for someone's in first when it fits.
loup-vaillant 4y ago
"Don't roll your own… anything"

BuyMyBitcoins 4y ago

Adding on to that, “QA time is expensive” too. I’ve learned from experience that trying to tweak well established repos/libraries rarely gets management’s approval because the extra time it would take to QA and regression test is considered pure loss. Better to leave it be and force the new code to work with the old stuff. That way it is at least billable.

jjav 4y ago

> Also the "developer's time is expensive" Agreed. I really dislike this excuse for sloppy slow code. Yes, developer time is expensive, need to keep ROI in mind. But if the expensive developer spents a week optimizing the function to make it 1 second faster, is that worth it? Too many people will respond "developer's time is expensive" without thinking beyond that. But of course, it depends. If that function is being invoked millions of times per day by hundreds of thousands of people, it very quickly becomes totally worth it.

kaba0 4y ago

I don’t know, should I really reimplement that graph lib in a buggier, slower way, over choosing a battle-tested one that may also contain some additional features I don’t need? According to Brook’s famous paper, code reuse is the only way to significantly improve programmer productivity. No new language will suddenly make you 10x faster, and even that would be meaningless against all the quality code bases out there.