This post has been in my drafts for over a year, and I keep revising it and pondering more about it, but I think the time to publish is now, since I have also been talking about this in talks. In fact, I now say that Hedy has three main points that differentiate it from other tools, of which “designed for teaching” is one:

So, what do I mean with “built for teaching?

In my “teaching kids” career, I started with using Lego Mindstorms, a visual, dataflow language (basically a skin on top of LabView). This was surely not a language to use in teaching, it was obviously a tool to get stuf done. It was clear that, even though the goal of building a robot was engaging, this tool was not always easy to handle for kids. Keeping a good understanding of how a lot of digital wires connect is very hard.

A first look at Scratch

When I first saw Scratch, this must have been somewhere in 2014 or 2015, I was hooked! This would be THE language that would make programming for kids easy and encouraging. With Scratch, things were going to be different. Clicking blocks together to make a program, making is very visible what blocks were connected to what other blocks, and immediate output, in the browser. I immediately envisioned what games, animations and stories kids could make with Scratch.

“But teacher, what should I do?”

The first problems already arose when I presented Scratch to kids. Some of them took it and ran, but many had problems to get started. Scratch does not tell you what to do. I just “is”, ready for you to use like a box of Lego blocks that had the potential to become anything.

This is also what I said to kids: You can build whatever you want. But, not knowing anything about programming, you can’t really make a plan! It was like giving them some fabric and wool and knitting needles and saying: make a hat! They lacked the understanding of how the things worked together to even want to know what do to, let alone to make a pla

“Teacher, help, my project does not work!“

After a while, I got the kids to program a bit. I created some extensive tutorial (take this block, connect it to that one”) and some were making some progress.

Then we ran into the second problem: when I was walking around in the class, helping out kids (with or without their own plans) is that when something was amiss, it was extremely hard to detect the issue. For example, often variables would have unexpected values “teacher, I never reach 10 points in my game” or “I have minus 5 lives but the game should stop at 0”. Simply finding out what sprite set a certain variable is possible in Scratch only through manual inspection of all sprites, scrolling through all blocks. Heck, I sometimes opened the textual json format of a Scratch program to ctrl-f in, but that’s not a thing you want to show kids I guess.

It turns out that not having error messages is a double-edged sword: yes, kids don’t get scared away by “Syntax Error Unexpected EOL”, but on the other hand: all errors are hidden. Accidentally disconnect a block? No one will warn you that you did. Created an event listener but no event? No problem! But also no result.

In the time I spent with kids 1:1 fixing their mistakes, I fear I might have done more harm than good. Even I as an experienced programmer was sometimes lost for while, and when I saw what the mistake was, I had no good process for the kid to repeat next time other than: “I have seen many programs fail over the years kid, that’s how I knew.” Also, because kids were embarking on their own plans (very often vague plans, or games that I did not know) I sometimes had trouble understanding what they even wanted to achieve, let alone that I could help them achieve it.

Teachers, like no other, saw these issues with Scratch

When I was struggling with the fact that Scratch does not tell you what to do or how to do it, I assumed for a while that it was me. Better teachers would, surely, be able to help kids better. But as time went one, I also was sometimes asked to teach Scratch to elementary school teachers, hoping to find in them fellow enthusiasts for this great tool and help in learning how to teach it.

I was telling them: “Look, at this shiny toy, people! You can have your students make an Easter story, or a history quiz or a game to practice math” and they kept asking me in words that I did not fully grasp at the time: “Yeah ok but how do you teach this?” (I was like: well, that is your job right?).

Teachers saw through this issues and asked exactly the questions I was struggling with: ok, but what do kids build? and ok, but how do I help kids that are stuck? And of course I had no answer there, because I myself was struggling with helping kids out in 1:1. “Yeah just figure it out with them” I would say to unenthusiastic ears.

How do you effectively use blocks in the classroom?

And you know what, the real answer to this date is: I still don’t know how to teach with Scratch.

This of course is partly about me! I know I am the kind of teacher that likes it when kids are working with goals that are clear to me and to them, and I am aware that there are other teachers that feel a lot more comfortable with vagueness and that is ok.

But it is about Scratch. Scratch is a tool that seems to have as a goal to be a tool for kids to program with. It is not a tool to teach concepts. You can use it for that, like you can use a shoe to hammer a nail into the wall, but it is not made with that goal in mind. The line of thinking that Scratch results from, going back to Seymour Papert, believes that kids learn best when they explore are are not taught. Hence (in programmers lingo) the user story “a teacher can explain a variable using Scratch” is not something that was considered explicitly as a design goal.

Of course it is entirely fine that Scratch does not help in teaching, that is not a criticism of Scratch perse. It is fantastic to have tools in our toolbox that allow kids to create things. But think it might explain the trouble that schools have had in implementing Scratch successfully, especially schools in countries like mine where teachers are expected (and like) to explain things and maintain some sort of control of the tasks that kids work on. While there might be many different answers to the question why schools around the world have not adopted blocks-based programming en masse. I suspect the fact that blocks are, at their core, not designed for teaching might be a factor that we rarely talk about.

Of course some schools absolutely succeed in adopting Scratch, but I think it is often despite Scratch’s design and not thanks to it. Teachers use tools to work around the teaching limitations, like telling kids explicitly what blocks they can use, for example, or make long lists of “possible problems and their solutions”.

Encore: “Programming education is nostalgia for parents”

You might ask then: why is Scratch so popular and used extensively? So far it seems to be a lot more used than your Hedy, Felienne!

Sure, Scratch succeeds in many ways. Scratch suits the type of kid that I was as a child, and the type that many programmers were: the kids that like exploration, who have a good resistance to failure and really want to learn programming for whatever reason.

And of course there are a lot of kids with programming parents that will, like me, also fall in love with the potential of Scratch. Someone (and I am so sorry I forgot who, if this is you, please make yourself known and I will credit you!!) once said after I gave a lecture that “a big chunk of programming education is just nostalgia for parents” and I think that is so true.

One of the reasons Scratch is so cool it that is is easier than what we got as kids, so excites us old people. Imagine what we could have made had we had Scratch! So we sit down with kids, recreate our own childhood but with less GOTOs and show kids what they could build. For some, the blocks click in place, but many others don’t see the potential because they don’t see any connection to something that they care about. And this is where I do so agree with Papert! We need kids to build stuff that they care about, to show them that the computer is a place where problems can be solved, where bars can be reached and the sky is the limit. But so many kids and teachers need several small examples, and our step by step guidance in how to get there.