I can think of several problems with your driving analogy but I think they are rooted in two different things -- we have instincts related to movement/motion and we get real-time sensory feedback while driving.

No analogy is perfect. However, I think that if we squint our eyes a little and maybe stick our heads through a convenient opening in that proverbial cardboard carton--even if we're not prepared to climb all the way out--that there are some parallels even for those two things:

1. Feedback.

   It may not be real-time per se, but I think warning and error messages are at least somewhat analogous to the feedback driving provides.

   That kind of ethereal tingling sensation one gets at the base of the spine, when the surface you are driving on has little grip. When you've been there and felt it a few times, you get to recognise it long before the tyres actually loose grip. And if your good enough--race and rally drivers for example--then you can use it not just to tell you slow down, but to temper the way you supply inputs to the controls. If you're really good, you can even antisipate the slide and apply corrections before they are indicated.

   The same thing goes for warnings and errors. It's not just the text of those messages tha tells you something. But the way they are issued--their number and frequency. If they are many and continuous, the problem is probably inside the loop. If they are less and stacatto in the occurance, you probably have a bounds error--maybe the infamous out-by-one on the loop control.

   There are others signs. The cpu fan steps up in frequency when you're not expecting it to. The drive light goes hard on. Even the notes and tune the drive motor plays as the program runs can tell you something is different. These things don't usually tell you what is wrong, but they tell you that something is wrong--and maybe even indicate where.

   Feedback is also the primary reason I love my REPL, simplistic as it is. There is almost aways a copy of it running on my system, and whenever I have any doubts about a line of code I'm about to write, I switch to it and try that line out in the REPL before coding it in the program.

   And when trying to debug an algorithm that produces large volumes of output, I'll often direct the output to the screen and shrink the font to a minimum--on my console that's an unreadable 5-point Lucida--and then just watch the output scroll for a while. Instead of concentrating upon the detail of the output, I look for patterns in the flow. I cannot tell you how many times I've spotted, if not the cause, the area of the code to look at for the bugs.

   These aren't things that you can read in any text book, nor learn from any lecture. They're intuition you acquire over time from the feedback the code gives you.

2. Instincts

   A few years ago--shortly before coming to this site for the first time as it happens--I spent a couple of years in which I did virtually no coding. Indeed, for the first of those two I did none at all. And the main thing I notice when I started to get back into it, was not that I forgotten how to code, or write algorithms, or design my programs.

   It was that my instincts had become dulled.

   Everything just took longer, and was harder. From deciding what to name my subroutines, to ordering their arguments. How to structure my data; split my program across files; split my statements across lines. It wasn't that things took an inordinate amount of time--just longer. I had to think about it rather than just doing it

   And when the program failed, it was even worse. I would often sit staring at the code without any intuition about where to start looking. Worst of all, I'd find myself "shotgun debugging". Scattering debug throughout the program looking for clues. Altering statements to see what if any affect the changes had. Trying the same things multiple times in the hope, if not the expectation, that the outcome would be different.

   I'd say that it probably took 2 years or so to get my intuition back to where it had previously been. Maybe that was slowed down somewhat by moving to a new language--Perl--at the same time, but still it was an uncomfortable transition back.

   I think that intuition plays a considerable role in lifting a mediocre programmer into the realms of a reasonably good one. More importantly, perhaps the hardest working and most contentious programmer I ever knew, simple never seemed--in the time I worked with him--to develop any level of intuition for coding at all.

   For him, coding was simply a 9 to 5 activity predicated upon the need to put money in the bank. As I said, he was neither lazy nor callous about about it, but it was just a job that he did to the best of his ability--without seeming to take any great pleasure in it--until he took the step into management at the first opportunity. Something it turned out he excelled at.

So, whilst the analogy may be imperfect, requiring a stretching of the mind to make the pieces fit, I don't think that it is necessarily a stretch too far.