Nothing Undone

A weblog, by Peter Jaros.

Let's Not Teach the Fundamentals First.

This weekend I TAed at RailsBridge Boston. RailsBridge is a day-long Ruby on Rails workshop for women of all backgrounds. It is awesome.

I can’t express the joy that comes from seeing the lightbulbs go off in someone’s head for the first time as they learn to program. The magic in the moment when they become visibly excited at the prospect of what they’re doing.

“So, "Hello, world" doesn’t do anything on its own, but if I put puts in front of it, I see Hello, world in the Terminal. Can I put something else after puts? Why is it in double-quotes? Will single-quotes work? What about no quotes?”

So many amazing questions. So much beautiful, exciting learning. To be honest, I’m not sure I enjoy programming nearly so much as I enjoy learning to program, and helping someone else find that joy is just as fun.

While I was there, I began to crystalize a theory of how we learn to program, and it goes something like this: You can’t teach someone to program. We each need to learn it for ourselves. All you can do is make the right information available at the right time. It’s like a gardener fertilizing a flowerbed. You can’t make the flower. That’s the seed’s job. Your job is to provide the right conditions.


The workshop is a series of short lectures alternating with hands-on work. Over the course of the day, students build a functioning Rails app and deploy it to Heroku. That’s pretty sweet. Zero to production in one day.

The lectures troubled me a bit, though. I hate to criticize them, because so much awesome volunteer work went into this, I may not know what I’m talking about, and I’m not sure I can offer a better solution. So take this as speculation.

Have a look at the slides from the first lecture, Intro to Ruby. Here’s slide #3:

Variables

  • Variables are used to keep track of objects, each variable holds a reference to an object.
  • No need to declare a variable
  • Ruby identifiers are case sensitive, therefore var myapple and var myApple are two different variables
  • $ - global variable
  • ‌@ - instance variable
  • [a-z] or _ - local variable
  • [A-Z] - constant

(Note to the future: Since the slides will probably change over time, you can look at the version I’m referring to on GitHub.)

Say I’m a Ruby newbie. I know nothing about Ruby but that it’s a popular programming language. I don’t know any programming languages. I’m not sure there’s anything in here that I actually care about. I think I’d pretty much let this whole lecture go over my head. Syntax and variables don’t mean much to me.

As a counterexample, here’s how I did learn Ruby, for real. TryRuby. No installation, no explanation, just playtime. That’s how I came to care enough to learn about the rest of the language.


If I’m right, there are two things in here that are interesting. One is that a laundry list of language features is not the most effective way to teach a language. The other is that we, as people who understand the details of the language have a compulsion to explain those details.

I mean, I know I do. Hell, sometimes when I’m in the shower or brushing my teeth or sitting in the doctor’s waiting room I notice that I’ve been explaining Ruby’s message-passing, everything-is-an-object OO model in my head to no one for the past 20 minutes. What is up with that?

But here’s what _why’s (poignant) guide to ruby (my second Ruby resource) gives you as your first Ruby code:

Read the following aloud to yourself.

5.times { print "Odelay!" }

In English sentences, punctuation (such as periods, exclamations, parentheses) are silent. Punctuation adds meaning to words, helps give cues as to what the author intended by a sentence. So let’s read the above as: Five times print “Odelay!”. Which is exactly what this small Ruby program does. Beck’s mutated Spanish exclamation will print five times on the computer screen.

Read the following aloud to yourself.

exit unless "restaurant".include? "aura"

[…]

Read the following aloud to yourself.

\['toast', 'cheese', 'wine'\].each { |food| print food.capitalize }

First and foremost, it gives you something you can read, understand, and probably even write. Guess the first thing Suzy does when she sees 5.times { print "Odelay!" }. That’s right, she types in 5.times { print "Suzy" }, because we as a species love it when computers say our names. And then she types 6.times { print "Suzy" }, because now she’s controlling the vertical and the horizontal. She’s writing Ruby. And guess what?

Suzy still doesn’t know what a method is.

Or an object, or a class, or even a string. She’ll discover those in time. When she does, they’ll mean something to her.

For that matter, most professional Rubyists (wild speculation alert) probably don’t entirely grok the relationships between Class, Module, and Object:

                         +---------+             +-...
                         |         |             |
         BasicObject-----|-->(BasicObject)-------|-...
             ^           |         ^             |
             |           |         |             |
          Object---------|----->(Object)---------|-...
             ^           |         ^             |
             |           |         |             |
             +-------+   |         +--------+    |
             |       |   |         |        |    |
             |    Module-|---------|--->(Module)-|-...
             |       ^   |         |        ^    |
             |       |   |         |        |    |
             |     Class-|---------|---->(Class)-|-...
             |       ^   |         |        ^    |
             |       +---+         |        +----+
             |                     |
obj--->OtherClass---------->(OtherClass)-----------...

But you don’t need to understand how it works, even though it’s awesome. You just need to be able to use it.

As tempting as it is, let’s not teach the fundamentals first. Let’s get people excited.

Comments