3 ms·

I've run into programmers that always want to make code faster and more "efficient". What is wrong with that thinking is that computing resources are cheap but

by xupybd 6y ago

I've run into programmers that always want to make code faster and more "efficient". What is wrong with that thinking is that computing resources are cheap but programmers are not cheap. Most of the time the more efficient option is readable and maintainable code.

emsy 6y ago
Inefficient software is deployed to millions of users and can cost a lot more time (and resources/energy). Also, I’m fed up by bad software eating up all the performance improvements of modern hardware. It feels like we never got faster CPUs, memory and SSDs. The demand for programming increased but the supply of capable engineers couldn’t keep up and everyone is trying to find excuses for the simple truth: most programmers are incompetent.
- kspacewalk2 6y ago
  >Inefficient software is deployed to millions of users and can cost a lot more time (and resources/energy). Whose time/resources/energy? Not the software vendor's. >most programmers are incompetent. You can't afford the software written exclusively by very competent programmers, optimizing for efficiency/speed/energy usage instead of development time. That'll usually cost you far more than more compute resources/time in the end.
  - hedora 6y ago
    With *aas, the vendor ends up paying for the electricity. Also, paying an army of incompetents to modify a codebase isn’t a sustainable development process. Eventually the code spins out of control. Worse, one of the incompetents eventually accidentally gets promoted, then rapidly hires and promotes more bozos. Ultimately, they eat the organization from the inside like a cancer. (This is well-documented, and has happened to many organizations. Search for “bozo effect” or “bozo explosion” for more information.)
    - bluefirebrand 6y ago
      > paying an army of incompetents to modify a codebase isn’t a sustainable development process. Unfortunately it doesn't have to be sustained long term. Only until you get bought or whatever, the people at the top make their money, the army of incompetents cash in somewhat too if they are lucky, and some poor sucker is stuck with an unmaintainable mess that they just paid a premium for.
- rosmax_1337 6y ago
  Most situations operate on more or less cost vs efficiency basis, no matter if you are a beginner programmer making your first game in Unity or a senior dev at Google. Your code needs to be fast enough to be fast, but not fast enough that you have no time to develop anything else on your project. It seems therefore natural, that as hardware becomes stronger, developers feel less pressure to optimize. Naturally also, it is the developers fault when something is so poorly optimized that it affects the product. Because in the end, we are workers like all other kinds of workers, and we're looking to get a job done, and not done "perfectly". (unless you're hired to optimize servers at Google to the point of perfection) Also, a term I like to mention is that "instant = instant * 0.5". Meaning, if your code is fast enough that it doesn't affect the user experience in the end, and feels "fast". Making it twice as fast has literally no impact. And I doubt server computing cycles is causing energy shortages around the world. We've got other problems causing that.
  - jcelerier 6y ago
    > Also, a term I like to mention is that "instant = instant * 0.5". Meaning, if your code is fast enough that it doesn't affect the user experience in the end, and feels "fast". Making it twice as fast has literally no impact. that makes the very flawed assumption that your program is the only one running on the computer. In practice even if your program does not appear slower, it uses more battery, other software have less CPU time, etc etc
    - username90 6y ago
      Even more important is that it caps the number of features you can add. There are many expensive operations people like to have in text editors, using code that is 10x faster would help with many of those.
- Igelau 6y ago
  It's kind of outrageous the amount of software that seems to be completely inoperable unless you have a SSD.
- xupybd 6y ago
  Yes if you are deploying to millions you need to spend time making your code fast. The vast majority of people are making code for much smaller audiences.
beny23 6y ago
It is very easy to write code that “works on my machine” or “works in QA” and then fails when it hits production volumes or a requirement changes to add more users/elements. Then it often becomes prohibitively expensive to just throw more servers/VMs at it. And often the “expensive” engineer changing a nested loop into a map lookup can save years of compute time in a matter of hours. Unfortunately all too often that only happens after scaling up/out without understanding why systems are slow. Don’t get me wrong, I’m not arguing for needless early optimisation but an inefficient query/algorithm can waste a lot of computing resources...
hedora 6y ago
This is a false dichotomy. It’s easier to make code faster if it is readable and maintainable. The slowest code I’ve encountered was also unreadable and unmaintainable (otherwise someone would have already fixed the obvious performance issues).
- uglygoblin 6y ago
  I've had the exact same experience.
dan-robertson 6y ago
Indeed, the ways to write efficient code are driven by testing and measuring rather than trying to write code that is efficient (probably with silly micro-optimisations) from the start. The importance of readability to efficiency is that it would be good for your code to be obviously linear (or n log n) from reading it. The most significant efficiency improvements typically come from better algorithms or data structures in specific cases. Sometimes improvements to heuristics too. Lesser improvements may come from optimising hot code (eg making it better for the cache) or fundamental language changes (e.g. in a more statically typed language, field accesses may be pointer dereferences, or even better pointer addition, rather than hashtable lookups. But languages like python probably have better tuned general-purpose hashtable implementations than you’ll likely find elsewhere. Also changing default data structures from e.g. linked lists and binary trees to arrays (or something array like) and b-trees (or some other shallow tree) will likely be good)
fpig 6y ago
In my experience, it's the opposite. Inefficiency can be orders of magnitude more expensive than the cost of the added effort to avoid that inefficiency.

by xupybd 6y ago

emsy 6y ago

Inefficient software is deployed to millions of users and can cost a lot more time (and resources/energy). Also, I’m fed up by bad software eating up all the performance improvements of modern hardware. It feels like we never got faster CPUs, memory and SSDs. The demand for programming increased but the supply of capable engineers couldn’t keep up and everyone is trying to find excuses for the simple truth: most programmers are incompetent.

kspacewalk2 6y ago
>Inefficient software is deployed to millions of users and can cost a lot more time (and resources/energy). Whose time/resources/energy? Not the software vendor's. >most programmers are incompetent. You can't afford the software written exclusively by very competent programmers, optimizing for efficiency/speed/energy usage instead of development time. That'll usually cost you far more than more compute resources/time in the end.
- hedora 6y ago
  With *aas, the vendor ends up paying for the electricity. Also, paying an army of incompetents to modify a codebase isn’t a sustainable development process. Eventually the code spins out of control. Worse, one of the incompetents eventually accidentally gets promoted, then rapidly hires and promotes more bozos. Ultimately, they eat the organization from the inside like a cancer. (This is well-documented, and has happened to many organizations. Search for “bozo effect” or “bozo explosion” for more information.)
  - bluefirebrand 6y ago
    > paying an army of incompetents to modify a codebase isn’t a sustainable development process. Unfortunately it doesn't have to be sustained long term. Only until you get bought or whatever, the people at the top make their money, the army of incompetents cash in somewhat too if they are lucky, and some poor sucker is stuck with an unmaintainable mess that they just paid a premium for.
rosmax_1337 6y ago
Most situations operate on more or less cost vs efficiency basis, no matter if you are a beginner programmer making your first game in Unity or a senior dev at Google. Your code needs to be fast enough to be fast, but not fast enough that you have no time to develop anything else on your project. It seems therefore natural, that as hardware becomes stronger, developers feel less pressure to optimize. Naturally also, it is the developers fault when something is so poorly optimized that it affects the product. Because in the end, we are workers like all other kinds of workers, and we're looking to get a job done, and not done "perfectly". (unless you're hired to optimize servers at Google to the point of perfection) Also, a term I like to mention is that "instant = instant * 0.5". Meaning, if your code is fast enough that it doesn't affect the user experience in the end, and feels "fast". Making it twice as fast has literally no impact. And I doubt server computing cycles is causing energy shortages around the world. We've got other problems causing that.
- jcelerier 6y ago
  > Also, a term I like to mention is that "instant = instant * 0.5". Meaning, if your code is fast enough that it doesn't affect the user experience in the end, and feels "fast". Making it twice as fast has literally no impact. that makes the very flawed assumption that your program is the only one running on the computer. In practice even if your program does not appear slower, it uses more battery, other software have less CPU time, etc etc
  - username90 6y ago
    Even more important is that it caps the number of features you can add. There are many expensive operations people like to have in text editors, using code that is 10x faster would help with many of those.
Igelau 6y ago
It's kind of outrageous the amount of software that seems to be completely inoperable unless you have a SSD.
xupybd 6y ago
Yes if you are deploying to millions you need to spend time making your code fast. The vast majority of people are making code for much smaller audiences.

beny23 6y ago

It is very easy to write code that “works on my machine” or “works in QA” and then fails when it hits production volumes or a requirement changes to add more users/elements. Then it often becomes prohibitively expensive to just throw more servers/VMs at it. And often the “expensive” engineer changing a nested loop into a map lookup can save years of compute time in a matter of hours. Unfortunately all too often that only happens after scaling up/out without understanding why systems are slow. Don’t get me wrong, I’m not arguing for needless early optimisation but an inefficient query/algorithm can waste a lot of computing resources...

hedora 6y ago

This is a false dichotomy. It’s easier to make code faster if it is readable and maintainable. The slowest code I’ve encountered was also unreadable and unmaintainable (otherwise someone would have already fixed the obvious performance issues).

uglygoblin 6y ago
I've had the exact same experience.

dan-robertson 6y ago

Indeed, the ways to write efficient code are driven by testing and measuring rather than trying to write code that is efficient (probably with silly micro-optimisations) from the start. The importance of readability to efficiency is that it would be good for your code to be obviously linear (or n log n) from reading it. The most significant efficiency improvements typically come from better algorithms or data structures in specific cases. Sometimes improvements to heuristics too. Lesser improvements may come from optimising hot code (eg making it better for the cache) or fundamental language changes (e.g. in a more statically typed language, field accesses may be pointer dereferences, or even better pointer addition, rather than hashtable lookups. But languages like python probably have better tuned general-purpose hashtable implementations than you’ll likely find elsewhere. Also changing default data structures from e.g. linked lists and binary trees to arrays (or something array like) and b-trees (or some other shallow tree) will likely be good)

fpig 6y ago

In my experience, it's the opposite. Inefficiency can be orders of magnitude more expensive than the cost of the added effort to avoid that inefficiency.