The Hopscotch Blog

How NOT to teach your kid to program

Since last fall we’ve been creating products to help kids learn programming. Here are a few lessons we’ve learned along the way: 

• It’s much easier to be creative when you are given a framework: Kids like to create things but they have no idea what. Most will just look confused when they are faced with a blank project. Once you give them some guidance (eg: “see if you can make Daisy jump 4 times”) they are eager to riff on your instructions. One of our biggest successes was helping kids program their own quiz games. They had a blast coming up with the questions and answers and showing off how hard their quizzes were. 
• Kids like to make things their own: While people liked the look of Daisy the Dinosaur the top requested feature by far was to be able to customize the Daisy Avatar and background. When we ran classes with Hopscotch kits the first thing everyone wanted to do was change the default colors and images. If you check out our gallery page you can see all the crazy puppies people came up with.
• Middle School Kids are bad at typing: If any kids are reading this, sorry, but it’s true. The most common response when I told this to adults this was: “But I remember taking typing lessons in middle school”. Only people who are bad at typing need typing lessons, QED. The upshot of this was that kids faced an additional hurdle when trying to complete a Hopscotch Kit. They are quite slow and error-prone when typing in their programs which makes it difficult to get the syntax right. 
• Non-programmers are bad at typing programming characters: In everyday typing we rarely use the curly brace “{” the pipe “|” or the hash mark “#”. These are among the most commonly used characters used in many programming languages. It’s difficult to concentrate on programming when you have to constantly hunt and peck on the keyboard to find your favorite strange programming character. 
• Nobody reads instructions: Including me. I don’t know why I thought our users would read my lengthy paragraphs on the meaning of the variable. I guess you get into a different state of mind as the instruction-giver. Long instructions = bad. 
• Kids think mobile apps are cool, websites, less so: ”Hey kids, we’re gonna teach you how to make a website!“ received a lackluster reaction. “Do you want to make an app?” got them excited. It’s important to note that once they actually started building a website they had fun, but when asked what they wanted to do it was inevitably apps. 

Agree, disagree? I’d love to hear comments. Show this to your kid and see if they find this accurate (they probably think they’re good at typing though). 

Language choice in learning to code

Some folks believe that which specific computer language you learn to code in is very important.  Others say it doesn’t matter, programming languages are as similar to each other as French, Spanish and Italian.  Learn one well, and you’ll be able to learn other ones very easily.

That’s the idea behind Udacity’s blog post about why they teach their courses in Python.  It was interesting to see the Hacker News comments generated by this post.  

One comment struck me in particular: that Python is very simple to learn, yet it isn’t a “toy” language.  What constitutes a toy vs. real language?  That “real” web applications are built out of it?  I agree that I think of certain languages as toy languages (ie: SmallBasic, Logo, Scratch and most certainly our Hopscotch), but why?  It’s a question worth posing.  After all, they’re all Turing complete.  

Our goal with the Hopscotch iPad app (coming soon!) is to allow kids to learn the concepts underlying programming without simultaneously struggling with the frustrations of getting the syntax of a particular language right.  With typed languages, how do you know whether your program is buggy because you are missing a curly brace or because you didn’t understand the concept of assigning variables?  A Hacker News commenter said it well:  ”less incidental complication so you can focus on inherent complexity.”  That’s what we want to do.  

Methods to Avoid Madness

Many programming students have initial difficulty with the more abstract concepts of programming. For instance: variables and methods (two concepts that often come hand and hand) are really hard to grasp without any context.  Once Jocelyn asked Sam and Evan: what exactly is a variable? and neither of them could give a clear definition. 

When you encounter new vocabulary in a new field, you want to be able to go somewhere for a nice neat definition. But with programming, the short definition usually ends up being more confusing than enlightening. The better way to understand a method or variable is to feel the pain of solving a problem without them.

Here’s an example: Imagine you are drawing a star. It might take 20 lines of code. What happens if you want to add another star in a slightly different spot? You copy the same 20 lines, changing the positioning. As you add 3, 4, 10 stars the situation quickly becomes unsustainable.

What if I were to tell you we could give a nickname to those first 20 lines of code to make a star?  Then any time you wanted to make another star, you just called up that nickname (or method ).  Instead of copy-pasting and finding the right numbers to edit, you would call “star” with numbers representing the position where you wanted to place it. If I told you this right off the bat you might not understand the purpose of all that extra code. But after those 10 copy-past-edits, your “star” method would start looking pretty good.

And voila, you’ve organically discovered methods and variables.

Opinionated Tools: Forcing Your Users To Make Something Beautiful

Jocelyn had an art teacher colleague whose students consistently brought home beautiful, abstract works of art.  The school even used kindergartners’ art as holiday cards.  If you’ve ever seen little kid art, this is no small feat.  The trick was that the art teacher took away a painting when it got to be beautiful work of abstract modern art, before the kids started adding too many colors, or patterns on the side or extra figures.  While she let them use their imagination she also curbed them in according to the dictates of good taste. 

For a more familiar example, think of Instagram. This was not the first photo-editing software for the iPhone.  But Instagram actually made your cell phone snapshots look good, all the time. Other apps allowed you to edit but didn’t guide you to make them look good in quite the same way. 

My instagram ‘art’- they do all the work to make me look like I know what I’m doing. 

This is something we talk about a lot at Hopscotch. We want our products to allow kids to create amazing programs on the iPad but only under very specific constraints designed maintain a beautiful look and feel.

We’re taking a lot of inspiration from MIT’s Scratch but we want to be careful. With Scratch it’s far too easy to make something supremely ugly (see below). 

On the other hand, there are products like Scribblenauts.  This is also somewhat open-ended, allowing users tremendous latitude over the objects that appear on the screen.  But no matter how hard I try to cram random non-related things into the scene, it still looks consistent and fun.

Conclusion: even people with zero design aesthetic can benefit from guidance. This is especially true of kids. Stay tuned too see what beautiful projects will be coming out of Hopscotch!