Hacker News Reader

Comment by ww520 | Hacker News Reader

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.

View on HN

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

"Don't roll your own… anything"

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.

"Dammit, I went to school for the whole algorithm, I'm gonna implement the whole algorithm!"

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

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.

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

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.

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

Reply on news.ycombinator.com