No one actually codes using a REPL in a browser. Yet the site makes no attempt to explain why or how this REPL exists, or how it works.
It doesn't explain why I can only type in certain places on the screen.
It doesn't explain how to try again, or undo mistakes.
It doesn't explain why a string must be surrounded by quotes, but numbers must not be.
It doesn't explain why suffixing `.length` to a string (but not a number) does anything, versus any of 50,000 other English words I might have put in its place.
It's confusing that there are three sources of errors: those from the language, those from the tutorial, and those from the browser/internet. Where is this program running? Where does the code live? How does this code turn into action? How does the tutorial know what I'm doing?
Codeacademy doesn't explain how any of this magic happens. It just plops you down in front of a REPL and tells you to echo specific things.
Coding is not about learning the syntax that lets you type "Ryan".length. It's about learning the underlying concepts: the "why", not the "what".
Coding is best learned "the hard way".
Funny. There is a series of books by Zed shaw called "Learn 'x' the Hard Way". The books tells you to type things first; the explanation comes later.
In my experience, the most important part of learning to program is that you can do something fun, quickly. If you enjoy the programming, you will continue with it, and then bother to learn the "why"'s. If you don't find it fun, why would you bother learning "why"?
The Code Academy tutorial isn't perfect, but I do think it's a fun introduction. Importantly, it's a fun introduction that require almost no set up. I know it has limitations, but it is pretty awesome, and a much better path into Ruby than a lecture on object oriented programming.
Not to knock the lecture. It's very important, in fact. I just think the lecture should wait until lesson 2 or 3.
One example is the popularity of Stanford Professor Andrew Ng's Machine Learning class. The course is almost entirely top-down, with concepts, then trying out basic code, then finally learning some of the Math behind the algorithms. But people have definitely been able to learn from the course-I remember seeing an HN post about a guy who built a self-driving RC car using the algorithms in the ML course.
The idea of adding buckets of complexity by beginning with questions like "what is a REPL", "how does the code turn into action?", "how is my message getting to this site?" kind of takes all the fun and exploration out of the experience.
As a programmer I dislike magic, I have to know what's happening under the hood. But had I kept asking why, I'd be studying electronics and electricity at the moment.
The trust in the existing infrastructure has to begin somewhere, and I think the quick feedback from a REPL is a great learning tool. It whets the appetite, and students can then expand their circle of knowledge over time.
Imagine if you had to understand E=mc^2 before being allowed to appreciate the night sky ;)
It is obvious the users' background covers a wide spectrum so Codecademy would have to draw a line somewhere and say here's the pre-requisites prior to starting the intro coding course. They may need to provide this background knowledge via a pre-sessional/foundation/principles course (or pintpoint users where to go if they don't) covering the barebone basics of computer science and computing as a task.
Whether 'the hard way' is the best is really up to the learner - people learn in different styles so whatever gets their attention really. As a suggestion , Codecademy should provide a list of additional resources for eager learners who wants to understand the underlying concepts and/or provide links to other courses if this particular course is not useful for them.
It's a distraction from what otherwise seems to be a great idea.
There cannot be a right way to teach given the multitude of learners now online.
The problem I found was this tendency to start with the terminal as the teaching tool. The terminal is a black and intimidating hole to a beginner. Sure, I happily typed in 2+2 and got 4 as a result, and I understood how to store variables and even if statements and while loops, but honestly, I found this to be too abstract. I didn't understand what the terminal was and how typing in 2+2 was supposed to help me build a website, which is why I wanted to learn to code to begin with. I got frustrated and quit learning to code for a while as a result.
But then I decided to try out the free Stanford CS106A course. I was hooked from the very first lecture. Instead of starting at the terminal, Stanford had me download Eclipse (which is less intimidating than the terminal) and they started with a fun "Karel the Robot" language. In the first assignment, my goal was to make Karel the Robot run around the grid and drop / pick up diamond 'beepers'. I LOVED it. The excitement I got from actually getting Karel to do what I wanted was exhilarating and far more rewarding than getting a pretty badge from Codecademy. I completed the course in about a month and am now learning Ruby, which I absolutely love.
My point is, people want to learn to program so they can build something, so starting off with concrete and fun projects (versus typing random stuff into a Terminal) is the way to go.
We're in the amidst of creating something complimentary (different too) to Codecademy called http://CodePupil.com. We're eager to see different styles of teaching; especially examples where gaming is used!
As noted in the OP's article creating a new experience and especially one that teaches all the Elizabeth's how to code is a big challenge. We've been asking our friends like Elizabeths to test and then we reiterate. Also we've found Mechanical Turk to be helpful in re: to user testing feedback. There seems to be a lot of Liz's there.
See if there's anything you find useful in it.
Although, I think this comment needs to be someplace else.
THough I wonder it asked me to sign in using my Google account. Is there an option to use the site further without signing in?
The app uses it to send a welcome message to users.
Unfortunately that's the default minimum permission set granted by App Engine Users API. Further, I promise not to be evil:
Also, my first intro CS course also used Karel the Robot, and while it was cool that I could see this guy run around on the screen, I kept wondering "what is the point of this"? It didn't seem useful or related to writing actual programs at all. While it is less abstract than typing commands in a a prompt, it still felt very contrived.
But I guess that depends entirely on the student's motivation for learning to code -- are they looking to build a website? To understand how computers work? Because they like solving puzzles? Just to "try it out"? Teaching through a robot game like Karel probably would not be a good approach for those who want to get their hands dirty and build actual stuff (and Java is probably not the best first language). But for those who are more interested in understanding computer science / puzzles, those who value the problem solving aspect of programming, a tangible game like Karel might be better.
However, I'd still say CodeAcademy's approach with browser based lessons is much better -- there's a much lower barrier to getting started than downloading and setting up an IDE. Furthermore, they have complete control of their site design. I don't think introducing REPL at the beginning is the best idea, but it's better than hitting the student with a sledgehammer like Eclipse.
Perhaps a compromise would be a very simple game in Ruby/Python? There was a web based Ruby game on HN recently, intended for experienced programmers, in which you wrote the AI for a bot navigating through a map. Obviously that is too complicated for a beginner, but I imagine something simpler could be both appealing, engaging, and accessible.
It used to be that terminal was the standard when it came to learning ones first language (think BASIC in most of computers in 80s).
EDIT: I wanted to criticize the choice of learning programming by starting with something as unwieldy and bloated as Eclipse and Java.
My mind changed, as I read about Karel language. Starting with a simple language that can actually do something then gradually building up is great for learning.
However, one point still stands, BASIC was basically one level down the abstraction from machine code, while Karel is now four levels down. This is the inevitable price of progress just like we can't build a toaster completely from scratch(http://www.ted.com/talks/thomas_thwaites_how_i_built_a_toast...).
She also told me that codecademy assumes too much stuff is known, like booleans or whatever. All the things that we take for granted and innate are extremely complicated to teach through a human-computer interaction.
I think the easiest way to learn is to take a simple page or script that already does something and change it. With that you get a little excitement that motivates you to learn further.
The classical computer learning books normally start with a "hello world" program and then move on from there.
I wouldn't go with any theory to start.
I can't imagine this would be productive. What's the point of learning OO stuff if you aren't actually going to be writing programs big enough to warrant it right away? Get started with the smallest part of of the joy of programming: write some code and see it do something, even "10 print hi goto 10" is going to be a lot more exciting than OO, I would think.
CodeAcademy is trying to teach people to code, and I think a big part of that, is learning to navigate small problems, debug, and follow instructions. If they just gave instructions that said "type the following", that would take away these problems - but what would that achieve? That would be like a professor not giving repeat questions on an exam, and a student complaining he wasn't clear enough.
"Oops, try again."
Code Academy could type your statement:
"A large part of learning to program is testing and debugging. Please see if you can figure out what went wrong and try again."
It's all about setting expectations.
All this said, I've at least gotten some totally sweet badges.
It seems to have been fixed since I mentioned it this morning.
In the initial stages of learning of learning a concept, have a dialogue appear for each error saying something like:
To fix this error type in: "Janet".length instead of Janet.length
I did exactly the same thing when I was checking out Code Academy - in fact I think I even typed the same math she did.
Nothing at all to do with CodeAcademy- but I really hate this behavior.
Still... 'delete/backspace' going back in a browser never made sense to me.
Until Codecamedy came along it was probably just going to be a project I continuously put off until something else changed to make it happen. But now I'm signed up to get the Code Year emails, it's something I'll probably remember to do from week to week.
Anyway, back to the usability. I agree with the author that it's easy to make mistakes and feel confused with learning to code on Codecademy. But from what I've gathered so far it's easy to make mistakes and feel confused with learning to code, period.
Programming involves a lot of testing, of trial and error, to come to the right answer, or more relevantly; a better answer. Codeademy is giving people the opportunity to ease into that sense of trial and error, but it needs to be there nonetheless, because that is the reality of programming.
If you make a mistake, such as typing with a close bracket quote, and then you get an error message, what you do from there is probably a good signal of whether you should continue learning to code. If that happens to you five times, and you keep thinking "huh, why did that happen?" and then continue working on it until you figure it out, there's a good chance you have the sort of insatiable quest for understanding that you probably need to be a programmer. On the other hand, if you give up after a few tries, then it's likely that you don't have that same need to understand the logic behind it.
Codecademy is obviously trying to bring programming to a wider audience, but it shouldn't simplify it to the point where it's not giving a realistic picture of the very nature of programming. You can choose to take the stairs over diving in; but you still gotta get in the pool.
People have been taught by their IT dept., their family members, friends, store clerks, etc., to not mess with a computer. This also applies to their automobiles, appliances, etc.
In short, a lot of people out there have been hit with a newspaper on the nose (various times) for trying something new.
So, they decide to learn a new hobby (or craft), and they spend (waste) a lot of time fighting the fear of breaking things.
Yet, we (as in hackers) all know that one can't really do much harm to a computer with a simple approach such as the one used by CodeCademy. But non-hackers do not know that. They fear the machine (or the result of making a mistake with it (their files will be deleted! - plays in their mind)).
So, CodeCademy, I suggest you help people overcome such fear by showing them what they can do before showing them how to do it.
The terminal is fine, actually, I find that it was a genius idea. But, learning how to code is not bound to a terminal. It is bound to thinking, problem solving, abstractions. A learner cannot be afraid to break things, otherwise, they will not learn.
Challenge their fear (and ignorance) from the start. Instead of throwing them crumbs in the form of a simple string.length exercise, show them that they:
- cannot mess their computer up by playing with your website
- will not get a virus
- should try again if they fail at something
- programming (not coding) takes time to learn
How will you do that?
I can point north, and tell you that Nirvana is that way, but I cannot walk the roads for you.
Sit back, and think about what I'm saying.
Help people learn how to code by helping them get over themselves.
I wish your team the very best;
She was excited to try, but ran into the exact same problems this article surfaced. She was being a real trouper about it, but it was plain that her patience and temper were running short. That said, once we got past the first steps and I taught her how the website was supposed to work, she breezed through the next handful of exercises before calling it a night.
All that said, I was definitely left with the impression that codecademy was not well designed for complete beginners. Yet.
For now I had a brief look at Scratch (http://scratch.mit.edu/) and I'm tempted to turn her loose on that. It seems to have a nicer effort/reward slope, and will help her understand enough of the core ideas behind programming that I could then turn her loose on other languages.
While the problems with the REPL and trying to delete text are obviously a problem (and a hard one to solve), I'm not sure the issue with leaving out the quotes is. Obviously if the text was replaced with "I don't know anything called liz" instead of "liz is not defined" would be a minor improvement -- but at the same time anyone should be able to sit back, look at what they were asked to code ("Ryan".length) and notice the difference to what they typed (liz.length). The "Oops, try again" might be enough of a message there.
ie. for this one, since missing the quote is an obvious error, why not match the string entered with a regex (or your parsing tool of choice) and look for the presence of exactly 2 quotes, with at least one character in between. If it's not there, print "That didn't work. Did you miss out a quote?"
In fact, if they log all the things people type in, they could analyse it for all the most common errors and then start attacking each of those.
Adding more expansive instructions should help as their current one/two-liner approach doesn't really explain anything for the absolute beginners. However, this can put some slightly more knowledgeable learners off by being too pedantic so Codecademy needs to find the right balance. Within their existing UI, they can probably do this via offering more 'Show Hints' per task like certain computer games where Hint 1 is the cryptic-ish hint, Hint 2 gives slightly more context and Hint 3 for really struggling learners. Users can then self-select how much help they need and don't feel like they are being spoonfed. If Codecademy is really targeting the absolute (but willing) beginners, they need to realise these users are unlikely to google for help as they are used to self-contained courses a la CBT courses in their day jobs.
Agree with imjared about the sweet badges - if they want to get the crowd (or maybe just me) going, they should start offering the options for users to buy some embroidered patches or 3D printed versions of the achievements!
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".
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.
Making friendly error messages in the general case is a hard problem, but doing so in a restricted environment where you know the most likely errors that beginners will make (which you can data mine over the long term) is not.
I remember fooling with tiny BASIC etc as a young man. It was weird and wonderful. Nothing worked right; everything was a maze and a puzzle. I wouldn't have missed that for the world.
I think I fixed this problem in my app (iheartpy.com) using AIML. Caution: Still a work in progress.
The whoe thing -
I am a self-taught programmer. And I had been an extensive user of codeacademy myself. I realized this rather serious design flaw early on and tried to do something about it.
Initially, I tried to right my own engine based on JSON but midway I discovered AIML. It suited the task perfectly. So I downloaded pyAIML library . It is surprisingly simple to get started with. I hacked around a bit and got a workable python app.
Finally using pyAIML + regexp, I ended up with a crude engine that takes something like this (in Python):
def foo(param1, param2)
FUNCTION foo PARAMS param1 param2
Then I threw together a minimal UI and got it up and running on App Engine here:
Honestly, this is my first project and looks more like the work of a script-junkie at this point of time. The lessons are not done yet. I wasted a lot of time in trying to optimize my app for App Engine. And now I'm an 18 year-old who has a LOT of exams on his head and this unfinished project. It is kinda disheartening.
Anyway here's the github repo . It is not very neat. Psst.. I added some LOLPython magic as well !
Finally, I made something that is essentially an MVP. I'm new to both design and coding. Plus, I don't think I'm proficient enough in Python to teach people.
In short, I need help. Would be happy enough with some feedback, though. ;)
What it meant was that the application would have access to see your email address i.e. google will disclose the address firstname.lastname@example.org
Unfortunately that's the default minimum permission set granted. I use it to send people a welcome message. Further, I promise not to be evil here:
Thanks for the encouragement!
(Sorry, couldn't resist.)
(I hope you note it's sarcastic)