I teach programming, and it is painful to watch my students slowly arrow around the screen, backspace over something, then retype it. It would take less than a second for him to have grabbed his mouse, double-clicked the word and started typing the new word, all without looking down.
I taught them about editing and keyboard shortcuts at the beginning of the curriculum, yet they do not all take everything on board (who does?). So now months later I am left with the question of whether to urge improvement on them like a mother bird, or just let it go. As programmers, their time will be valuable, and their enjoyment of work improved by the ease of getting work done. But is it up to me to reinforce this after having made it thoroughly clear early on? This is not just about editing, but all sorts of practices like naming conventions, coding standards and so on, which I did in fact present already and have said that the industry expects these things. Editing is simply one obvious example.
Addition: It is not for me to dictate how students should work, but I would be remiss if I did not point out better ways to accomplish things. The question is: to know if I have made the point or when to stop trying to make it. "A word to the wise is enough", but how many of us are wise, especially while learning many new things at once? An example of coding standards is a student who doesn't like Properties. Well... They are useful or they would not have been invented. I couldn't convince this person.
Ah a fellow traveller! Welcome friend.
I agree it is so painful to watch, and there is such a professional dilemma on wether to grab the keyboard or not. I have developed my own attitude over the years, in that my time is sometimes precious and is spread thinly over many students. To remain polite I sometimes say "Do you mind if I quickly fix that for you?" and then just do the magic edits. Voila! I then move on to the next student.
Other times, when I am less short of time I let them work through it. Having me smiling and waiting patiently at their side is intimidating enough to remind them that they need to up their game. You have to do both as it can sometimes be demoralising if you always grab the keyboard. You want them to improve and not give up in despair!
One things I find is essential is not just to teach the quicker mechanisms, but to demonstrate them yourself. I sometimes "code live" in a lecture. I throw some code up that I know is bad and needs an edit, and pretend that I have to make some heavy changes. I use all the tools at my disposal like regular expression replacements, keyboard macros and IDE code re-factoring in a blur. Bish, Bash Bosh - loads-of-code. The smart ones get it when they actually visualise how long it would have taken them to do the same task. I also make (fantasy) hints that the faster you cut code the faster you can earn the dosh when a real coder. This annoys them because they all thought they were real coders before coming to class.....
Another tool I find useful are screen capture videos of me doing it. Helps the slower learners catch on, and is easier for them to emulate than some dry hints sheet. My stuff is on YouTube BTW (under my name).