I think about this question a lot, less because of wasting energy though, and more because of wasting user's time, or battery life, or even wasting your own pro

I think about this question a lot, less because of wasting energy though, and more because of wasting user's time, or battery life, or even wasting your own profits should your product start getting more load than you anticipated! For people who are created product for an end user, being far off from optimal efficiency is very excusable. You have deadlines to hit, you can't afford to iterate forever on the thing, users won't like that either, their want their stuff. But as your software moves further down the stack to being a more fundamental tool: a library, a compiler, and operating system, a database, things that other software will depend on, those things I think deserve way more attention on performance. And of course they generally DO get way more attention. There are some glaring exceptions though, such as the huge degree of inefficiency that popular, interpreted (or badly jitted) languages have. None of that is strictly necessary. Languages could exist with the same productivity as those (maybe more!) with good runtime performance. Another example would be our industry's dependence on using a web browser to build multi-platform guis. We could fix that, and create more efficient, easier to use things. The effort level is very high but the payoff very big. I think looking for those popular, inefficient, software building blocks, and improving them, or replacing them, is the fastest way towards positive change. Another easy leverage point we have is to quit discouraging curious programmers from thinking about performance. I see it all the time here, on reddit, on stack overflow. Using the Knuth quote to discourage performance investigation and curiosity. Let people learn! The cost of writing fast code goes down with practice.