This brings to mind a couple things I've read. One is Richard Gabriel's article The Art of Lisp and Writing , specifically where he talks about the practice of coding something up and then revising it. He equates this to the process of writing (in English). I extended his ideas into my own world, writing my own blog post , quoting his article, if anyone's interested. This was my own thinking about current software practice and what needs to change about it.

What I realized as I was reading through this material again is that your example of a routine, and how you reasoned about it, has implications for whole programs/systems, and thereby, projects.

Here are what I thought were the relevant parts that Gabriel talked about:

Great writing is never accomplished through planning followed by implementation in words, because the nature of the word choices, phrasings, sentence structures, paragraph structures, and narrative structures interact in ways that depend [on] each other, and the only possible plan that can be made with which a writer can reason about the piece is the piece itself.

...

[T]he requirements for a system come not only from the outside in the form of descriptions of behavior useful for the people using it, but also from within the system as it has been constructed, from the interactions of its parts and the interactions of its parts separately with the outside world. That is, requirements emerge from the constructed system which can affect how the system is put together and also what the system does. Furthermore, once a system is working and becomes observable, it becomes a trigger for subsequent improvement.
I think this bolsters your point, that clarity of code is important, because you make it more difficult to reason about your code if it's already optimized. He makes a larger point about our dev. tools, that they've promoted premature optimization of design in order to get optimized executables, but this has made software/project development more difficult to reason about.

Interestingly, Gabriel used the same quote that Knuth used, though Gabriel says it comes from C. A. R. Hoare (and has been misattributed to Knuth): "Premature optimization is the root of all evil in programming."

Your article also brought to mind something Alan Kay told me about coming up with new architectures:

[W]e need to ask about the architecture of the proposed model . . . before worrying about details. Some of these questions are algebraic: i.e. are there abstractions that could simplify the number of concepts needed to span the model? It seems there are: both structural and behavioral. Can we separate "meaning" from "optimization"? Yes, in many if not most parts of the system.
An idea that seems to have stuck with him for a long time is that code should represent "goals," rather than commands, and it's up to the underlying system or dev. environment to formulate implementations of those goals. The idea being that you can have clarity, and optimized implementation, but to have that, you have to have a compiler or runtime that doesn't take your code at face value. This is "pie in the sky" for me at this point. I don't know what it means yet, but I felt it had relevance to the subject.