I agree with your point. However, I think I look at it from a slightly different perspective.
When it comes to any code I produce (with the exception of some learning projects), I try to keep it: effective, efficient and simple. In that order.
Effective is essentially what you were saying about correctness and usability from the user perspective. Peter Drucker would say to be effective is to "do the right thing." This is always an outward focused item. Does it impact the user in the right way? Does it solve the right problem? Etc. This is hands down the most important thing. Nothing else matters if you're doing the wrong thing.
In contrast, efficiency is to "do the thing right." Once you're doing the right thing, minimizing your costs, increasing your quality, making it so your code doesn't "consume the whole world" all fall under this category. Poor efficiency can negatively impact the effectiveness of your code. "It does this really cool thing, but it takes far too long to load so I can't use it."
Then lastly, keep it simple. That is not to say ignore the natural complexity of the problem, but rather to keep the solution to the essential complexity of the problem. Keeping things only as complex as they need to be covers a whole lot of dimensions in software. It makes things more explicit and understandable, it helps with code readability, and code re-usability. It decreases the surface area of what needs to be maintained. All good things for the health of the dev and the project.
It's all in that order for specific reasons. They move outside in. As the dev, I'm not the most import person with respect to the code I'm writing. The user is, and so the code needs to be purposeful to them (efficacy). Efficiency is more about the product, making sure it works properly. Keeping things simple, although it impacts efficacy and efficiency, is largely a positive for me and helps me maintain sanity.
I think it's important to note that it's all of these things, not just one of them. We'll approach tradeoffs in a prioritize way, but we're striving for the three of them. Obviously a very difficult task. But I find that approaching engineering this way has helped me grow a lot as an engineer.
Anyway, first time post here. Your comment made me think of this. Thanks for coming to my tedtalk.
When it comes to any code I produce (with the exception of some learning projects), I try to keep it: effective, efficient and simple. In that order.
Effective is essentially what you were saying about correctness and usability from the user perspective. Peter Drucker would say to be effective is to "do the right thing." This is always an outward focused item. Does it impact the user in the right way? Does it solve the right problem? Etc. This is hands down the most important thing. Nothing else matters if you're doing the wrong thing.
In contrast, efficiency is to "do the thing right." Once you're doing the right thing, minimizing your costs, increasing your quality, making it so your code doesn't "consume the whole world" all fall under this category. Poor efficiency can negatively impact the effectiveness of your code. "It does this really cool thing, but it takes far too long to load so I can't use it."
Then lastly, keep it simple. That is not to say ignore the natural complexity of the problem, but rather to keep the solution to the essential complexity of the problem. Keeping things only as complex as they need to be covers a whole lot of dimensions in software. It makes things more explicit and understandable, it helps with code readability, and code re-usability. It decreases the surface area of what needs to be maintained. All good things for the health of the dev and the project.
It's all in that order for specific reasons. They move outside in. As the dev, I'm not the most import person with respect to the code I'm writing. The user is, and so the code needs to be purposeful to them (efficacy). Efficiency is more about the product, making sure it works properly. Keeping things simple, although it impacts efficacy and efficiency, is largely a positive for me and helps me maintain sanity.
I think it's important to note that it's all of these things, not just one of them. We'll approach tradeoffs in a prioritize way, but we're striving for the three of them. Obviously a very difficult task. But I find that approaching engineering this way has helped me grow a lot as an engineer.
Anyway, first time post here. Your comment made me think of this. Thanks for coming to my tedtalk.