> “how much CPU time do I have for running this code?”
When someone asks me something like that, more likely phased like, “how quickly does this need to run”, “how fast does this page need to render”, etc., that’s the engineer I want to work with. Pair that with “how much of a benefit would there be if I get it to run faster” and you’ve got the makings of a superstar.
My experience:
Good engineering is about achieving organizational objectives, while understanding and managing tradeoffs.
People who aren’t asking questions of the above style, either fail to see the real-world purpose of their work, or they fail to accept that when doing even semi-competent work, the decisions they make tend to have both positive and negative consequences.
Without understanding those two things, it’s tough to be effective over the long term.
You say that good engineering is about achieving organizational objectives. I say that competent management is about setting organizational objectives. Therefore, you're saying that good engineering is about satisfying competent management. From this POV you see increasing efficiency beyond the level required by management as the opposite of being effective. This is correct from the angle of the game played in the org. This is not necessarily correct from shareholders/other stakeholders' POV - sometimes it is, sometimes it isn't.
But I agree that going against the grain of managerial objectives will make you ineffective in the long term - management will see to it. You need to do less of this or find less competent management if you want to do more of this.
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.
When someone asks me something like that, more likely phased like, “how quickly does this need to run”, “how fast does this page need to render”, etc., that’s the engineer I want to work with. Pair that with “how much of a benefit would there be if I get it to run faster” and you’ve got the makings of a superstar.
My experience:
Good engineering is about achieving organizational objectives, while understanding and managing tradeoffs.
People who aren’t asking questions of the above style, either fail to see the real-world purpose of their work, or they fail to accept that when doing even semi-competent work, the decisions they make tend to have both positive and negative consequences.
Without understanding those two things, it’s tough to be effective over the long term.