I don’t regard efficiency as one obvious thing. Is it single threaded efficiency? Best hardware utilization? If it’s an application that’s guiding external resource utilization, should you even be limiting your efficiency measure to just your code? How often does that code even run? I.e. does its efficiency even make a difference?
And once we define what we mean by efficiency and come to a conclusion that for the code we’re writing improving it will be impactful, recognizing that it’s only one of many worthwhile engineering goals including readability, test-ability, correctness, security, flexibility/adaptability, and time/cost effective implementation, and come to the obvious (though slightly sad) conclusion that at least some of these goals are always in opposition. We can’t really write code that optimizes for all of these things. So now we have to prioritize, and if engineers are taking it upon themselves to decide which goals are most important to them, without considering the needs of the organization (that’s paying them to do the work) to me that’s not a good sign.
Sometimes managers are ineffective and ask people to do dumb stuff. Sometimes engineers like to ignore the fact that by some metrics their work is always going to suck and avoid the mental overhead of having to pick which metrics to optimize for.
Some real examples of these tradeoffs:
* Pure functional code is more straightforward to test and IMO easier to prove correct, but it will likely have more GC overhead than imperative code with mutable variables.
* Techniques like STM can lead to much higher throughput on multi-core systems (while effectively eliminating entire classes of concurrency-related bugs) so you can do more with fewer servers, but it introduces some overhead on each invocation.
* More effective route planning software could be much slower and CPU-intensive to run but that inefficiency may be dwarfed by vehicle fuel savings.
* In the language I work in, monomorphic code (all things being equal) is always faster and more efficient than its polymorphic equivalent, but I often use and implement polymorphic functions so I’m able to handle many types of data down the road.
And once we define what we mean by efficiency and come to a conclusion that for the code we’re writing improving it will be impactful, recognizing that it’s only one of many worthwhile engineering goals including readability, test-ability, correctness, security, flexibility/adaptability, and time/cost effective implementation, and come to the obvious (though slightly sad) conclusion that at least some of these goals are always in opposition. We can’t really write code that optimizes for all of these things. So now we have to prioritize, and if engineers are taking it upon themselves to decide which goals are most important to them, without considering the needs of the organization (that’s paying them to do the work) to me that’s not a good sign.
Sometimes managers are ineffective and ask people to do dumb stuff. Sometimes engineers like to ignore the fact that by some metrics their work is always going to suck and avoid the mental overhead of having to pick which metrics to optimize for.
Some real examples of these tradeoffs:
* Pure functional code is more straightforward to test and IMO easier to prove correct, but it will likely have more GC overhead than imperative code with mutable variables.
* Techniques like STM can lead to much higher throughput on multi-core systems (while effectively eliminating entire classes of concurrency-related bugs) so you can do more with fewer servers, but it introduces some overhead on each invocation.
* More effective route planning software could be much slower and CPU-intensive to run but that inefficiency may be dwarfed by vehicle fuel savings.
* In the language I work in, monomorphic code (all things being equal) is always faster and more efficient than its polymorphic equivalent, but I often use and implement polymorphic functions so I’m able to handle many types of data down the road.