I find this… interesting. I mean, yes, think about your problems up front, but a computer will always be a better computer than a programmer would. How do slow feedback cycles make one a better programmer? In what ways do you find that these habits serve you well now? Is, for instance, painstakingly checking variable spelling an interesting (or valuable) use of a programmer's time, when it can be handled by automated tooling?
> In what ways do you find that these habits serve you well now?
It doesn't help now, it helps you get better for the future.
This is something in photography: if you lengthen the feedback cycle, you are forced to build a stronger mental model of the behavior of the camera.
With film, you had to see whether the exposure was right well after the fact. With digital, you could see right away and take another shot after adjusting. With live view, you can fix exposure before taking the shot.
Which teaches you more? If you always have exposure preview, you blindly learn to adjust the exposure compensation knob until the exposure is good, and there's no learning forced upon you.
With film, when I would mess up exposure, I would find out a week later and feel intense regret: "Damn, in that situation I should have used positive exposure compensation."
This leads to me, having understood the system better and internalized it, being able to anticipate what exposure comp I need ahead of time.
Basically, if there's nothing (or less) lost as a result of a mistake, you won't learn as quickly.
I'm going to make a little stretch here, just bullshit really, but:
There is no (conventional) way to lengthen the feedback cycle when playing a musical instrument. It is immediate.
But beginning jazz piano soloists are often taught to vocalize their lines as they play. This clarifies your goals, and keeps you from aimless noodling that is in key, but lacks a pull towards something (which is how I play, since I have shit pitch memory and perception).
I guess I'd draw the connection to writing tests before implementation. And then to extend out a little further, as you become experienced and have internalized what your instrument will sound like, this habit could hold you hold you back from truly free expression, not that anyone wants that in my code.
On the other hand, personally when playing music I don't perceive any feedback on the more subtle aspects unless I make blatant mistakes. Intonation and bowing on cello, unwanted accents on piano.
These are only revealed fully when I record myself.
And regardless of how short or long he feedback loop is, listening to a recording of my own mistakes when playing is sufficiently traumatic for me to make for a strong learning experience.
My impression of how slow feedback cycles make for better programmers is that habits of careful thought are developed because the cost of waiting is so high.
The following are anecdotes, not data, but consider their sources:
"When I learned to program, you were lucky if you got five minutes with the machine a day. If you wanted to get the program going, it just had to be written right. So people just learned to program like it was carving stone. You sort of have to sidle up to it. That's how I learned to program."
- Don Knuth [0]
"Before I sit down to code something, most of the instructions have already run through my head. It’s not all laid out perfectly, and I do find myself making changes, but all the good ideas have occurred to me before I actually write the program. And if there is a bug in the thing, I feel pretty bad, because if there’s one bug, it says your mental simulation is imperfect. And once your mental simulation is imperfect, there might be thousands of bugs in the program. I really hate it when I watch some people program and I don’t see them thinking."
Along those lines, in the Kemeny-Kurtz documentation for their original Basic from Dartmouth college on GE hardware, there was a remark "Typing is no substitute for thinking."
Have you ever heard teachers say that they don't allow cheat sheets on tests because students learn the material better without them?
Have you ever studied for a test and REALLY mastered the material, and walked away with the feeling that you know it inside and out? It's actually a great feeeling. Alternatively, have you ever managed to squeak and get a decent grade despite the fact you only partially knew the material but had prepared a good enough cheat sheet?
I feel like code completion, fast compilers, and debuggers are one big cheat sheet.
