If Scratch Isn’t the Answer, I Think I Know What Is

(Originally posted over at Medium)

In this post, the author, Dominic Pace, argues that we should teach “actual programming” instead of Scratch. I encourage you to read that first because it makes some great points. It’s written by a high school senior who’s hit upon something important: “Learn to code” tools like Scratch and Alice really are somewhat disconnected from software development. They do help with problem-solving, and they do help students work with the very basics of software development, but they create an unrealistic expectation of how we really build software.

This is a problem I’ve been thinking about for a long time. I’d like to propose a solution that’s worked for me and my students.

I spent a few years teaching beginners to code full-time, and the biggest thing I learned about teaching people a new skill is that it’s all about motivation and connections to familiar things. The learners are eager to create things similar to what they already love to use. They’re interested in coding because they know that’s how apps and games they use daily are made.

I can relate to this and I think a lot of people my age can too. When I was a kid, I played text adventure games. And my love for coding came from being able to make the same kinds of games I was playing. It was fantastic. I was even able to find books where I could just type the code and I had the game. Then I could learn from what others did and monkey with it.

This approach is how other disciplines have learned for centuries. Bach learned composition by transcribing music from other composers.

But times have changed. The steps to making a basic text adventure game pale in comparison to building a first person shooter or a mobile game. You have to know a lot more about programming to do either of those things.

This then becomes a motivation problem — telling someone who’s excited make mobile games to type a bunch of statements into a text editor and run or compile a program that prints console output is really only going to attract the nerdiest folks in the group. Most people don’t see the immediate connection, and even the best teachers struggle to make this kind of exercise interesting enough to motivate the students to do it again. And when the student discovers just how far they have to go before they’re building their own VR games, they’ll probably just give up. I’ve seen this a lot.

This is where Scratch comes in, right? It gives quick wins. It’s easy to make some fun 2D games with Scratch. A “magic 8-ball” in Scratch is a 5 minute project, and most of that is just making the graphics.

The problem is that Scratch and other tools abstract things too far away and then makes people really adverse to doing anything in a code editor. It feels like a step backwards to them. This is similar to some folks I’ve met who did Visual Basic programming for a while, liked it, then went to get CS degrees and found out they’d have to do Java and write the GUI in code using Swing.

Both of these approaches result in people losing interest in software development. But I think I’ve found that addresses both the “it’s real programming” and “it’s relatable”:

JavaScript and HTML in the browser.

The first exercise I have people do is navigate to a web page, and pop open the web console in the browser. Then we start tinkering with the DOM using code. It works because they all know what a web page is, they immediately feel empowered, it’s real programming, and they feel like they have superpowers. I’ve seen them show their friends and family the cool programming stuff they can do.

And they can do it right in a browser they already have, on the computer they already have. They don’t have to install tools, compilers, build systems, linters, or any of that stuff. They can start coding and get motivated to keep going.

Then I can gently nudge them, slowly, towards better practices.

“Oops, refreshing that page means you lost all your stuff. Programs are just files we write. Let’s write our program in a file and run it. We’ll just open it in the browser now. Look! It runs!”

I’ve gotten resistance to this idea from a few places.

First, there’s a segment of people in the industry who look down at web development because HTML and CSS isn’t “real” programming, and JavaScript is a awful language because “many reasons.” “Front end developer” has become the new “junior developer”.

That’s just silly. You’re reading this on a platform created by a bunch of talented professional developers, many of them quite well-versed in front-end development. And JavaScript might not be the best language, but a beginning programmer doesn’t run into the kinds of problems that JavaScript can cause them. Because you’re there to guide them.

There’s another segment of people in the industry who insist that programmers have to “eat their broccoli” and do the difficult, hard programming because “that’s how you learn real programming.”

This group is already opposed to Scratch — they’re in the “it’s not real programming” camp. And honestly, I think they’ve either forgotten what programming was like before they knew stuff. (I hope it’s not that they’re just not that interested in making programming accessible to a wider audience.)

Me? I want more people to program. We need more perspectives. We need more ideas. We need more fun.

So I used this approach in my classes. And it worked. I had a lot of new programmers who got hooked on building things in a browser. They found out how fun coding is. Many of them went on to do Java, C, PHP, Ruby, and even Elixir. They learned in the browser, but they learned transferable skills in a way that was motivating.

Don’t look too hard for the perfect way to teach programming to beginners; you might look right past the one in front of you.

What do you think? Share your thoughts!