Thursday, December 12, 2013

Newbie Syntax Blindness

For the very first step of the very first challenge that learners do in our programming curriculum, they are given one instruction: type a piece of code exactly as it's displayed.

The displayed code is pretty simple, a single command:

rect(80, 70, 60, 240);

...well, it's simple to those of us who know programming. But for somebody who's never programmed before, it's not necessarily that simple. It's a mix of letters and symbols combined in a way that's completely new to them, and even when the goal is just to copy the line exactly, it's easy to get confused. A newbie does not realize what's important about the syntax of a programming language - they don't realize that capitalization matters, they don't know that a misplaced comma can be a fatal error, they don't distinguish between different types of brackets. That's probably because they're coming from human languages, where much of that doesn't matter, and they haven't re-trained their brain to realize what matters in a programming language.

To give you a concrete idea of what I'm talking about, here are specific examples of syntax errors that new programmers make with that single line of code:

(10, 70, 60, 240)           // Not starting with function name
rect{80, 70, 60, 240};      // Using {} instead of ()
rect[80, 70, 60, 240];      // Using [] instead of ()
rect( 80 , 70 , 60 , 240 ), // Using comma instead of semi-colon
rect(140, 170,120, 140, )   // Extra comma
rect()70,60,240);           // Extra close paren
rect;(140, 170, 260, 484);  // Mis-placed semi-colon

Now, we send all user code through JSHint, so they will see an error message pop up when they make a mistake like this. But for many users making these sort of errors, that error message wasn't enough to help them figure out the error, and they clicked our "Help" button to report their confusion. For each of these mistakes, I put them in the editor myself, saw the error that popped up from JSHint, and thought to myself, "Is that what *I* would tell a learner if I saw them make that mistake in person?" For many of them, the answer was no. I would give them a much more specific, helpful message.

That's not because JSHint is bad - it's fantastic - but because I know exactly what their end goal is, I can offer a more informed message than JSHint. JSHint has to offer messages for all possible JS that someone could write, and can't assume it knows anything about their intentions. There are many ambiguous errors that one can make in JS, and the JSHint messages have to equal the ambiguity of those errors.

We can't be emailing every learner that encounters one of these syntax errors with our hand-curated custom messages, as we now have thousands of students going through these challenges every day — that just wouldn't scale! So we've added another set of messages that override JSHint syntax messages, are specific to a challenge, and are served based on matching a RegEx of the code. These messages provide more meaningful, newbie-friendly syntax help, and will hopefully help learners get over the beginner syntax hump.

Here's a before/after of our messages:

Their code Old message New message
(10, 70, 60, 240)
I thought you were going to type an assignment or function call but you typed an expression instead. Make sure you specify the command name, rect, before the parenthesis.
rect{80, 70, 60, 240};
I thought you were going to type an assignment or function call but you typed an expression instead. Make sure you use parenthesis around the numbers, *not* curly brackets.
rect[80, 70, 60, 240];
I thought you were going to type ] to match [ from line 2 but you typed , Make sure you use parenthesis around the numbers, *not* square brackets.
rect( 80 , 70 , 60 , 240 ),
Unexpected early end of program. Make sure you end your statement with a *semi-colon*, not a comma.
rect(140, 170,120, 140, )
I think you either have an extra comma or a missing argument? You have an extra comma after your last parameter.
rect()70,60,240);
It looks like you have an extra ) There's an extra parenthesis before the first parameter of the rect() command.
rect;(140, 170, 260, 484);
I thought you were going to type an assignment or function call but you typed an expression instead. You have an unnecessary semi-colon after the command name.

We won't be able to hand-curate every syntax error they encounter, but we hope that helping them through the first challenge will give them the confidence to approach and interpret the more ambiguous errors they'll encounter late in their programming life.

A big take-away for us, as teachers: never assume anything is obvious. Just because it's obvious to us what the difference is between the written code and the displayed code, does in no way mean it will be obvious to new programmers.

Hour of Code Day 3: Coding across Cultures

One of the things I love about being a programmer is that it’s given me the opportunity to meet programmers from so many different cultures, languages, and countries, because programming is something we all have in common. We all speak the language of code, even if that’s the only language we have in common.

On Khan Academy, we try to make our curriculum accessible to a diverse set of learners. For the Hour of Code curriculum that hundreds of thousands of learners are taking on this week, we’ve added interactive transcripts for deaf and non-native speakers, and we’ve translated all of it into Spanish and significant portions into Portuguese (and could use your help with the rest!).

We see that diversity in what students are creating for the final project, the greeting card. The cards celebrate a range of holidays (Christmas, Hanukkah, the Winter Solstice, even Festivus!) and wish happy holidays in many languages (German, Italian, Spanish, French, Dutch, Estonian!):

Tuesday, December 10, 2013

Hour of Code Day 2: Coding is Creative

We often talk about coding as a way to solve problems, but it is also a way to create new things that never existed before. It can be a medium for creation, just like paints for artists, ingredients for chefs, or blocks of wood for carpenters.

Since we teach coding on Khan Academy using ProcessingJS, a drawing and animation library for JavaScript, we encourage students to explore the creative side of coding. We want them to solve problems but also to create new things along the way: new games, drawings of new worlds, new ways to visualize concepts from other fields. We love giving our learners a general direction and seeing the many different ways they take it and what they learn along the way.

In our Hour of Code curriculum, the big opportunity for students to show their creative chops is with the final project, since it’s an un-graded free-for-all. All we tell them is to make a greeting card, suggesting they may want to put in festive things like a snowman, a tree, or presents, but many students go beyond that, and we love that. Here are some of the cool creative projects we’ve seen so far:

Monday, December 9, 2013

Hour of Code Day 1: Coding is Caring

Since I’m a woman in technology and that’s considered a rare find, I often get asked the question, “How did you start programming?” and I respond with this story:

When I was a kid, I was a bit forgetful when it came to buying presents for holidays, and I woke up on Mother’s Day realizing that I had no present for my mum. We lived in the boonies, and the nearest store was a two-hour walk away, past a high-security prison.

Well, I could have done the “draw a card, it’s the thought that counts” route, but I’d already done that in forgetful years past, so I needed a new “thought that counts” gift.

I had just recently discovered the web, and thought “Hey! I’ll learn how to make a webpage!” After a few Yahoo! searches (Google didn’t exist then) and a download of the “Microsoft Internet Explorer Assistant Plug-in,” I had made my first webpage.

It was just a converted Word art banner proclaiming “Happy mother’s day!” but hey, it was a webpage! And I made it myself! Needless to say, my mum was impressed, and from then on, I’ve been a programmer *and* never had to buy presents. :-)

So when it came to coming up with the curriculum for our Khan Academy Hour of Code, I thought I’d bring that same experience to the many new students learning to program this week, and made the final project be a greeting card, to share with anyone you want.

We’ve had thousands of projects made today, and it warms my heart to see that many of them are greeting cards filled with warm fuzzies and addressed to loved ones. Here are a few of my favorites — addressed to parents, relatives, teachers, and friends:

I love that the creators of those cards are learning that they can not only use coding to solve problems, but also to show they care.

We’re looking forward to seeing what everyone comes up with on the second day!

Wednesday, November 27, 2013

Call for volunteers: Caption and translate our programming talk-throughs

In computer programming, our "videos" aren't actual videos - they're interactive coding talk-throughs, where an audio file is synced to a playback of code typing. That means we can't take advantage of built-in Youtube player features like on-screen subtitles, but we do have the ability to embed interactive transcripts below the talk-throughs. Learners can turn that on using the options menu next to the playbar, and then they will see the transcript scroll by as they watch and can click on parts to jump to them:

For a live example, check out the Intro to Drawing talk-through and click the option in the gear menu next to the play bar.

However, we will only show the transcript option when we have one available, and that’s where we need your help! We use the Amara service to make it easy for us to crowd-source subtitles of our Youtube videos elsewhere on Khan Academy, so we’ve created video versions of our talk-throughs and uploaded them to YouTube.

Below is a list of our programming talk-throughs on Amara, which you can click through to start captioning. If one is already captioned, keep going — you’ll probably find one that isn’t yet, farther down. You can also check this spreadsheet, last updated February 2015, which shows which talk-throughs we're missing captions for. Make sure to read through our subtitles best practices before you get started.

Besides English captions, we are also looking for translations into other languages. When we detect that the learner is on an internationalized version of Khan Academy and we have the transcript available in that language, we will automatically show it. So if you are fluent in a non-English language and want to help international students learn to program, we’d love your help in translating the captions. Just click through the links below and select your language from the dropdown.

Thank you for helping us teach programming to a wider audience!

Intro to JS

  1. Intro to Drawing
  2. More Drawing!
  3. Intro to Coloring
  4. Intro to Variables
  5. More on Variables
  6. Intro to Animation
  7. Mouse Interaction
  8. Incrementing Shortcuts
  9. A shorter shortcut
  10. Resizing Shapes with Variable Expressions
  11. Terrific Text: Part One
  12. Terrific Text: Part Two
  13. Functions
  14. Function Parameters
  15. Function Return Values
  16. Special ProcessingJS Functions
  17. Local and Global Variables
  18. If Statements
  19. More Mouse Interaction
  20. Booleans
  21. Logical Operators
  22. If/Else - Part 1
  23. If/Else - Part 2
  24. Intro to While Loops
  25. More While Loops: Balloon Hopper
  26. For Loops! A New Kind of Loop
  27. Nested For Loops
  28. Intro to Arrays
  29. Looping through Arrays
  30. Modifying Arrays
  31. Intro to Objects
  32. Modifying Objects
  33. Arrays of Objects
  34. Object Types
  35. Object Methods
  36. Object Inheritance
  37. Pseudo-Code
  38. Clarifying with Comments
  39. Readable Code

Intro to HTML/CSS

  1. HTML basics
  2. HTML: Text emphasis
  3. HTML: Lists
  4. HTML: Images
  5. CSS Basics
  6. CSS: Selecting by id
  7. CSS: Selecting by class
  8. HTML links
  9. HTML internal links
  10. HTML tables
  11. HTML comments
  12. CSS font-family property
  13. CSS font-size property
  14. CSS font styles and shorthand
  15. More CSS text properties
  16. CSS inheritance
  17. CSS grouping elements
  18. CSS width, height, and overflow
  19. CSS box model
  20. CSS position
  21. CSS floating elements
  22. Using multiple CSS classes
  23. Combining CSS class and element selectors
  24. CSS descendant selectors
  25. Grouping CSS selectors
  26. CSS dynamic pseudo-classes

HTML/JS

  1. Putting JS in a webpage
  2. The DOM (Document Object Model)
  3. Finding elements by ID
  4. Finding multiple DOM elements by tag or class name
  5. Finding elements by CSS selector
  6. Changing attributes
  7. Changing styles
  8. Changing CSS classes
  9. Setting innerHTML and textContent
  10. Creating elements from scratch
  11. Adding an event listener
  12. Using the event properties
  13. Processing forms with events
  14. Preventing default behavior of events
  15. The window object
  16. Animating DOM with setInterval
  17. Animating styles with requestAnimationFrame
  18. Animating styles with CSS animations

Friday, November 15, 2013

Join us for Hour of Code on Khan Academy!

Hour of Code is an initiative to get students (ages 6-106!) to spend an hour learning how to code, as part of national CS Education Week, December 9-15. There are nearly 2 million students signed up already and 12,000 events scheduled from 144 countries.

At Khan Academy, we’re obviously pretty excited about this initiative, since we believe that all students should start learning computational thinking and programming at an early age, even if that’s not what they ultimately do in life. Unfortunately, that’s not yet a part of the K-12 Common Core curriculum, so many teachers don’t get the chance to expose their students to programming. Thanks to the Hour of Code initiative, we hope they can find the time - and that some students will keep going afterwards once they’ve realized how cool programming can be.

Our full programming curriculum takes much longer than an hour to complete, so we’ve curated a subset of the first tutorial to come up with a special Hour of Code mini curriculum. Of course, we firmly believe in self-paced learning at Khan, so we encourage teachers to give students more than an hour and to not make them feel rushed.

If you’re a teacher, you can read our Hour of Code teacher’s kit here. You don’t even need to be a classroom teacher - you can be a parent doing it with your kids, an employee doing it with your colleagues, a Meetup organizer doing it with your members, etc. As long as you’re passionate about teaching the world to code, you can join in. Remember to register your event on CSEdWeek so that you can be eligible for prizes and get access to more resources, and spread the word to everyone around you.

Thursday, November 14, 2013

Introducing Pair Programming to the classroom

A few weeks ago, I started volunteering as an instructor for a local GirlsWhoCode club. GirlsWhoCode is an amazing non-profit that wants to teach pre-college girls about computer science, via summer camps and school year clubs at high schools around the country. They also happen to use Khan Academy for teaching programming, so it's a great opportunity for me to see Khan in the classroom with my own eyes.

One of the important things that I want to share with our club students are the many social aspects of programming - the whole spectrum of learning from each other online, helping each other in person, giving peer reviews, and the practice of pair programming. We could just tell them "pick a pair and program" but I wanted them to really understand *how* to pair program and *why* its useful.

I started with this short slideset on pair programming:

Then, I did a little variables review and told the students what project they'd be working on, the Custom Clothing Project. They proceeded to pick a partner, re-arranging chairs when needed, and got to work. As I walked around, it looked like most pairs were pairing well, collaborating and switching off every so often. A few pairs devolved into working on their own computers, which is something that can easily happen when a classroom is lacking actual physical pairing stations. Next time, I may explicitly tell them to turn one computer off, or only host documentation on it.

Overall, I'm happy we introduced pair programming this way, and hope to use it in our future in-class projects. If you're thinking of introducing it to your classroom, I recommend checking out the NCWIT Pair-Programming-in-a-Box kit, which also has recommended surveys for finding out from students how well they liked it. If you're a teacher that already uses pair programming, I'd love to hear your tips, especially for doing it at a younger age and with the Khan curriculum.

ACM Education Council 2013 Meeting

I was honored to be invited to the ACM Education Council meeting on November 2nd, to speak on a panel about teaching young programmers how to code. I spoke alongside Jeremy Keeshin from CodeHS, Krishna Vedati from Tynker, and Neil Fraser from Google's Blockly open source project. It was a great opportunity to meet people passionate about teaching programming.

Here we are, smiling it up for Dan Garcia's camera:

For a nice write-up of what we all talked about, you can read through this blog post. You can also look through all the slides presented here.

Here are my own slides, giving an overview of the current Khan Academy programming curriculum:

After the panel, I had the chance to speak to fellow teachers of programming, like Dan Grossman from Coursera's Programming Languages class, to hear about their own experiences. If you want to keep tabs on what computing educators like Dan are thinking about, check out the newsfeed and resources on computingportal.org. I'm looking forward to hearing more from ACM Ed in the future!

Wednesday, October 30, 2013

Handouts: Graph Paper and Cheat Sheet

Last weekend, we used our Khan Academy programming curriculum for an in-person JS101 workshop for GirlDevelopIt San Francisco. I prepared two handouts for that workshop:

  • Graph paper: A sheet with two 400*400 grids, for students to sketch their drawings on before transferring the numbers to code. That was inspired by a Programming teacher in the Los Altos School District, who starts off her students with an exercise where they turn code into a drawing on graph paper, before they even know what code is. In our workshop, the students used the paper mostly for the Design an Animal project.

  • Cheat sheet: A one-pager with our documentation - it's literally our documentation in paper form. I encourage students to use the online documentation ultimately, but some students found it handy to have a physical paper to look at when they're starting to learn, so that they don't have to scroll their code off screen.

If you are using our curriculum for in-person workshop or teaching, you might like to make copies of those for your students. If you're using any other handy handouts, please do share with us here.

A more newbie-friendly documentation

After giving a talk on developer experience last week, I was reminded of something that's been bothering me about the Khan Academy developer experience: the documentation.

Previously, our documentation was a one-pager with columns for "Shapes", "Mouse", and other categories. We auto-generated the documentation based on tagged programs, dynamically arranging the columns to balance them and alphabetizing the functions inside each column. It was handy that we auto-generated the docs, because we could add more to the docs without a code change, but it also had its drawbacks:

  • The columns weren't always in the same place, so you couldn't memorize the spatial location of what you were looking for.
  • Sometimes, the most "advanced" column would be at the top, showing functionality that newbies didn't know yet, and making it harder for them to find what they are looking for.
  • On a similar vein, inside each column, the more "advanced" functions would be at the top, burying the more basic, far more commonly used functions (like arc and bezier appearing before rect and ellipse).

Before:


For our audience of mostly beginner programmers, it's important that our documentation be newbie friendly. It should be very easy for them to find what they're looking for, and to not get distracted by things they're not looking for. Given those goals, we've renovated our documentation in the following ways:

  • The sections are now ordered in rough "curriculum-order", the order in which students learn things if they go through the tutorials.
  • The sections are now rows, not columns, so that the student can process a section before getting distracted by other sections on the side.
  • Within a section, the functions are also in curriculum-order, instead of alphabetical. Given we only have ~9 functions per section, it seems better than alphabetical order. If we grow beyond that, we may reconsider.

Now:


At the bottom of the documentation, we used to have links for students to go off and learn programming in other places (including different languages). We now focus that section on links for students to specifically learn more about JavaScript and ProcessingJS, the subjects of the documentation. We've also added a section on the differences between the original ProcessingJS and the Khan Academy version, like disallowing the non-JS Java syntax and making the default angle mode be degrees instead of radians.


If you are using us inside a classroom, you might also be interested in the "cheat sheet" version of the documentation, which I made by simply stripping out all the interface around the documentation panel. You should certainly encourage your students to use the in-page docs, but there are some students that prefer having a paper cheat sheet to look at instead.

We hope these changes will improve the developer experience for budding Khan Academy programmers!

Monday, October 14, 2013

Ayuda a Traducir Nuestro Currículo en Español!

Back in September, Khan Academy officially launched our Spanish website, which includes Spanish subtitles and translations for the majority of the core exercises.

Since the launch, we've added a lot of content to our programming curriculum, so most of it is new and un-translated. We would really love for Spanish speakers to be able to learn programming in their own language, and we're hoping that some of you can help with the translation. We would especially love for developers to get involved with translations, since our curriculum is highly technical and not so easy to translate by a lay-person.

How can you help? Well, we use crowdin.net to manage our translations, and anyone can sign up and contribute translations. The moderation team will review them, and if there are no issues with them, they'll be downloaded into our codebase nightly and uploaded on the next deploy.

Here's an overview of the parts of the programming curriculum that can be translated:

  • Titles, descriptions: Like "Intro to loops" and "Learn how to use a loop to repeat code over and over." Most of these are translated now.
  • Challenge messages: In the coding challenges, each step is accompanied by a title and description. When a student doesn't write correct code, there's often a message that pops up and tries to guide them towards improving their code, like "Hm, is your y value big enough?". There are about 5-15 messages per step, and that's the bulk of what is untranslated now. For translating those, it's probably best to actually try the challenge out and see what the messages are talking about. If you're a developer, you should have no problem completing the challenge (and if you do, let me know!).
  • Syntax errors: Whenever a student writes code in our editor, we run JSHint over it and pop up a message to warn about syntax errors, like "Unclosed string!". Based on feedback from the challenges, we've been adding and improving those messages, so there are a few more of these that need translating.

You can find the first two types of messages by visiting our crowdin.net project page and searching for “learn.cs” in the page. There's also a lot of messages here. Crowdin shows the percentage translated, so you can tell at a glance which areas need the most help.


There are a few parts of our curriculum that cannot yet be translated:

  • Talk-throughs: These are our alternative to videos, with English audio narrating over live code editing. We need to add a dubbing or subtitle mechanism to them. (Update on Nov. 27, 2013: We now have a transcript mechanism for them.)
  • Comments: Any single or multi-line comments in official programs, talk-throughs, and challenges. We try to keep them small and nouns-only when possible, for now, since we don’t yet have a translation mechanism for them.

In the meantime, we would love your help in translating the hundreds of message strings that are on Crowdin now. We’d also love to hear where and how you are using Khan Academy with Spanish-speaking audiences. Muchas gracias!

Saturday, October 5, 2013

New tutorial: all about functions!

We've added a whole tutorial on functions, complete with five talk-throughs and three challenges. The tutorial covers defining custom functions, passing parameters to them, returning values, variable scope, and the "magic" global functions in Processing. Check it out!

Tuesday, October 1, 2013

Challenges: 56,000 completions in our first month!

“...this. is. AWESOME!!!!! I love you guys. This is so fun, I probably won't get any sleep tonight.” - Dallas

In just our first month, just over 14,000 students have completed a Khan Academy coding challenge — nearly 56,000 challenge completions total! Overall, students completed 58% of the challenges they attempted, but over the last week, our completion rate jumped to 66%, likely thanks to improvements made based on user feedback.

We started with just a couple of challenges, but have steadily been adding more to make sure we assess every part of programming that we teach - like drawing, animation, and strings.

We really want students like Dallas to enjoy these challenges and to learn from them, so we’re gathering user feedback and aggregating statistics. We use the feedback that students send in to help us improve the challenges (like making the grader accept more variants of correct answers), and we look at the statistics to see overall trends in how students are doing in each of the challenges.

“My Favorite Foods” is the challenge with the highest completion rate (77%). It’s a simple challenge to use the text() command multiple times.

“Mickey Mouse Ears” is the challenge with the lowest completion rate (46%). It’s also the challenge that comes after a talk-through which many have said is too much of a jump from the last one - so that probably means we need both a talk-through and a challenge before those.

“Beautiful Day” and “Parting Clouds” are the two challenges with the highest spin-off rates (8%). Apparently, everyone likes suns and clouds!

Going forward, we’ll continue to monitor both the aggregate stats and manual feedback to improve the challenges. Our goal is that every student that does actually understand a concept can get through the challenge of that concept, and that they aren’t blocked by confusing instructions or a bad grader. If we find that many students aren’t completing a challenge because they don’t understand a concept well enough, then we need to look at the curriculum (did we actually cover it well?) and also at the challenge ramp-up (do they need a simpler challenge to start off with?).

Stay tuned for more improvements!

Saturday, September 28, 2013

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.

Tuesday, September 24, 2013

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.)

Monday, September 23, 2013

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

Saturday, September 21, 2013

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.

Tuesday, September 17, 2013

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.

Sunday, September 15, 2013

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.

Tuesday, September 10, 2013

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?