Live data from Hacker News

What We've Learned About Teaching Code

codecademy.com

11–20 of 45 posts

Re: What We've Learned About Teaching Code

#11

“There are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns – there are things we do not know we don't know. ” The Johari Window - quote from Donald Rumsfeld This is the point of user acceptance tests - it doesn't matter if the code does 100% what it was designed to do. If the users c…

Great quote—thanks for sharing it!

Re: What We've Learned About Teaching Code

#12
"There is an interesting paradox in teaching: the better you know a subject, the harder it is to talk to beginners. Experience means you have forgotten what tripped you up when you were a beginner."

This reminded me of how I always have to clearly explain to my beginner piano students that the higher the note on the staff, the further right on the piano it goes. It's very non-intuitive that up/down on the staff = right/left on the piano.

Re: What We've Learned About Teaching Code

#13
Since I know the codecademy team is always listening, I'll share my feedback through supporting my two friends through codecademy:

Firstly they love it. The game mechanics and the reward cycle is a great motivation for them. I think nobody can argue that you've found a great way to get TONS of people to enjoy "learning to program".

The second part is a bit tricky... are they really learning to program?

IMO the problem with all pragmatic approach is the lack of the need to understand. I know you didn't intend it, but codecademy suffers from the same tired "tutorial" approach. Users follow instructions to win the prize.

I will say codecademy is better than the tutorial approach, but it's still a tutorial.

The fundamental problem is my two friends need me to teach them how to think in code, how to conceptualize the problem, how to understand that "i am taking this problem, i am working out a solution in my brain, in english, and then i will write this solution in code" They simply do not have the capacity to do that. And they are 5 months in through codecademy.

Just yesterday my friend had the idea that when using a for loop, the loop passed all values at the same time to the nested switch statement, upon which the switch statement would evaluate ALL the variables at the same time, using whatever the hell case was the best match.

He couldn't pass the level because he did not visualize in his head that the for loop passes each value, one at time. Then it procedurely flows down, line-by-line into the switch statement... and so on.

My friends do not have pictures in their head about how code works, why it works that way, and how to use those pictures to draw their own.

They don't know how to code.

EDIT: sorry one more thing. The only lifeline they have when they get stuck (aside from asking me) is to look at the QA. I have never once seen an answer that explained the answer, nope, it was "here put this magic code in it and that way it will PASS! YAY!" And I mean answer in the sense of "why", not why does javascript require a return here instead of there, or why the "right" answer is to put this code before that code, or the strange reason you need this bracket here instead of there -- I mean why! why? really...why?

Re: What We've Learned About Teaching Code

#14

“There are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns – there are things we do not know we don't know. ” The Johari Window - quote from Donald Rumsfeld This is the point of user acceptance tests - it doesn't matter if the code does 100% what it was designed to do. If the users c…

I love that quote. In a way, this article is talking about the "unknown knowns" -- the things that are so obvious now that you don't even remember learning them, or can't imagine not knowing them. These are the lurking biases and preconceptions that we aren't even aware of having, and may be just as dangerous as the "unknown unknowns".

Re: What We've Learned About Teaching Code

#15
This phenomenon - of the difficulty of being able to teach something once it is obvious to you - has the rather unfortunate name - "the curse of knowledge", and it is well documented based on research in other fields too. There is a good discussion about it here : http://37signals.com/svn/posts/213-the-curse-of-knowledge

Re: What We've Learned About Teaching Code

#16
post #9
post #8

When you're teaching something completely new to someone, at first you won't even have a common vocabulary. This is true no matter what you're teaching, and you have to dedicate some time to establishing the language (English, not computer). One thing that makes coding a little harder is that many of the analogies we make for non-coders aren't especially clean: A hash is like an set of cubby holes, each can be named…

Excellent point. Not only that, but analogies always come along with extra bits that may lead them down the wrong path. It's very tricky to find just the right metaphor.

Richard Feynman answering the question "How do magnets work" in an informal pick-your-brain type interview:

"I can't explain that attraction in terms of anything else that's familiar to you. For example, if we said the magnets attract like rubber bands, I would be cheating you. Because they're not connected by rubber bands. I'd soon be in trouble. And secondly, if you were curious enough, you'd ask me why rubber bands tend to pull back together again, and I would end up explaining that in terms of electrical forces, which are the very things that I'm trying to use the rubber bands to explain. So I have cheated very badly, you see. So I am not going to be able to give you an answer to why magnets attract each other except to tell you that they do."

Re: What We've Learned About Teaching Code

#17
post #10

Isn't this common sense? If you've ever tried to teach anyone anything, you've run into this.

It's obvious, and they should have known. In my experience the best people to educate the newbies are the people who were newbies a year ago. They know what the roadblocks were for them, and the don't know 'too much' as to complicate things.

It's funny because education is actually is backwards here. You're supposed to want to be taught by an expert in the field.

Re: What We've Learned About Teaching Code

#18

This phenomenon - of the difficulty of being able to teach something once it is obvious to you - has the rather unfortunate name - "the curse of knowledge", and it is well documented based on research in other fields too. There is a good discussion about it here : http://37signals.com/svn/posts/213-the-curse-of-knowledge

When I was teaching I found that you have to learn the subject, then you have to learn to teach the subject. In a pinch some teachers do both at the same time, and as long as they are bright and it is not an advanced level class, this can actually work better.

Re: What We've Learned About Teaching Code

#19
post #13

Since I know the codecademy team is always listening, I'll share my feedback through supporting my two friends through codecademy: Firstly they love it. The game mechanics and the reward cycle is a great motivation for them. I think nobody can argue that you've found a great way to get TONS of people to enjoy "learning to program". The second part is a bit tricky... are they really learning to program? IMO the proble…

That's not the worst thing in the world, since most pedagogy that works is of the basic format "You should know X. What should you know? Class repeats X. Good, because you should know X. Timmy, if I say Y, what do you say? Timmy repeats X. Good job Timmy, because you should know X. Susan, if I say Y, what do you say? Susan repeats X. Good job Susan, because you should know X. You should also know that if Y', X'. What should you know? Class repeats if Y' then X'. Billy, if Y', what do you know? Billy says X. Can anyone point out Billy's mistake? June does. Good job June, because if Y', X'. Billy, try it again. Billy does. Good job, Billy. What if Y instead? Billy says X. Good job Billy. Billy got the right answer because Billy knows X, except when Y', then X'. Class, what have we learned? Class repeats X and if Y', X'."

While it is true that they don't know how to code, the more specific status is that they are presently learning to code. That's not the worst thing in the world -- so am I, and I get paid for it fairly regularly.

Re: What We've Learned About Teaching Code

#20
post #8

When you're teaching something completely new to someone, at first you won't even have a common vocabulary. This is true no matter what you're teaching, and you have to dedicate some time to establishing the language (English, not computer). One thing that makes coding a little harder is that many of the analogies we make for non-coders aren't especially clean: A hash is like an set of cubby holes, each can be named…

The point about dictionary is an important one. When I teach I try to keep redefining the words I'm using over and over again, even if I've defined them already. I feel this is one of the more underestimated complications. Especially in my math classes I've always found that teachers are all too eager to just write down some definitions and use them from then on, spewing out theorems that involve them and expecting people to follow. The dictionary takes time to sink in, at least it's always been the case for me.

I am also worried about the analogies and how they're all slightly wrong. I usually resort to trying to explain exactly what the computer does in completely reductionist terms on the bit level when you write an assignment, print, etc, but it's a bit of a rabbit hole and finding the right balance is hard.

Post reply on HN