Sound advice

Wise words

I wish that my teachers growing up had more often told me to "Mess around" and "guess."

I took this photo at Scratch Day 2013 at MIT.  It was posted on a wall where participants were asked to write down what they did when they got stuck in Scratch.   If you are the kid who wrote this, thank you. 

 As both a student and teacher, I have noticed that willingness to follow the advice given above is often directly correlated with success in programming.  I find that once students are over the feeling that they have to get it right the first time, they start to experiment and "mess around" until they discover both the "answer" and the logic behind it.  

Marble Mazes and Programming

Marble mazes are a staple in the world of constructive play.  For reasons that I'm guessing are as deep in the genome as the reasons we like rhythms, melodies, and Angry Birds,  we like to watch a ball bounce down some sort of landscape, watching how the laws of physics play with our creation.  But why? Here are my conjectures.

1. It is a way to experiment with and understand our most constant frenemy,  gravity.  Just how much can we alter the path of a falling object before it ends up where it is going to end up (at least for the observable present).  Just how much do the angles and materials and sizes of things matter?  Is falling inevitable? How much up can we get out of some down? 

This marble maze is in the Holyoke Children's Museum, in Holyoke, Massachusetts.

I also see a lot of parallels between building a marble maze and programming.   If we are engineering a bit of software with a particular goal in mind, then we devise a set of instructions within the limits of a code, and see if we can get the result we are looking for. (E.g. I want to make the ball jump and then land and keep rolling)  If we are tinkering with programming we play with different sets of instructions, and our observations of the results help us to discover and gain fluency with the logic of the language.   We watch the ball bounce, roll, accelerate and decelerate and it teaches us about the structure of the physical world and the rules it sticks to.  

If we have a certain outcome in mind, and it doesn't work, we engage in the debugging process - finding the unknown mistake in our logic that is preventing things from ending up as we'd hoped.  E.g. "Oh, it doesn't make it over the gap unless it is going fast enough...it doesn't go fast enough unless it is rolling for a few seconds in one direction...if I want it to roll in that direction, I will need to place more pieces here...no here.  Ok that worked!" 

Computers in Pretend-Play

The "compooter"

A few months ago, (likely as a result of seeing her parents nearly constantly pecking away at their laptops) our daughter started to pretend to be on the computer herself. She created this here computer.  So, some thoughts (Besides the "awwwww", which I do say when I see it) :

 1. We already know that kids develop competencies with real life skills through play that imitates what they see adults doing all day.    So, score one more for developmental psychology and the value of play.  I would be interested to find out if there is recent research on how computing shows up in pretend play. I know, lmgtfy. 

2. It's interesting to imagine what letters look like to four year olds.  They have a clear pattern - a letterness - but they are not quite known yet.  I guess it's how Greek looks to me - "I kinda know that letter is a whatsit called, looks like A but does it say L or something? And that one, whoa what does that one do, I don't know..." 

3. It's a nice balance of chaos and order - a.k.a. creativity?

Direct Instruction, ok I said it.

That sums up the debate I go through just about every day as an educator.   Despite a whole lot of progressive training and thinking, I too sometimes wish "they would just get it so we can keep going..." 

For some kids,  just seeing the first two scratch blocks connect and the cat move as a result of a space-bar press is enough send them off and clicking, experimenting and watching results, picking up understandings on the fly.   For many others, I've reluctantly found that more direct instruction at the get-go has helped them get engaged sooner. 

Thinking about this after class last year, I wondered: "What criteria should I use to decide when to offer a student 'direct instruction'?  What do I even mean by that term?

At first, there seemed to be an obvious answer: "When the student is asking for help, answer their specific question."   When students feel confident and curious enough to ask a question, they make our job easy and gratifying.  They ask a dream question like: "How do I get him to move in the other direction?"

But it turns out these are often exactly the students who really don't need the direct instruction.  They ask, and we get to respond like the teacher from a book we read in grad school: "Well, take a look at how you made him go to the right. What are those blocks saying? What do you think?"  Then they get back to puzzling and we move on. Yay.  I didn't have to do any direct instruction after all. 

I think it gets complicated when students are in a far more hazy, and less happy/engaged zone, and they are asking something that indicates we might just be about to lose their interest,  something like, "Wait, so what is the cat supposed to do..."?

If I answer, "It's not supposed to do anything, you get to invent something for it to do!" I may get a smile and observe a renewed sense of confidence, but I will just as likely get a look of disbelief and see the student slump down a notch.  The thought bubble pop up: "I really don't get this."

These are the moments, I think, to decide on a kind of direct instruction where we go from "teacher" to "pushy experience-sharing person."  I might say something like, "Here's something I think is cool, can I show you what I was thinking when I was trying to figure it out?"