Tuesday, October 13, 2015

Live Coding and the Teachable Moment

The smart thing is to practice any code writing one is going to demonstrate in front of an audience. When I was was working in industry and preparing demos for presentations I would typically work though the program code several times before a demo. Over and over until I could get it right in my sleep. As a classroom teacher I sometimes get a bright idea 5 minutes before class starts. And that is where it gets interesting.

The other day I decided that as a class we would work out how to create a program to determine if a string is a Palindrome or not. I’ve done this several times over the years. It’s a great little exercise to practice string handling and loops. Later in the semester we will revisit it as we refactor it into methods. But I was doing it on the fly that day. It went very well. For a while. I kept things very simple.

Then I decided to get fancy which is seldom a good idea. I created an if statement that looked like this:

if (working.Substring(i, 1).CompareTo(working.Substring(working.Length - (i + 1))) != 0)
    isPalindrome = false;

It didn’t work. Can you see the problem? I didn’t. My students didn’t. It’s a horrible statement for understanding and debugging. There are just too many pieces all crammed together in one place. Just getting the parentheses balanced took a while. I know better than to write code like this but I was winging it. It wasn’t in my plan at all. So what do you do when demo code doesn’t work? Obviously you pretend it was done on purpose and model debugging methods.

The first step was to make things easier to see via the debugger so I broke the code down a little:

temp = working.Substring(working.Length - (i + 1));
if (working.Substring(i, 1).CompareTo(temp) != 0)
    isPalindrome = false;

It’s a lot easier to read and understand already though of course it could be simplified more – and probably should be. If you understand that I want to be comparing single letters you can probably see the error now. The Substring command on the first line is missing the second parameter which specifies how many characters to use. This became immediately obvious when I put the program into the debugger and looked at the values of temp. It wasn’t so obvious in a mash of lots of nested parentheses, parameters inside of parameters and generally to much “stuff” in one statement.

This led to a discussion of simplifying code to make it more readable, more debuggable and more maintainable. We’ll continue the discussion next class.  Just don’t tell my students I didn’t do this it on purpose ok?


Mike Zamansky said...

I'll frequently livecode unrehearsed or so as to keep the class alive and so that the class can also see that mistakes happen and that it can take way more time than it should to see a silly error staring you in the face.

The problem is, when you do that in your first of 3 classes in a row how do you keep the same vibe for the next two.

Brian Sea said...

I take the opposite tact. I tell my students that all my 'mistakes' are not on purpose. I then model debugging techniques, as you do. This behavior gives my students the license to experiment, make mistakes (because even Mr. Sea makes mistakes!) and then know a bit on how an 'expert' (HAHAHA!) recovers. My students are left to wonder if I really know what I'm doing or if the school made some drastic mistake in their hiring process.... though I make them question more when I tell students what their errors are without looking at their code.

Remember your blog post about the students learning how to handle a missed flight? Sometimes, the best teaching moment are unplanned. :-D

Garth said...

This is why I do most of my teaching in pseudo-code. No typos and no syntax errors. I am also a terrible typist. I also cannot talk and type at the same time. Of course now that I think of it I cannot do anything and type. Like think.

Alfred Thompson said...

Actually I joke about pretending that I did it purpose but my kids know I am joking. I think. In any case I do tell students about making mistakes all the time. Especially things like nesting issues. In this case when I had trouble getting the nesting right I said "Ok if it takes someone with 40 years of experience time to this right what does it say for people with 40 days of experience?" :-)

Mike Zamansky said...

Garth - there's either an internet meme or a "smartest man in the world" thing going on or some other joke to me made with:

"I don't always pseudo code..."

or maybe:

"When he write's pseudo code, it compiles with no errors."

I don't know, but just the prospect makes me chuckle.