I think that final sentence is unduly pessimistic - after all, if practice did not play a big part in expert programmers becoming that way, what did? What hope is there for the novice who is frequently making off-by-one errors and the like?
Maybe you are saying that there is no deliberate method of practice, but I think there is: whenever you correct one of your mistakes, try to figure out how you might have written the correct code the first time. Often, it might be a boneheaded mistake, but a significant number of cases have something to learn from. Can you make an argument for the current version being correct, and the previous one not? If an API did not work the way you expected, did you overlook something in the documentation? (Maybe just that the documentation was ambiguous, and you might have realized that earlier.)
I think OP's point is that slow turnaround encourages that sort of thinking, and it does, though it is quite a cost to pay.
> I think that final sentence is unduly pessimistic - after all, if practice did not play a big part in expert programmers becoming that way, what did? What hope is there for the novice who is frequently making off-by-one errors and the like?
It's not that the knowledge can't be acquired, but this is a type of knowledge often can't be explicitly practiced through some training routine.
A beginner may of course learn to check off common errors they've been told about, and may arduously step through the code in their head line by line, but an expert sees the code is wrong unconsciously and understands what the code does without stepping through it. The only way to learn that is to engage with code for decades. There are no shortcuts.
I agree that competent, experienced programmers look at code differently, and much less linearly, than do novices, and there have been studies that show this. On the other hand, a person could (and people do) spend years programming without learning to look at code in this way. The people who do improve must be doing something different.
There are no shortcuts, AFAIK (though I think most people can achieve most of their potential in less than a decade), and I am sure you cannot get there through rote learning. Are you suggesting, however, that the sort of approach I am advocating is not very helpful, or just that it cannot be explicitly practiced?
Maybe you are saying that there is no deliberate method of practice, but I think there is: whenever you correct one of your mistakes, try to figure out how you might have written the correct code the first time. Often, it might be a boneheaded mistake, but a significant number of cases have something to learn from. Can you make an argument for the current version being correct, and the previous one not? If an API did not work the way you expected, did you overlook something in the documentation? (Maybe just that the documentation was ambiguous, and you might have realized that earlier.)
I think OP's point is that slow turnaround encourages that sort of thinking, and it does, though it is quite a cost to pay.