I'm a little stumped by that, I'm all for repl oriented development, ~zero round trip time etc etc but I have to admit that when you thought the problem through in your head long before writing any, then the right code will fall through. So are instantaneous cycles good or bad ?
For me this advice is about developing your spec to an appropriate level of detail before writing any significant amount of code. I'm still in the phase where writing code is fun, and it takes a little discipline to think my spec through enough to make my code-writing time efficient.
I went through each quote carefully while adding some missing ones to my fortune clone/database at https://github.com/globalcitizen/taoup and noticed two things versus modern sources: (1) The weight lent to optimization related concerns seems higher than today. (2) Comprehension of the non-electronic context of programming seems higher than today.
I think these are probably valid cultural reflections, potentially ascribable in part to the (edited, time-lapse) nature of paper-publishing versus electronic.
I've always been fond of Thompson's rule for first-time telescope makers: "It is faster to make a four-inch mirror then a six-inch mirror than to make a six-inch mirror."
Heh. That's my dad's quote - I remember seeing that page tacked to his office cubicle wall back in the 90s when Unisys still employed programmers who had office cubicles.
If you're a consultant there is still a degree of paperwork to do. Documenting the approach, the work itself, the handover, the install and troubleshooting.
If you're in big business or government then there is still paperwork. These are political organisations and even doing a good job isn't satisfactory, in many cases I'd argue that appearing to do a good job on paper is what your task really is and any delivery of a working piece of code is second to it.
I certainly benefit from regular reminders of this.