Your point was thought provoking. In problem solving the "what" and the "how" are orthogonal since the method doesn't dictate the goal. However, if it takes a long time to do something (how: working slowly eg. because you're coding on a very slow, old machine) it tends to predict that there's less accomplished (what). That suggests that this isn't 'fully' orthogonal.

Someone else raised a good point that if we're working on the wrong thing, it doesn't matter how fast we are. However, I think a more subtle interpretation is more helpful here. I think that we need to be clearer about the consequences of the outcomes: what's the value add. The way I often reason about that is whether the outcome is 'Long-term greedy' or whether the outcome is going to make us a million dollars now. I find the latter really helpful, because if we're going to make a million dollars now but it costs us 100K in tech debt, then (provided there's not a better use of the resources) that is likely a good cost-benefit outcome.

I think, unfortunately, this is something which requires the development of good taste: the ability to distinguish good abstractions and clean implementations in advance of their creation, to direct it. There is little replacement of experience in this endeavour, and most time people spend learning to do software engineering pays no attention to it. Intentional analysis of existing projects and developing your own new things is incredibly helpful for this, and the sort of development we recognise in the workplace we may recognise but fail to prioritise and reward appropriately.