Hmmm, I don't really know how well this actually works in the real world (rather than on a University campus, where people are quite a bit smarter than the average population).
For example, text messages. I can be sitting there with the person that I'm trying to help - the computer spits up a dialog box. The user immediately, reflexively, moves to click on 'yes' or 'OK' or whatever button seems most likely to make the box go away (but is actually going to lead them straight into the problem that they called me for in the first place). So I tell them to stop, and read the dialog box. Then I ask them what they think the computer is trying to tell them. They think about it, and most of the time come up with the correct answer, and their problem is solved. You would have thought that this would teach them the value of reading dialog box messages when trying to resolve problems, but no... The next time they have a problem, you have to go back through the whole thing again...
Another example: the other day I was helping a friend set up a home network. It was a moderately complex setup, and he wanted me to explain how I had identified the problem, and how I found the tight way to fix his problem. But how do you explain the difference between a computer being able to ping a network drive, and the drive icon appearing on the computer's desktop? How do you explain to them that you just guessed that the ADSL modem's config page was available at http://192.168.1.1. You can't, it's the result of years and years of working in the field. The only way to learn that stuff is to play with it yourself, instead of calling in the IT guru to fix it for you.
Anyway, this is an overly long post simply to say that to truly be able to resolve computer problems, you need to be able to understand what is going on underneath all of the UI abstractions presented to the user, and that these things are complex, and difficult to learn.
For example, text messages. I can be sitting there with the person that I'm trying to help - the computer spits up a dialog box. The user immediately, reflexively, moves to click on 'yes' or 'OK' or whatever button seems most likely to make the box go away (but is actually going to lead them straight into the problem that they called me for in the first place). So I tell them to stop, and read the dialog box. Then I ask them what they think the computer is trying to tell them. They think about it, and most of the time come up with the correct answer, and their problem is solved. You would have thought that this would teach them the value of reading dialog box messages when trying to resolve problems, but no... The next time they have a problem, you have to go back through the whole thing again...
Another example: the other day I was helping a friend set up a home network. It was a moderately complex setup, and he wanted me to explain how I had identified the problem, and how I found the tight way to fix his problem. But how do you explain the difference between a computer being able to ping a network drive, and the drive icon appearing on the computer's desktop? How do you explain to them that you just guessed that the ADSL modem's config page was available at http://192.168.1.1. You can't, it's the result of years and years of working in the field. The only way to learn that stuff is to play with it yourself, instead of calling in the IT guru to fix it for you.
Anyway, this is an overly long post simply to say that to truly be able to resolve computer problems, you need to be able to understand what is going on underneath all of the UI abstractions presented to the user, and that these things are complex, and difficult to learn.