7th Grade Career Day

Years ago, I came across this question on StackOverflow: Career day in kindergarten: how to demonstrate programming in 20 minutes?

I thought it was a great question with some even better answers.  The top answer suggested doing a live programming demonstration.  But instead of writing code, the presenter would act as the computer and the students would be the programmers.  For the kindergarten presentation, the answer recommended making a butter and jelly sandwich as the "program."

"I'm going to pretend I'm as dumb as a computer, and you guys tell me how to make a sandwich."  And when the first kid said "open the bag of bread!" I ripped the bag apart and let bread fall randomly all over the table.  That got a lot of giggles.

I remember thinking one could have a lot of fun with the concept of being the "computer" and having the kids in the audience be the "programmers."  A few years ago, I got just such an opportunity.  Instead of kindergartners, though, I would be presenting to 7th graders.  And instead of one presentation, it would be six.  

That meant I needed something that required little or no raw materials, was age appropriate, and could be set up and broken down quickly.  I came up with what I believe is the perfect solution: drawing a rainbow on a whiteboard with dry erase markers.

Since 2016, I have given the following presentation to hundreds of seventh graders in small groups of about 8 - 15 students at a time as part of our middle school's annual 7th grade Career Day.  Over that time, I have refined the demonstration beyond a simple description of programming.  I manage to teach multiple programming concepts to absolute beginners in the span of about fifteen minutes.

Drawing rainbows

I start the same way as the StackOverflow answer, by asking the students for a show of hands if they think computers are smart.  I then proceed to tell everyone with their hand up that they are wrong; computers are, in fact, quite dumb.  Computers do only what you tell them and you have to tell a computer everything you want it to do.

"To prove my point," I say, "let's draw a rainbow.  I'll be the computer and you will be the programmers."  I stand in front of a whiteboard with a basket full of dry erase markers and ask the students, "What do we do first?"  

JACK: Draw an arc.

ME: [Make a sweeping motion with my hand in front of me; they need to tell me every single step.]

SARA: Pick up a marker.

ME: [Pick up the green marker.]

SARA: No, pick up the red marker.

ME: [Pick up the red marker; I now have two markers in my hand.]

SARA: Put down the green marker.

ME: [Drop the green marker on the floor.]

ME: [I'm now holding the red marker facing the students (not the whiteboard).]

CARTER: Turn around.

ME: [Spin around 360 degrees and continue facing the students.]

CARTER: Face the whiteboard.

ME: [Turn and face the whiteboard.]

CARTER: Take the cap off the red marker (by this point the kids are picking up on the fact that they need to be quite specific) and draw a curve on the whiteboard.

The process of getting the first two colors drawn varies with every group.  But, there are some steps that I always include.  

1. It always takes 3-5 commands before I start drawing anything on the board. This drives home the point that they need to be specific, without taking so long that they get frustrated. Read the room.
2. I always drop a marker.  This is the moment that captures their attention without fail.
3. I never pick the red marker first unless they specifically tell me to get the red marker.  
4. I never take the cap off the first marker until they explicitly tell me to.  I've found most groups do actually tell me to do this step.  They adapt quickly to the concept of the exercise.

I make the kids really work for the first red arc.  I'm more forgiving with the orange arc. For example, I uncap the marker even if they forget to tell me to.

Occasionally, the kids will argue about the order of the colors of the rainbow.  I have fun with that when it happens.  Do schools not teach ROY G BIV anymore?

Error handling

The first time I did this presentation, I panicked because there was no yellow dry erase marker.  That's when I came up with my favorite twist on this "presenter-as-computer" concept.  I would use the missing yellow marker as a way to talk about error handling.

After drawing the red and orange arcs, one of the students will tell me to pick up the yellow dry erase marker.  I look in the basket of markers.  There is no yellow marker.  I throw every other marker color over my shoulder as I search through the basket in a panic.  I pace back and forth in front of the classroom.  I look under the desks, in the garbage can, anywhere I can think of to find a yellow marker.  The more ludicrous the spot, the better.  Finally, after about 15-20 seconds of frantic searching, I pace to the corner of the room, sit down on the floor, pull my knees up into my chest, and rock back and forth staring at the corner of the wall.  I make a real ass of myself.  And the kids eat it up.

I then stand up, pick up all the markers, and explain to the students that what they just witnessed was an unhandled error.  I explain that errors are inevitable.  I tell them that anticipating and handling errors is an important part of programming.  We then have a short discussion about how best to handle the error of the missing yellow marker.  I let the kids decide.  Usually they choose to either skip the yellow arc or use a different color, such as brown.  Once in awhile, they will suggest I use a highlighter.  I applaud their out-of-the-box thinking, then inform them I wasn't brought in to ruin their teacher's whiteboard.

Don't repeat yourself

Once we're done discussing error handling, it's back to drawing arcs.  I ask if anybody noticed anything about the first two arcs we drew.  Eventually, someone will point out that there were a lot of common steps.  

I then explain that "Don't Repeat Yourself" is an important concept in programming.  One way to avoid repeating yourself is to create functions to perform repetitive tasks.  I suggest we create a function called "DrawArc." I write "DrawArc" on the whiteboard.

Although many of the steps of drawing the two arcs were identical, I point out that there were some important differences.  I ask them what was different between the two arcs.  I then write the differences on the board as function parameters.  

They always figure out color on their own.  Next, they go with something like "size" or "starting point."  I talk about how important it is to be precise in our naming and that different algorithms (approaches) will be easier to code than others.  That's when I recommend using Radius and Origin as the remaining parameters needed for our DrawArc function.

Encapsulation

Next, I point out that if we were making a game, we might want to be able to show a rainbow in multiple places.  It would be annoying to have to call DrawArc seven times for every rainbow.

I ask what we can do to avoid that situation.  Before long, someone will suggest we create a function like we did earlier.  I write the name of the function on the whiteboard and facilitate the discussion as they settle on the correct parameters:

Evil geniuses

Occasionally, I will get a student that takes advantage of the fact that I will do exactly what they tell me to do.  I usually indulge these students because it really increases engagement with the whole group.  I've thrown markers (in safe directions), spun in circles until I was too dizzy to keep spinning, and even chugged an entire bottle of water.  Inevitably, these students will see how far they can push the envelope.  When they do, I put my foot down ("No, I will not chug a second bottle of water."), then talk briefly about programmer ethics.  And when I say briefly, I'm talking about a 15-20 second aside that usually includes the Spider-Man quote, "With great power comes great responsibility."

Final thoughts

As part of the school's requirements for career day, the first five minutes or so of my presentation consists of me boring the students with information about my own past and what kind of things I do on an average day.  It's very dry and I make no attempt to liven it up.  Why?  Because I love to see the looks on their faces when I drop that first marker on the floor and they all sit up to try to figure out what the heck is going on.

The utter wackiness of the demonstration makes the whole thing a surefire hit.