Disabling Copy/Paste == Increasing Learning?

In our coding challenges, we present a "hint" for each steps, which is a bit of code with blanks, and it's up to them to figure out where that code fits in the current program and what will go in the blanks.

For example, here's a hint from our very first challenge, which gets them to use the rect() command to form an H:

The goal is for them to learn by doing - to get a general idea of what we want code want them to produce, and to tinker until they figure it out. The hints vary in each challenge in how much they reveal, but there is always some structural hint to guide them.

In reviewing the challenge feedback form (which automatically records the students' code when they report a problem), I noticed many students had clearly copy-pasted the hint code. I can tell that from tell-tale missing arguments, wherever a blank had been - like "rect(,70,60,50)".

With invalid JavaScript like that, students would immediately see an "Oh noes!" syntax error and have to work out what it meant. Oftentimes, those syntax errors are not particularly newbie-friendly (which is a problem for another day!) and that can really throw a student off.

We had two possible solutions:

• Smart copy/paste: We could probably hack it so that when you pasted a blank, you'd get a comment instead, or we could change the editor to have a placeholder and disable syntax errors. We would still need to explain what comments were or what those placeholders were for.
• Disable copy/paste: If we disabled copy/paste, they would be forced to type it in, which would mean they would encounter our more sensible messages that remind them of the proper arguments for that function (instead of the more nonsensical confused syntax error). It also means they would have to take the challenge more slowly, and think about what it was they were typing. Though I can't find any research in the programming space, there is research in the note-taking space that manually typing increases learning more than copy/pasting, due to the extra attention it requires.

Well, we're all about increasing learning here, so we went with the latter option, using the CSS user select property on the code. Yes, they could be savvy and inspect element to get that code, but it is highly unlikely that our beginning students will do that, and they are who we want to do the most learning.

Now, we're not against copy/paste everywhere - once you understand code, you can be quite productive when you learn how to find the most similar code to what you want, and then copy-paste-and-modify. But that's not the skill we're testing in the challenges, and we think it's worth it to make them go through the effort to type syntax that is only marginally familiar.

If anyone has done research or your own experiments to study the effects of typing versus copy/pasting when learning code, we'd love to hear about it.

New animation challenges

We now have challenges for our three talk-throughs on animation. Animation challenges are harder, because the student often has to restart to see their changes, and conceptually, they have to visualize the program changing in their head - but they also bring greater reward, since, hey, we animals love moving objects. :-)

• Exploding Sun: The first animation challenge, it tests whether the student can put a draw() function int their code and then increment a variable inside of it.


• Tasty Tomato: This comes after a talkthrough where we introduce mouseX and mouseY, two powerful global variables that report the user's mouse position. It's not quite animation, but it is changing the program over time, a powerful and related concept.
• Parting Clouds: This challenges the students to make an animation similar to the first one, but using the incrementing shortcuts that we cover in the talkthrough just before (+=, ++, etc.)

Kids Coding Classes in the Bay Area

When I was in high school, I got my first taste of how much fun it is to teach coding by being a counselor at a computer camp. Back then, a "computer camp" was a rare beast, but now, there are more and more of them popping up - which is awesome, because it means that more kids get exposed to programming in a fun and friendly environment and have the opportunity to figure out whether they want to keep going with it.

I thought I'd do a little research into what kid-friendly coding camps, clubs, and classes are available in the bay area, and share that here. To find them, I first went to code.org and used their "Find a school" search engine, which lets you find things other than just schools, and filter by format and level. Then I added a few that I've heard about personally, like GirlsWhoCode, who is bringing their clubs to the bay area for the first time this year.

Besides these classes, there are also K-12 coding events that pop-up, like the upcoming Level the Coding Field hackathon. I discovered a Bay Area kids programming events calendar which hopefully includes those sort of events.

If you know of other coding classes for kids in the bay area or have experience with any of these, please let us know in the comments. If you're not in the bay area, just search code.org for options in your area and if there are none, consider starting a chapter of a club like CoderDojo in your own city.

Year Round

	What	Who
Technovation	Android Apps	High school	Girls
CoderDojo SF	HTML5 Games	Ages 6-16
BlackGirlsCode	Mobile apps, HTML	Ages 7-17	Girls
BreakoutMentors	Custom (tutoring)	K-12
CoderDojo Silicon Valley	Python, HTML, apps	K-12
WizBots	Lego Mindstorms	Grades 2-8
Menlo App Academy	Games	Ages 11-16
HeatSV	Data science	High school
Digital Monkey School	Art, animation, games	High school
ComputerMagix	Games, Graphics	K-12
CodeNow	Ruby, Robotics	Grades 9-12	Minorities
GirlsWhoCode	Programming	Grades 6-12	Girls
SMASH Prep	Video games	Grades 6-8	African-American males

Summer Camps

	What	Who
Digital Media Academy Stanford	Film, robotics	Ages 6-18
Ohlone	Robots	Grades 4-11
BFOIT	Programming	Grades 6-12	Minorities
TechKnowHowKids	Robotics, Games	Ages 5-14
Digital Media Academy at Berkeley	Film, Programming, Robotics	Ages 12+
SF BaseCamp	Python Games	Middle school

New text challenges!

We've broken our "Text" talk-throughs into its own module, and along with that, we've created 2 challenges to test how well students can use text commands and concatenate strings together:

• Challenge: My Favorite Foods: The first text challenge, it asks them to list their favorite foods, properly spaced out. Later, once we cover arrays, I plan to re-visit this challenge and show them how much better it is with arrays.


• Challenge: Mouse Tracker: This comes after a talk-through where we introduce the "strings" term, show how to save a string into a variable, and animate it on the string. This challenge will have them doing something very similar and quite useful, showing the current x and y next to the mouse position.

New talk-throughs: Clarifying with Comments and Writing Readable Code

We love that we have such an active and creative programming on Khan Academy, and we're inspired daily by seeing the programs that students put out there, and the way they try to help each other. That's why we're putting particular focus in our curriculum on writing code in a way that helps other people learn from it, and we've added 2 new talk-throughs along those lines:

• Clarifying with Comments: How to use multi-line program descriptions and single-line comments to explain tricky parts.
• Readable Code: How to use indentation and whitespace for easy-to-read code.

We hope these lessons will make everyone's programs easier to learn from, and prepare students for a lifetime of clean, clear code.

New introductory challenges!

We've added 3 new challenges to our beginning lessons:

• H is for Hopper: This one is designed to be the very first challenge that anyone does, and as a bonus, it introduces them to Hopper, our friendly beaver.
• Bucktooth Bunny: This challenge is the first test of variables, and whether they can use them to store a bunny's eye and teeth size.
• Funky Frog: This challenge is the second test of variables, and if they understand adding to them to make new values.

Besides the new challenges, we've also refined our feedback form to give us better information about the problems that users encounter, and we're using that to keep improving the challenges.

Teaching Variables: Analogies and Approaches

As we're in the process of auditing and redoing our introductory talk-throughs, we find ourselves discussing the different approaches to teaching variables and debating which analogies make variables the most approachable to newbies.

There are a few aspects of variables that we’d ideally like new learners to understand:

• A variable has both a “name” and a “value”.
• The value can change (atleast, in JavaScript).
• A variable can be used multiple times throughout the code.

There are some aspects that maybe they don’t need to understand at first, but it’d be a nice bonus if they did:

• Variables can hold data of different sizes.
• Variables can be different types.
• Multiple variables can point at the same value (more true in the case of objects than primitives).

We’ve considered a few analogies ourselves, and I asked around to find out what other folks use. Here’s a round-up of them, with scribbles approximating how one might visualize them on a whiteboard. It’s not always necessary to be able to visualize an analogy, but it helps.

“Buckets”

We currently use this analogy in our first talk-through on variables. We don't love it, however - we don’t usually think of buckets as having labels in the real world, so this analogy doesn’t help reinforce the important idea of variables being labels for containers that hold values.

“Drawers”/”Boxes”

We like this analogy because drawers are often labeled as to their contents, and the idea actually maps nicely to what happens behind the scenes in a computer too, with the registers. Kevin Henney points out that the “labeled boxes” analogy also works nicely for introducing “arrays (a row or column of boxes) and objects (a group of boxes).” Ikai Lan likes how “box size is a good analogy for type discussions later on.”

“Envelopes”

Similar to drawers, envelopes often have something on the outside (a name or address) and a value on the inside (the letter). An envelope can also be different sizes, which lends itself nicely to talking about storing data types. But, the address doesn’t map perfectly to variable names, and I prefer using the envelopes analogy to explain concepts like HTTP requests or message sending systems.

“Tentacles”

Marjin Haverbeke describes variables as tentacles in the first chapter of his great book, Eloquent JavaScript, and its a great analogy to emphasize the idea of variables as pointers:

“You should imagine variables as tentacles, rather than boxes. They do not contain values, they grasp them ― two variables can refer to the same value.”

“Name tags” / “Names”

This analogy really emphasizes the named aspect of variables. Want to refer to something by name? Then slap a name tag on it!

“Code like a Pythonista” uses this analogy extensively with diagrams demonstrating what happens when you re-assign a variable and assign two variables to the same value. They specifically stress that in Python, variables “are not labeled boxes.”

“Values in disguise”

Math.com describes algebraic variables with interesting wording:

“In algebraic expressions, letters represent variables. These letters are actually numbers in disguise. In this expression, the variables are x and y. We call these letters "variables" because the numbers they represent can vary—that is, we can substitute one or more numbers for the letters in the expression.”

The notion of disguise is fun and playful, and it's nice how they've attempted to correlate the actual word "variable" to its meaning. We often forget in programming how weird some of our terminology is, and that it might help learners to connect the words to their meaning.

Which should we use?

Of all of those, we will likely be going with “labeled boxes” for future lessons, because it’s a familiar concept and the analogy covers many aspects of variables.

We’ll keep trying out approaches and seeing how students respond. In the meantime, we’d love to hear what your experience with teaching and learning variables. What worked? What made it click? What didn’t work?