I apologize in advance if what I'm about to say may sound harsh, mean or elitist, but the truth is programming isn't for everyone.
While the intent of the article is very noble ("improving the usability of Codecademy"), it also raises very important questions about programming tutorials in general. How much "holding by the hand" should a tutor do, really?
The examples the author gives are very relevant to my point. The behaviour of a web browser when pressing "BackSpace" or of an interpreter when leaving an opening quote unmatched ... Those are perfect examples of the kind of things that a future programmer must learn to figure out by themselves. While I don't argue that the pupil has to necessarily find that out from the first time, I strongly believe it is not up to the tutor to point it out.
To a certain extent, the role of "introductory" tutorials aiming at teaching programming, should be a way to filter potential programmers and select the best from the ones who won't make it. Teaching programming is similar to Martial Arts in the sense that the best teachers are the ones who let their students struggle before earning an achievement.
I can safely assume most of us here found out the "backspace in browser" issue (as well as "unmatched quote" one) without having the solution pointed out to us. We played, tinkered and experimented. This is how we got where we are today.
Holding a student by the hand is not doing him a favor. Often, it's simply delaying his giving up. And I think that the worst thing Codecademy could do is presenting their student with a modified interface for the JS (or whatever language) interpreter, just to make things "nicer".
It's not hand holding when you're trying to introduce someone to programming. Learning to use a REPL isn't a test to separate good programmers from bad. It's something that has to be learned first.
I think babarock phrased it poorly but he's not entirely wrong. I learned to program (like many others of my generation) by futzing around on my C=64's repl. It wasn't a great system by any stretch of the imagination, but actually playing with it (and failing) got me to learn it so well. I think the C=64's repl was simpler for users than Javascript's, which certainly helped. The goal should be to get people to play with it, not to get them to type "Ken".length and press return.
The things we know best are the things we play around with. The things I know the least well are those where I only learned the happy-path through some training procedure. I learned to read and speak and cook breakfast and ride a bike and program and everything else mainly by trying and failing.
(The bicycle is actually an interesting case, because we try to teach the happy-path with training wheels, though this essentially inverts the controls we're trying to learn. It's a confidence-builder, not a skill-builder.)
Last year I took a class to learn a new skill. The teacher was great: he was enthusiastic, and after each teaching point he got us to try it by saying "Now let's go screw it up and learn!" We spent a lot more time screwing it up than being lectured, thankfully.
I don't know much about "Codecademy", but based on this I would say it's not really going to help most people, but not because of these minor usability gripes. The goal shouldn't be to create an 'intuitive tutorial'. You're trying to teach people a new way of thinking. The goal should be to provide an environment where the essence (type something, get result) is completely obvious, and where more information is always available upon request, and where they are encouraged to play around. What I'm seeing is an environment where there's a right and a wrong. It makes programming look like a 1980's MS-DOS adventure game but harder.
What you call "holding a student by the hand" I call "teaching." It's not legitimate to assume that some subject should only be reserved for an elite group just because it is difficult to teach and learn; the failure in this case is in a lack of good teachers.
While the intent of the article is very noble ("improving the usability of Codecademy"), it also raises very important questions about programming tutorials in general. How much "holding by the hand" should a tutor do, really?
The examples the author gives are very relevant to my point. The behaviour of a web browser when pressing "BackSpace" or of an interpreter when leaving an opening quote unmatched ... Those are perfect examples of the kind of things that a future programmer must learn to figure out by themselves. While I don't argue that the pupil has to necessarily find that out from the first time, I strongly believe it is not up to the tutor to point it out.
To a certain extent, the role of "introductory" tutorials aiming at teaching programming, should be a way to filter potential programmers and select the best from the ones who won't make it. Teaching programming is similar to Martial Arts in the sense that the best teachers are the ones who let their students struggle before earning an achievement.
I can safely assume most of us here found out the "backspace in browser" issue (as well as "unmatched quote" one) without having the solution pointed out to us. We played, tinkered and experimented. This is how we got where we are today.
Holding a student by the hand is not doing him a favor. Often, it's simply delaying his giving up. And I think that the worst thing Codecademy could do is presenting their student with a modified interface for the JS (or whatever language) interpreter, just to make things "nicer".