Felienne | Explicit Direct Instruction in Programming Education | RStudio (2019)
In education, there is and has always been debate about how to teach. One of these debates centers around the role of the teacher: should their role be minimal, allowing students to find and classify knowledge independently, or should the teacher be in charge of what happens in the classroom, explaining students all they need to know? These forms of teaching have many names, but the most common ones are exploratory learning and direct instruction respectively. While the debate is not settled, more and more evidence is presented by researchers that explicit direct instruction is more effective than exploratory learning in teaching language and mathematics and science. These findings raise the question whether that might be true for programming education too. This is especially of interest since programming education is deeply rooted in the constructionist philosophy, leading many programmers to follow exploratory learning methods, often without being aware of it. This talk outlines this history of programming education and additional beliefs in programming that lead to the prevalence of exploratory forms of teaching. We also explain the didactic principles of direct instruction, explore them in the context of programming, and hypothesize how it might look like for programming
image: thumbnail.jpg
Transcript#
This transcript was generated automatically and may contain errors.
Good morning, everyone. So my name is Felina. I'm an associate professor at Leiden University. I'm also on Twitter. My Twitter handle is my first name, super easy. So if you want to talk about this talk, maybe mention me so I can see what's going on in the room afterwards.
So this talk is about explicit direct instruction in programming education. That sounds a bit technical, so an alternative title that we might use is one I stole from Greg Wilson of our studio is how to teach programming and other things. That's what we're really going to talk about. How do we teach programming? Because a lot of you probably are also involved to some extent in teaching. Maybe you teach your kids, but also junior colleagues, maybe on your team, you want to get them up to speed on your code base or libraries that you're using, people in your team. So lots of people are actually teachers or teaching, so I hope you get something out of this talk.
First, mandatory audience participation. Who knows who said this? Everyone should learn programming. Any guesses from the audience? I think it's like every programmer ever. You are all guilty of this, because we love programming. We're like, oh, programming is the best, so everyone should learn programming. But it's fun, but it also opens up a super interesting question, because what is programming? If I ask a bunch of people in this room what is programming, I might get 10, 20, 100 different answers.
What is programming? It might be very well that what's programming to me isn't programming to you. And we programmers might not be the best people to answer this question. Maybe you've heard this story by David Foster Wallace that I absolutely love about three fish. So this big fish, he's swimming, and he runs into two tiny fish in the sea. And the big fish says, hey, folks, how's the water? And the tiny fish say, what's water?
We programmers, we are those tiny fish. We are so much swimming in the sea of programming that it gets really, really hard for us to see we're in that sea, to understand that we are actually influenced by this water of programming, as I call it.
The spreadsheet revelation
So how did I came to think about this? It wasn't that one sunny morning I woke up and I thought, oh, today I'm going to ponder what programming actually is. There was a sort of long backstory to this involving my PhD work. So let's go back to the year 2008, when I moved from Eindhoven, where I did my master's and bachelor's degree, to Delft, where I started a PhD in software engineering. And my research question for my PhD was to make a DSL, a domain-specific language for finance.
So my supervisor and me, we envisioned something like this, a programming language in which people in finance, bankers, insurers, people like that, could express their business logic such that they didn't need programmers for everything, because there aren't a lot of programmers. And also it's very empowering, of course, for people that have no full programming degree or experience to be able to make some small things for their own needs. So this is what we envisioned to work on for four years in my PhD.
And the first thing that I did when I started is I did an internship at a Dutch insurance company. I went there just to look around and to see, what are people actually doing in industry? And my mental model of the world was sort of this. There are users. And there are also programmers. They are entirely different species with a wall between them. They have nothing to do with each other. Maybe sometimes they converse a little bit through the wall, but in general, they're entirely different people. And the programmers program, and the users use.
Well, turned out, it was more like this. Everyone in the company was programming, all of them. The programmers were programming, but also the other non-programmers, people that didn't have programming as a part of their job title or former role, they were also programming. But they weren't programming like this in a traditional programming language, of course. They were programming in spreadsheets. This whole insurance company was ran on spreadsheets.
That is weird, because they told me in school all those years that normal people, the non-programmers, they needed our programming help to make things, because they could only write things like requirements and stuff. They couldn't do programming. So I was like, wow! So I went back to my supervisor, I said, friends, they don't need a domain-specific language in finance. They have a domain-specific language in finance, and it's Excel.
Spreadsheets, and I really say this without any irony, spreadsheets are the best programming system that has ever existed in the history of mankind. Spreadsheets are such a good programming system that people can program without knowing their programming. Let that sink in for a bit.
Spreadsheets, and I really say this without any irony, spreadsheets are the best programming system that has ever existed in the history of mankind. Spreadsheets are such a good programming system that people can program without knowing their programming.
Excel is such a good programming model. People just know what to do, and they can start doing it immediately, and they can add formulas and pivot tables and VBA, but initially, it's just so intuitive. This model where you get live feedback from a spreadsheet, it's just a programming language.
So that became the motto of my PhD dissertation. Spreadsheets are code. We should take spreadsheets seriously as a programming paradigm, because people are running companies with it, and people are very, very successful in building stuff with it. But spreadsheets are not just codes. They're actually functional programming. A formula in a spreadsheet is guaranteed to be side effect free. A formula just takes input from other cells, and then calculates the results based upon those cells. So it never has side effects. It's pure functional programming.
Spreadsheets are also reactive programming. The spreadsheet model works in such a way that if you update a cell, only the cells that depend on that cell will be updated, and not a full recalculation of the spreadsheet is needed. So it's pure functional reactive programming, and still, 750 million people are able to use it in an easy way. Like, eat that, Haskell!
The culture of programming communities
And the people there are like, it's not real programming. It didn't matter. They were still like, it's not real programming. And I mean, I'm laughing now, but at that point, I was really sort of sad. Who in the audience has a PhD or is working on one? So you and your topic become this one thing. And if people say your topic is not real or not worthwhile or anything, then it really hurts.
Because there was such a big difference between how important I thought the stuff was that I was working on and how other people viewed my topic as not real programming. That was definitely one of the biggest reasons that I'm not doing spreadsheet research anymore. I was just sick of this behavior of people telling me my work wasn't real. And at this point, I really thought, this is how adults treat each other. I thought, well, you know, apparently, if you're an adult, if you're in an adult professional community, people just be shit to each other.
It was only until way later, like, let's go to 2015, when I realized that people can be nice to each other. So I joined a running club. And I'm not a great runner. Like, my fastest half marathon is two hours and 10 minutes. I have friends in the running club that do a half marathon in like one hour five. So they're literally twice as quick as I am. But no one in the running community will ever say stuff like, I'm not a real runner.
Who in the audience is a runner? So we're the worst. You know, runners, we want to make everyone runners. We're like Jehovah's Witnesses, like, ding dong, have you heard the happy news about running? No one will ever say stuff like, you're not a real runner. Everyone is super nice to each other. I'm like, as I said, I'm the slowest, and people root for me. They never say, like, give up on this because you're not a real runner.
But compare this to my experience in programming. Only later I realized that it doesn't have to be like this. And it's not just running. I'm also a knitter. I really love knitting. And I knitted a lot when I was a teenager. But then I went to university, you know, life happens. So I sort of gave up on knitting. And then in 2016, I came back to knitting. And I went to a knitting meetup, which is a thing, it's super nice.
So I went there with my old-fashioned straight needles that you got as a hand-you-down from your mother, from your grandparents, straight needles. These apparently are out of fashion. People now use circular needles. I didn't know this. I'm like, come on to this meetup. Everyone has different needles but me. I'm like, oh, shit, this is going to be not real knitting. They're going to be mean to me for using this not real skill. But they weren't. They were super nice. They said, oh, you know, we all use those needles. But let us show you how you do this. And this is what the benefits are, but in a super nice way, not in a demeaning way.
And that made me look back at my experience in programming. And I was like, why are they so mean? And I don't have an answer for you. It's maybe something to ponder on later, like, why is programming like that?
Learning to teach: the Saturday club
Luckily, what really saved my happiness there was I ran into a bunch of kids in a local community center in Rotterdam where I live. And they needed a programming teacher on Saturdays. So I was like, OK, I can do that. Let me teach programming on Saturdays. Then at least I have the feeling I'm doing something useful one day a week. And I'll figure out work stuff later. So I picked up that position at that school. I actually still do that every Saturday. And I'm flying back after this talk, so I'm in time to teach tomorrow.
And it was heartwarming. It was really nice to see kids coming in on Saturday to learn programming. But I didn't know anything about teaching. I had no clue about teaching. I just didn't know how to approach it. I had no plan. And I also wasn't considering a plan. I just thought, hmm, let's go there and we'll see what happens. And I think what happened in my brain, not consciously but subconsciously, I started thinking about how I was learning when I was their age.
So this is me, age 10, behind the computer. We had a computer. And I had this book of basic listings that I got from the library. And I just typed up the basic listings in my computer for hours. And it didn't work because I had syntax errors. And then I fixed all of those. And it still didn't work because I made indentation errors and whatever type of mistakes. But then in a while, it worked. And I had a game in BASIC. And that's sort of how I learned programming.
And notice the absence of a teacher or an adult in this story. No one was teaching me programming, apart from maybe the book. But there wasn't another person. So this was my experience learning programming without an adult or a teacher present. And it's not just me. Many people of my generation that grew up in the 80s learned programming alone, learned programming by themselves, taught themselves programming. A recent survey on Stack Overflow among hundreds of thousands of developers stated that 80% of developers taught themselves programming.
So this idea of how to teach programming, we don't know how to teach programming. As a community, we don't have a shared collective memory of what a programming lesson looks like other than us being alone with a Commodore 64 or something like that. And that does something to us as a community, that we lack this experience of being in a programming class until we're 18 in university. And of course, then you are already shaped a bit as a person.
So this led to this idea with me, but also with other people, just let kids explore the programming language. Just give them the basic listings. Well, it's maybe Scratch now or Python. But just give it to them. And they'll explore. And they'll figure it out. And they'll pick it up naturally.
So I bought some books, just went to the bookshop, programming for kids books, and brought them to the Saturday Club. But once you start looking on the things that are in there, it's sort of weird. So it's in Dutch, but I translated it underneath. So this says, the best part of programming is finding mistakes. Yeah, it's funny, but it's also interesting. So notice what it doesn't say. It doesn't say the best part of programming is making something, creative expression. And it doesn't say the best part of programming is being able to find a well-paid job, which actually matters to many people.
In a similar vein, it says programmers only learn from making mistakes. But why? Why would I only learn from making mistakes? Why wouldn't I learn from being told how to do it in a proper way? That seems to be so much more efficient.
It says, break the rules. If you're programming, it is important to break the rules. OK, I guess. But this is a book about Python. So let's go further a few pages. Same book. The colon goes there. The space goes there. The space needs to be in the right place. Otherwise, Python will be very angry. And it will shout syntax error at you. And the file stuff, the colon goes there. And the quote goes there. And the rectangular brackets go there. But also, break the rules.
But same code statement, the most important thing, it's fun. So it will be frustrating. You have to break the rules, but also not break the rules because of the syntax. And if you're not having fun, you're doing it wrong because the most important thing, people, is you should have fun.
Exploratory learning and its limits
So you see, this culture of trying out, exploring, is very much in everything we are. And part of it, that is our experience. Part of that is our culture. So that's what I did as well. I bought those books. I put them in the group. And I just had, let kids explore. And I did focus on concepts. So I said things like, a loop is an important concept that you need to know. It is about repetition, stuff like that. But I didn't really thought it really, really matters where the colon goes in Python. I didn't really talk about it because I was in this mindset of, oh, exploring. Oh, they'll figure it out. They'll get an error message. And the only thing they can do is learn from that. That was my thinking.
And surprisingly, it didn't really go amazing. So I saw kids making some progress. But then eventually, they got really, really frustrated. And the nice thing about teaching eight-year-olds versus university students is that if an eight-year-old is confused, they will tell you. They will take this book and throw it on the table and say, I hate this. But it's a good experience as a teacher because when students come into university, they get scared about saying they don't understand things. So I mean, it's clear that if you give a lecture to a big lecture hall with 18-year-olds, some of them will not get it. But they won't come up to you and hit you with a book. They'll go home and be in their dorm and cry and be frustrated or maybe drop out because they don't understand.
So then I started to look into research that has been done because I thought, wow, people must have tried this in research, and they did. There's actually this nice paper by Scafidi and Chambers that looked at skill progressions in Scratch users. So Scratch is a visual programming language very much aimed at young children. And they sampled children throughout a number of projects and they looked at, okay, what are the kids doing? So firstly, they found very, very high dropout. So kids register, make a project, and then they quit. But they also found that kids initially made some progress and then their skill levels sort of flattened out. They didn't explore new blocks, new concepts. They had a few that worked for them and then sort of stuck with that.
And this very much looks like my Saturday classroom experience. Initially, kids made some progress, but then I couldn't get them to the next level and I didn't really know why. Well, I didn't know why because I didn't know anything about teaching, and that's why I was really, really bad at it. I don't know how this works in the US, but in the country I'm from, if you want to teach tiny humans in elementary school, you have to go to teacher school for four years. If you want to teach medium-sized humans in a high school, you have to go to school for five years. But if you want to teach at a university, you get your PhD in 12 Afternoons of Bloom's Taxonomy, and then you're good to go.
What linguistics taught me about teaching
So I really, despite being a professional educator in a well-ranked university, I really didn't know a lot about teaching. So I was like, I should fix this. I should know more about how we teach things because clearly this isn't going well and there's an opportunity for me to improve. So one of the things I did is I read the Oxford Handbook of Reading, which firstly stretches the definition of a handbook a little bit. It's filled with all the things that humankind knows about how children or people read.
We programming, we know nothing. People in linguistics research have figured out so many detailed things about how people read. Why aren't we doing that type of experiments? And one of the most interesting things I read in the Oxford Handbook of Reading is that how we pronounce things actually matters a lot. So this is already very vivid in young kids because one of the things you teach children is if they start reading, they sound out the letters. So memorizing letters and words very much goes through sound. We don't teach children silent reading initially.
And this actually also sound really matters for adults too. So I'm a scientist. Let's do an experiment. Mandatory audience participation. Tiny experiment. I'll show a sentence on the screen. Once you reach the end of the sentence, reading it silently in your brain, you raise your hand.
So I didn't do any statistics, but it seemed like the second took you a bit longer. And this has repeatedly been shown in lots of experiment that these type of sentences take people longer to perceive because clearly what's happening in your brain is you're reading, I have a tear, because you're thinking it will be in my eye. That's more likely sound. And then you see my pants and you have to go back, re-pronounce the sentence in your brain with tear, and then read the rest. You cannot not do that. So this has shown consistently across proficient adult readers of English that to a certain extent, you always sound out stuff if you're reading.
So how stuff sounds matters. But I wasn't necessarily impressed with this fact, even though it's a super cool fact. I was impressed with how well this was measured, that people set up an experiment to figure out how to read these type of sentences, and then they had repeated that over different cultures. So they have repeated this type of experiments, and they have real solid knowledge of how people read things. Like, we have no solid understanding of how people read source code, for example. No one has done similar experiments this solid and this repeated about reading source code.
But the second thing I got from this book is we lack fight. In programming education, there's very much a monoculture, and of course, I don't mean a real fight, I mean some pedagogical diversity. In other fields like math and language, there are different streams, different beliefs from people of how to teach, and they argue about that, usually in a polite way, not in a you're-not-real-teaching way, but in a more solid way. And one of these debates, you might be aware of it, is called phonics versus whole language. These are two streams in reading education.
So phonics is, like I just said, this sounding out. E, I, D, read. You start with the basic letters, and then words, and then sentences, and this is how you build up an understanding of children, of letters and words. You also have the whole language approach, and the whole language approach says, no, language is not about technical skills, language is about communication. So you shouldn't teach people individual letters because that technical skill is going to disengage them from reading. You should just give them sentences and context, and that's the better way to teach.
There was also in the US in the 80s, you might be aware of this, something called the math wars, where in a similar vein, people were discussing how to teach math. So some people said, well, the way you teach math is you explain kids what to do, then they do it a whole bunch of times, and then they get it. On the other side of the aisle, you had, no, math is about finding the truth and beauty. So you shouldn't bore people with memorization, you should give them problems to explore. Exploration. Those are two sides of, two opinions of teaching. And we don't really have ever had that pedagogical debate where we're like, but wait, how do we even teach? This hasn't happened for programming.
The philosophy behind programming education
And probably that's because of this philosophy that we're not really aware of. So Alan Blackwell, a really interesting scientist from the UK, he says that technology is covert philosophy. It's a really interesting statement. It means something like, if someone has built a piece of technology, from that you can see what the people believe about the world. And in a similar way, I think education is also covert philosophy. You can learn a lot about the things people believe from the way they teach. There's a lot to learn about our culture from the way we teach.
So there's not just the water of programming, but there's also the water of teaching programming. And we are so much in this one side water that we don't really even realize how weird it is. And there's some history in our field that many people aren't aware of that has also contributed to that philosophy. So who knows who this is, the creator of Logo? Yes, Seymour Papert. So he's kind of well known in our community. He created Logo, which was the first programming language for children, but he came rooted in a certain philosophy.
He actually studied with a guy called Jean Piaget, one of the most important psychologists of the previous century. And he's the founder of a thing called constructivism. And constructivism means, the basic idea, there's a lot to it, but the basic idea is that I cannot put knowledge into your brain. The only way you can learn something is if you construct reality in your own brain. And Piaget said about Papert, nobody understands my work better than Seymour. He was very much influenced by this idea of, you cannot, you should not teach people things they should explore. So for example, he said things like, by explaining something to someone, you take away the opportunity for a child to discover it.
And then you see how weird this is if you compare this to other things. So imagine you have a kid or a kid you care for, they wanna learn the guitar or tennis. Would you buy them a guitar and say, hey, I'm not going to tell you anything because that will just ruin the surprise for you? So you just figure out, you know, strings, chords, finger placement, you just figure it out. You'll be fine, it'll be fun this way. I'll be in my room. Or like tennis, do you really want kids to figure out what is a backhand and a forehand and how do you rip the thing most efficiently? It doesn't make any sense.
So then you see how weird it is and how very much that philosophy of Piaget and Papert still is visible in those programming books I showed at the beginning of my lecture. Because in this situation, we'd be like, we'd get them a tutor in a club. And that form of teaching is actually very common and very aligned with the left-hand side of the argument with phonics and with explanation and practice in all sorts of things, sports, music, language, math. We have focused on just explaining stuff to kids.
The case for direct instruction
So warning, some controversy ahead because some people really still very much buy into this philosophy. But across fields, it's been very, very clear that this left-hand side instruction phonics explaining is just better. It's just better than exploration. There's this paper by a Dutch psychologist called Paul Kirschner and some other people, why minimal guidance doesn't work. And it summarizes a long list of studies across fields saying you should just explain stuff to kids. There's this other paper actually by Sweller and Cooper that compares two groups of children. Half of the group got a worked example. So the teacher said, this is what you do and you just do the steps. And the other group of kids got a more traditional, maybe in some places, equation. They said, this is the equation and you have to solve it for A. And they didn't know how to do it. And they compared the children how well they did. And this left group, first group, did way better. They did the solutions in 1 5th of the time of the other group. So not 20% less in the 20% of the time. And they also did better on new programs, new problems.
And this makes lots and lots of sense if you know a little bit about short-term memory. So here's another mandatory audience participation session. I'm going to put, let's say, $1,000 on the table. If you can remember this tiny snippet of things, I'll put in front of you for a few seconds. Ah, that was hard, right? No one got it.
That's super easy, right? But it was the same length, the same number of things, the same variety in things. And still, this was super easy to do. That's because our short-term memory can only hold seven plus or minus two items. And actually, you might be aware of this study. Neural research said it's now four items. So there's very, very limited room in our brain to store things. And this, why is this so easy? Because you just store three things. You don't store the individual letters. You don't store the individual words. You store the concept. You think of a cat, and then of love, and of cake, and it makes sense.
So that has to do with something called cognitive load. If I would really bet you to remember this, then if you were to try memorizing it, you get this fullness in your brain, right? You're like, oh, it's an O with a dot, and a long stripe, and like a sigma, but reverse. You feel your brain getting fuller. And that fullness is called cognitive load. And that's the reason that this one group, the left group, does better, and in all sort of similar experiments, because the other group had a too high of a cognitive load. They're solving the problem, but they have to think of many things, like what approach am I going to take, and oh, what is that technique again? And their brain gets so full that there's no more room to actually store the memory of what they were doing.
So I think the biggest, if you just remember one thing from my talk, is you don't become an expert by doing expert things. That's what these studies have shown. And that's the misconception that we have in programming, and to a certain extent, also in math. We think that if we want kids to be problem solvers, we give them problems to solve. If we want kids to be programmers, we give them programs to program. But it doesn't work like this. If you want kids to be problem solvers, you have to teach them to memorize a lot of strategies for problem solving, or a lot of strategies for programming. That's how they memorize. And then once they see a problem, their long-term memory is filled with all of these approaches they can then use.
So I think the biggest, if you just remember one thing from my talk, is you don't become an expert by doing expert things.
Again, think of other things you want to learn, like running. The worst way to prepare for a marathon is to run a marathon every day. Everyone gets that. What do you do? Well, you do bench presses, and sit-ups, and interval training. You do all these other things that help you do a marathon. Same with playing the violin. If you want to learn some sort of Beethoven thing, you're not going to start by doing exactly that thing. No, you'll do chords and finger placement and stuff like that. So you build up little pieces of knowledge such that you can achieve bigger things. So you don't become an expert by doing expert things. And in programming, we still very much believe that.
Research into direct instruction for programming
So my goal of this is to start a fight, well, not a fight, but a debate about pedagogy of programming. Because this site, this whole language inquiry exploration part, is basically the only site that we have heard from in programming, partly stemming from Papert and Logo, partly coming from the way we were taught in the 80s. We have that site covered, but now I want to explore the other side. How would direct instruction look like for programming? What are those tiny things that we can do to help kids become programmers? What are the interval trainings, and the bench presses, and the chords of programming?
We've been exploring this, actually, at my research group in Leiden. And one of the cool things that we've done, probably the most exciting thing, is this idea that we can teach kids to say syntax, to vocalize syntax aloud. Remember that sound really matters for English and other languages. So probably code sounds also matter a lot. And we did an experiment with some novices, and we asked them to speak a line of code aloud, simple things like an assignment. We got all sorts of things. X is five, X equals five, X gets five, set X to five, assign five to X. All sensible things, but apparently kids, and we repeated it with experts, same story, we don't have a shared mental model of how to read code in our heads.
And probably based on those stuff we know from linguistics, this is going to hamper our understanding. And something interesting that we didn't think about, so we thought it was going to be confusing, but these were Dutch children, and there were all these extra things that came into play that we didn't think of. For example, this letter in English is called I, I as in tie, but in Dutch, my native language and the native language of these kids, we say it as E, E as in creep. So once children started reading these code snippets, they got confusing information, because the teacher would often say for I in range, because your brain gets in the English mode, but sometimes also conversationally, the teacher would say, oh, what variable, oh, it's E, because they would be speaking in Dutch at that point.
So one of the things that we're working on is this model of, we need consistent vocalization for source code such that children can repeat it and memorize it better. We did a super cool study where we had a group of kids repeating source code after us, for I in range, very much like you would do the tables of multiplication as well. One times three is three. And we found out it actually helps. We had two groups, one group read code aloud every lesson, and we had a control group that didn't do that. We would vocalize the code, but we didn't have this group exercise of vocalizing everything. And we found out that this first group just does a lot better on syntax exercises, and we're about to publish a paper on that.
And it's so cool because if I give presentations about this research to elementary school teachers that I sometimes do, they look at me like, wow, it's 2019 and you've just figured out that having children read something aloud works? Well done, slow clap, very impressive. They're like, did no one ever think of this? We all go to school saying one times three. How often were you made to read aloud letters when you were learning? And yet, to the best of our knowledge, we're the first one to actually try this on source code, and surprise, surprise, it actually worked.
Another thing that we're doing is teaching children and students as well, explicit reading strategies. So here's a snippet from a linguistics paper that says, here are a few strategies that you can use to read natural language. So a strategy is like looking at pictures, skipping parts of the text that you think are important. They explain children how to read natural language if they are just learning, and then they test them. We don't do any of this for source code. I have undergrads in programming classes, you give them a piece of source code to read, and they just start at the beginning. We've never told them what is a good strategy for reading code, things experts do, because they've picked it up naturally, like look at all the methods, or look at all the fields, or collapse something. They have no strategies because they weren't taught strategies.
And we did a study, actually, this is still research in progress, but we had, these were undergrads. Some students, we explained strategies, we practiced strategies with them in class, and we had a control group that were taught in a more traditional way, so very much aimed at creating programs, and not really reading a lot. Surprise, surprise, guess not, the group, where we explicitly explained reading strategies for source code, they did better.
And something else that we're really excited about is assessment. In programming classes, especially in programming clubs for kids, assessment plays no role, because they're very much ran by these people that buy into the exploratory learning style. So things like this, having a tiny test saying, this is in Dutch, which one is a variable, circle the right block, or which one sets a variable to zero, doing these things in code clubs is very much against what they believe in. So that's something we're exploring. How can we get assessments into out-of-school code clubs? Not because we want to give kids grades, because we want to help teachers understand what is the level that the children are at. Are they at this flat skill level where they maybe need a little bit of help to jump to the new level? So this is also something we're exploring.
Motivation follows skill
So, like everywhere, there are also haters in my new field, sadly. Because haters are everywhere except from knitting and running. So now I give this talk, now I go still to conferences because I just like being on a stage and I tell people this story, and they're like, but it doesn't seem fun. At one of the other conferences I presented something like this, a guy, they're often guys, pointed a finger in my face, almost saying, you're making it like school. No, school is not terrible. I'm teaching people things. I work at a school, calm down.
But actually the nice thing is research says this doesn't matter. Stuff doesn't have to be fun to actually be useful. Like I go to this running club every Monday and I do 50 pushups. Do you think that's fun? No, being on my couch, watching Netflix and eating potato chips is fun. That is pain, it's horror, I dread it. But I know it makes me better and that's why I do it. And the same is true for kids. People think, especially educators, many educators and outside of school clubs think that if kids are just motivated, they will get skills. If they just wanna learn, then they will get better.
But it's not true. It's actually very often the other way around. Kids that are skilled will be motivated. And specifically, like in my running exercise, if I feel I'm making progress, this also holds for kids. If they feel they're learning, even if it's painful, then they will be motivated to learn more. So what is actually kind of demotivating is just having them have fun and being stuck at a certain skill level because if they don't feel they're making progress, they will not be motivated.
It's actually very often the other way around. Kids that are skilled will be motivated. If they feel they're learning, even if it's painful, then they will be motivated to learn more.
So that's it, that's everything I wanted to share. Before we end the session, let me summarize my entire talk in like one minute because I know some people came in late or they're just awake and also I speak a bit quickly. So let me give you a second chance to get the gist of everything.
So what I've been talking about is the way we teach programming, which has been very influenced by streams of belief and often influenced by the lack of our community of a shared memory of how a programming lesson looks like that impedes us from teaching. And this culture is very valid in books and lessons. They very much emphasize problem solving and making fun and programming should be enjoyable and puzzly. And this comes to a certain extent also from the history of programming education that many people aren't aware of and that is very, very tied to a specific methodology of teaching. Sadly, this methodology just has shown in other fields consistently to not work as well as explanation and practice. So my new goal in life is to help figure programming out how could direct instruction look like? What are the tiny building blocks that we can give children so they advance and they're not swimming and confused, but they can feel they're making progress and thus be really motivated. The end.
So if you wanna check out more of my work, I'm on Twitter and I have a website where all my research is shared, all my papers are there, open access, and always accompanied by a blog post that also educators could easily understand. So not too technical, no p-values there. If you like listening to me, you might also wanna check out a podcast I host. It's called SE Radio. We have five episodes every month interviewing people in the software engineering field.
We don't do Q&A, but there's one question I always get, so I will answer it. Have you hand-drawn these slides? The answer is yes. I made them with my Apple Pencil and an app called GoodNotes, all by hand apart from some technology. And then I wouldn't wanna end before thanking some people that worked on this with me, mainly grad students and postdocs in my lab. And the final Greg, you know him because he's Greg Wilson and he's been just such an inspiration. Thank you.
