'How to teach programming (and other things)?' by Felienne Hermans

Everyone should learn programming, right? Yes! But how... Should we allow children to explore and learn about syntax on their own, or should we drill programming like we rote memorize the table of multiplication or German grammatical cases? Felienne's talk outlines this history of programming education and didactics beliefs in programming that lead to the prevalence of exploratory forms of teaching, starting with Papert's LOGO. She will then explore programming education in relation to mathematics and language education and explore how rote learning could look like for programming. Felienne will discuss her own research into misconceptions and code phonology as means to teach programming more effectively.

Bio:

[superscatboy]

Thank you so much for briefly addressing the "learning should be fun" myth.

I worked in a secondary school for quite a while, and the culture there was to try and make everything fun. All the teaching staff were huge fans of it (some of them unbearably so), but the same couldn't be said about the students. From what I saw, "fun" lessons were more likely to alienate a kid that wasn't interested than they were to encourage a kid that was interested.

The kids that were interested were *already* interested - they didn't need encouragement. The kids that weren't interested just found the whole experience cringey and patronising - it made them reject the lesson entirely. But if you sat them down and said "look, I'm not gonna lie, this stuff is boring, but it's also really useful and important to know about so let's just get on with it" then they were far more likely to at least try. They respected the honesty.

The stupid thing is, we all know this is how it works from our own experiences at school. Either we couldn't stand that one teacher that always wanted to sing a song or play a game because we knew it wasn't teaching us anything, or we loved them because singing songs and playing games was more fun than actually learning anything. Either way, it didn't help our education at all, and deep down we all know it.

[aaronhelton]

This was a fascinating talk. I learned programming when I was 15 years old, and I remember very much the process being an on-my-own type of deal. It was very frustrating, but I was extremely motivated. I remember getting stuck on the fact that I couldn't, for some reason, wrap my head around the idea of 'String's, and the fact that at substring wasn't a completely different data type, and all sorts of silly little other misunderstandings. I remember being very frustrated because I knew I was just fundamentally misunderstanding something that was probably (and turned out to be) simple, but I had no one to turn to. Online forums seemed very unwelcoming, and I wouldn't have known how to ask the question in the first place, because I couldn't understand what I was even struggling with. The books I learned from weren't much help in this aspect, because the idea was just that you would 'understand' after you did the exercises a few times, and the exercises didn't even have their solutions in the book!

Fast-forward to today. I'm 23 and finishing my final year in college (long story), and I have a lot of friends from my CS Degree who didn't get nearly as lucky as I did in having an early start. I remember sitting in the beginning programming classes with them, bored out of my mind because I understood everything, but I noticed that a lot of them were struggling. I enjoy teaching things, so I set out to become a tutor for CS (My school did not have tutors for my degree, as we were only a small department). The teacher taught exactly like what was described in this talk, with all sorts of programming assignments were the solution would never be provided after the fact, much less with an explanation. He would write code in class, and we were to follow along, but he would never solve very complicated problems and explain them. He would just write code and be like "this is an int, this is a String, a variable is this, blah blah blah".

I remember many of the other students being confused because they just couldn't wrap their head around the concept of data types, much like I couldn't when I was younger. This and other problems seemed trivial to me, but I couldn't figure out how to explain it to them in a way that would work. Obviously what the teacher did wasn't working very well. But I didn't know how to do any better. I tried walking students through problems little bits at a time, by not telling them what to do but trying to prod their mind in the direction of the solution, but it almost never worked because it was difficult for them to distill the abstract concept of the problems they faced down into a workable solution they could program. Swapping a number was a herculean task for some of them, because in their mind it's just "swap the numbers", but you can't exactly just write that in code directly. (Well, at least not in most programming languages). I'd almost always end up just having to tell them what to write and explaining it after the fact. And never mind solving the crazy problems the teacher would come up with. Some of them were even challenging for me (in a fun way, at least). They required a level of problem solving that just wasn't taught in the class.

I ended up changing tactics and, instead of trying to help them with their homework, I found that having students follow as I solved a similar problem, and explained each step of the way why I did something a certain way, helped out a lot more in terms of them comprehending and remembering how to solve similar problems. The most surprising thing to me about trying that technique is that sometimes I would do something, explain why, and it would be like a lightbulb went off in their head as they would exclaim something to the effect of "Oh, THAT'S why he wrote it that way!". They had problems understanding what the code did, but either wouldn't or couldn't formulate the questions in a way that they could ask me or the teacher. But when I stopped to explain the code, I would often stumble into solving these unasked questions for them, and it would open a sort of floodgates as they asked more questions. It was always very satisfying!

This talk seems to distill a lot of what was happening in that process down to something I can wrap my mind around. I did the above without really understanding why it worked so well, and I never could understand why the other students had such a hard time learning code the way I learned code, but this talk makes that all make sense in a huge way. I'm going to have to really rethink how I help tutor now in a more conscious way now that I've seen this. I had never thought of having the students actually read the code out loud to me like a book to check for misunderstandings, and cementing a certain way of saying it to them. I bet that would make it a lot easy to teach to them when and why to use certain statements like if, else, for, while, etc. as these are words we use in everyday language when describing processes, but I don't think many of the students have made the connection between saying these words when describing the problem to me and actually using them in their writing of the program! Here's hoping it truly produces some better results. I also should consider more the idea of assessing those I tutor. I had actually just started to do that with one of my friends by having him read through code I had written and having him describe to me what the code is actually doing, on a higher level. It proved a more challenging task than either of us thought it would be, but in the end I think it was really good for him as we got to clear up a lot of misunderstandings. I'll definitely be trying that more in the future.

[e]

@43:37 But what about retention?
I'm not supprise If reading the solution vs working through the problem show equivalent results in the short therm. But what about after one month?

[OttoNascarella]

"because it is slightly unpractical if everyone has to write their own alfphabet..." - what a joyful, awe-inspiring talk! Cannot thank you enough, Felienne!

[ARVash]

When I was learning on my own, I just kept a cheat sheet on the other screen and over time I looked at it less and less.

[e]

@47:27 "You don't need to have fun. You just need to do the work". Can we really compare doing push-up and doing programming exercises?
To me the key here is engagement:
- Your muscles are automaticaly "engaged" when doing pushup. No need to have fun. just do the work.
- You can "follow" a course without your brain being really "engaged".

To me this statement has a big caveat : "You don't need to have fun. You just need to do the work" (* Assuming that you are motivated)

[diribigal]

This has been enlightening and will make me rethink how I teach math.

[karlroth]

Cognitive overload is important to realize. When we want to learn something new, not just in programming but in anything of interest, we first look at it and have cognitive overload. For many, this will deter them from exploring further because they might not have the money to afford a good book, or they have no way to find out where to go to start, or they gave no motivation . Truth. Learning anything new requires a mindset of not only strength, courage, and research ability, but also the determination to find out how.

[omomomo]

Very nice talk I'll use this knowledge to teach programming to my 8yo son. Thank you for sharing it in such an enjoyable way

[esquilax]

This really seems like it could lead to a quiet revolution, with a majority of the population having at least some basic programming skills.

There are a *lot* of people in the business and finance worlds could benefit from some basic coding in their day-to-day jobs. I've seen people spending hours comparing lists of several hundred values, to find which ones are missing from each list, and doing it all by hand. Such a waste of time, and so error-prone. It's already a huge improvement if they learn to do this in a spreadsheet.

If they then have to repeat the same task across dozens of different lists, that means a lot of manual copy/pasting if doing it via spreadsheet. Learning to do it with a script is another major step up in terms of time saved, and errors avoided.

I think the basic problem is that most programmers are pretty smart, and naturally fascinated by computers, and so the "explore for yourself and see what works" approach was _good enough_ for them. Maybe if they had been taught the basics in school, with more guidance and examples, that would have been even better. But if you're unaware of a better way, you don't feel the lack of it.

So most people who actually understand programming don't see the need for more widespread programming education, or education at primary/middle school level. And people who don't understand it, just come to accept that it's an arcane technical skill that's too much effort to bother learning. It becomes a self-perpetuating system, because nobody realises or cares that things could be different.

BTW, +1 for the spreadsheet love! I'm a professional programmer, but I'm very pro-spreadsheet. Some tasks that take my colleagues several minutes to complete with a script, I can do in 20 seconds with a spreadsheet. The right tools for the right job!

Correct me if I'm wrong though, but I don't think spreadsheets using just formulas (so no macros) gets you Turing completeness, since you can't do loops. To get the Turing machine in the video, you would've had to copy/paste the same row of formulas over and over again, for as many steps as it takes. So I wouldn't say it's 100% "real programming", but it's close ;)

[e]

IMO, while this talk was definetly interesting, it seems to offer solutions for "teaching programming to absolute beginners" not "Teaching programming".
For example, @29:37 I think that the statement "Why minimal guidance doest work" is only true for aboslute begineers.

Like for the piano, everybody agrees that you just cannot give children an instrument (or text editor) and say "have fun exploring".
In this very first stage of learning, it doesn't surprise me that scientists observe that "minimal guidance doesn't work".

That said, when I go to /r/learnProgramming, people seem to struggle to escape "tutorial hell" (the ability to follow code exercises, but not architect a program by yourself).
While not very scientific, it seems like this contredict the "Explain First" / "Heavy guidance" teaching philosophy.
It looks like after a certain stage, guidance is not the answer.

Great talks nevertheless.

[mihaeladianadobreanu]

at the 14:06 min. "The best part of programming is finding mistakes" .... wow this is soo true! And now I'll get on the knitting (actualy at the sewing) part. When I was a little girl I was helping one in a while my neighbor (she was a taylor). Once she told me "before you learn sewing, you have to learn how to unstitch".

[samhughes]

I love it! This was really good! I've been trying to figure out how to distill the essence of what it means to "be a coder." I'm absolutely going to be rewatching this with my wife later! I am interested in the data produced by that poll, though. That sounds very interesting

[unbekannter_Nutzer]

Thanks for the talk. I found it a bit lengthy and slow in the first half. The finding about speaking out loud was interesting news for me, and I will take it away.
What I can't really buy, is the claim, that learning is possible by just reading without writing. My experience is the opposite - more like your copying from the early basic book.
When reading code, things look logical and sound. If I copy code with new language/syntax in a rush, I make mistakes, because things look sound in a different, wrong syntax, too.
Writing by hand instead of copy/paste slows me down, and meanwhile my head is forced to think about it, and has nothing else to do.
Another effect is, that keystroke combinations become subconscious by repetition. Sometimes the head doesn't remember, how to do it, but the fingers do. Well - that sounds silly, and it is. Of course the head is doing the memory thing, but a different area in the head, maybe instead of the linguistic modules the motoric modules, I'm not an expert of brain surgery.
And then the question, how to start an algorithm. I guess it is necessary, to practice solving strategies often, to get fluid. Maybe this will show up only over longer times.

About frustration and fun, I understand your critic, but on the other hand, I understand the authors. Programming is both: Frustrating and fun. The deeper the frustration is, the more fun, if you finally solve the problem. :)
But is it wise, to claim, that people shall have fun?
If you start riding a horse, you may fall down - right? Or better a less dangerous example: Starting playing the guitar, you will not always hit the right tone. Telling the kids, that it is pretty normal, to fail, and make stepwise progress, might help them feel less stupid.

[MrGlobalpanic]

Really interesting talk, and I'll follow up some of the references mentioned in the video. Just one (off-topic) question: how do you get the speaker to appear as an inset video in the slides? OBS? Thanks.

[martinkunev]

Interesting, but hard to make any conclusions without more details. Could there be some bias in the studies she presented? For example, when saying that having fun does not help learn more, does that count people giving up?

48:28 I can kind of understand this attitude. Different types of programming require very different skillsets. If you've spent 10 years learning 3D graphics, logic, algorithms, cryptography, numerical methods, etc. and somebody spent 3 months learning spreadsheets, there is a big gap in knowledge and experience so if I come and tell "you're doing the same thing", this paints something very different from the real picture.

[shitinsideyou]

In minute 44, you say only reading code and explaining does as good as when also writing... Maybe you need to re-think this, writing the actual code is crucial for your memory and learning!