How did you fail today?

During our regular weekly Techie Thursday lunch, we were discussing failure and how to learn from it and how to encourage our students to be okay with failure.  One teacher, a parent, said that she had started asking her kids every day, “How did you fail today?” They then talk about the failure, whether it was due to something they did–poor planning, not enough effort.  Or whether it’s just a perception of failure or out of their control.  And then they talk about how to recover, what to do next time.  They treat failure as normal, as part of learning and growing.

I loved it so much, I told Geeky Girl about it on the way home, and she shared a small failure with me and I shared one with her.

I fail on a regular basis.  I will admit that I don’t like failing sometimes.  We all like the feeling of being good at stuff.  It feel exhilarating when things are going smoothly and you’re shining in the spotlight.  Heck, it’s great to watch people who are performing at their best.  But in order to get to that point, you have to fail a lot.  And that failure can feel terrible.  We have to live up to those failures, though, and not be devastated by them.  That’s what we talked about .  How we help our students buffet the ups and downs of their academic lives and not feel like an A- is the end of the world?  Or is the culture such that that’s not possible? After reading Excellent Sheep, I feel that might be the case.  But I love that we had a conversation about it at a meeting that was supposed to be about technology.  As I often say, the issues we face are never about the technology, per se.  They’re bigger than that.

My Classes are Like a Safari

Or like being dropped in the wilderness.  Or like being thrown into the deep end. Or like going on an adventure.  These are all ways that my students have described what my CS I class is like.  When they describe it this way, they’re not frustrated or angry or anxious.  They’re excited.  At first, they were like “what? you’re not going to lecture or explain everything in detail?”  I did pause when everyone seemed confused by the same thing and do a brief mini-lecture, on functions, for example.  But generally, I have them read a bit about a concept, and then work through several examples and contexts for that concept.  It’s like solving puzzles or mysteries.  We’ve had a lot of aha moments where something finally sinks in.

It’s harder to teach this way, to let the students fumble their way through something, and I’ll admit I worry sometimes about how much they retain.  To counter that worry, I have tests and quizzes, but I can’t help but worry.  It’s also harder because I have to think through how an activity will go.  I can’t just lay out, this is a loop.  I have to work through how they’re going to use loops in meaningful ways.  Actually, Mike Z just posted something that is similar to how I approach things.  You lay out some instructions for something that seems simple and then discover why loops are cool and/or useful.

I also do a lot of running around.  I’m working on having students do more helping of each other, but we’ve only really been coding for a few days, so I’ll give them another couple of days before I truly let them wander the wilderness.

Lost in Translation

I often forget how embedded I am in the language of computing.  Even before I took up programming, I was quite familiar with how to use Unix commands and the difference between my computer and the server where my web site actually lived.  Having grown up in a GUI world, my students don’t see any of the underlying structure of the computers and servers they interact with.  I expose some of that but it takes a while before it becomes second nature to them.

For example, I gave this instruction verbally, “type /Users/Documents” and more than one student typed “slash Users slash Documents”.  Or conversely, when learning about types, I had the written instructions, “type type(6)”, and some students assumed I had typed type one too many times and just typed in 6.  Sometimes with the parentheses.  And then, when asked to define what hello is in either this context: type(hello) or this one: hello=”world”, they are baffled.  It’s a word, it’s a string, no, it’s a variable.  Their concept of variable in math is that a) you’re usually solving for it and b) it always has some value.  In CS, of course, variables sometimes don’t have values (giving you an error), or they can have values that are very different from a number: lists, functions, dictionaries, words, sentences, files, etc.  That’s more mind-blowing to students than one might think.

As Garth said in his comment to my last post: “Teaching programming is like teaching a foreign language but the student has to understand logic, major problem solving, technology and memorize the language, all at once.”  I’d say, too, that they’re having to learn new English words alongside their “foreign” translation.  It’s like having learned English, you find out there’s a whole dictionary full of words you never learned, and now you have learn them plus their translation in another language.  Painful.

But kind of fun.  I’ve said to both my CS I class and my 8th grade class that what they know right now, 6 weeks into school is more than any of their teachers know about computing (with maybe one exception besides me).  They makes them smile even as they struggle to learn this new context and language.

I have a tendency to throw my students into an activity without much explanation and then explain things after they’re done.  I know it can be unnerving.  I had a student ask a very good question after class yesterday.  She asked, “What is it that we’re doing exactly?  Is this a language?”  Once I explained, she then asked if there were other languages and how they worked.  The “throwing them in the deep end” approach leads to this kind of curiosity usually.  They often feel the need to figure it out.  That need to figure it out is what will keep them going when they feel a little lost.

Teaching, Programming, and Practice

Over the weekend, I read a couple of blog posts by programmers who were teaching workshops to either students or teachers, and who were quite amazed at how hard it was to teach. They didn’t come out and say that they thought teaching would be easy, but they implied that by talking about the challenges they faced.  They weren’t condescending at all, just clearly surprised.

And then there’s all the venture capitalist folks who think software is going to replace teachers any day now.

Education, teaching and learning are challenging.  People are often surprised by what happens in the classroom, of having to deal with different levels of students, of realizing that students don’t have some foundational information that you thought they would, of realizing that just telling them something doesn’t mean they actually learn it.  There is research out there that helps, but every day, you have different variables, so you try things.  And sometimes it works.

I don’t mean to be hard on the programmers trying to teach, or even the software developers trying to create something that will help people learn.  But the truth is, teaching is something we’re still trying to figure out.  If we had all the answers, then good teachers would be spitting out students who know everything they need to know and are equipped to continue learning all the time.  But we know that doesn’t happen.  And it’s not just that those good teachers miss a couple of students.  Sometimes they miss a lot.  Because there are other factors.  Learners learn in different ways.  Learners face challenges like poverty, drug addiction, lack of parental support that take up their cognitive capabilities, leaving little room for learning math or science.

And for the record, I find programming hard.  And I have much of the foundational knowledge to do some pretty complex programming, but I still struggle with it.  It takes me hours sometimes to do pretty simple things.  In part, that’s because my job is teaching, not programming, so I have less practice.  During the school year, I probably spend less than 2 hours actually programming things.  The things I do program are simple activities for my students.  They’re not complex, real-world problems.  I’ve tried to remedy this in a number of ways, trying to make time for some “real” programming (I did some this weekend, in fact), but I spend most of my off time, grading, giving feedback to students, planning ways to teach basic concepts, all that good stuff.  So I admire programmers, because I know they’ve had some practice and I admire them for wanting to share their knowledge with others, but like programming, teaching takes practice.  And I’m going to guess that programmers spend as much time teaching (at best) as I do programming.  We have a lot to learn from each other.

Food + Algorithms = Learning

IMG_20140924_084037452_HDRAs I’ve mentioned, I’m focused on making sure students understand underlying concepts without the need for code.  I really believe that if they know what a loop is conceptually, they can create a loop in any language.  Yesterday, I tackled both the concept of an algorithm and basic programming concepts by using food.  I broke the students into groups of 3 or 4 and gave each group a set of supplies.  For the morning class, we had bagels, cream cheese, and strawberries.  The afternoon class had crackers, cheese and pepperoni.  Each group got a plate, necessary utensils and napkins.  Then each group selected a person to be the robot.  I conferred with the robots and explained that they needed to be stupid.  They don’t know what cheese, bagels or crackers are.  They know basic directions and that’s it.

IMG_20140924_084335344As you can see from the pictures, the students had fun, especially when the directions went awry–as they did in every group.  In the morning class, we had time to test out the process using me as the robot.  That was instructive for many of the students as well.  In some groups, the robots helped out a little too much.  I didn’t.

In both classes, we discussed what was difficult about the process.  The fact that the robots could just be told to pick up a bagel or cracker was difficult.  They realized quickly how much humans know compared to computers.  I asked how they overcame their difficulties.  It was interesting how many different programming concepts they used to complete their tasks.  Some groups defined their objects.  They described what each item was and where it was located (object-oriented programming, ftw!).  Some defined functions, like spreading.  They all repeated actions in a loop.  Some simply said, “Repeat.”  Some used ctrl-c, ctrl-v, which I thought was hilarious and awesome.  They all used conditions, mostly in a “while” loop: “move hand down until you hit an object.”   And we talked about how to orient a robot using things like coordinate plans or just left and right, up and down.  I also suggested that their plate could serve as a clock, so they could say, put your hand at 3 o’clock.  I went through basic programming concepts after the activity, and I was able to connect each concept to something a group did during the activity.

IMG_20140924_134349079_HDRThe homework had been to read some material about algorithms and write what they think an algorithm is and how it relates to programming.  After the activity, I asked if they would revise their answer.  Most said yes.  Many said, just saying it’s a list of instructions isn’t enough.  They talked about figuring out how many steps to break the problem down into, that some of those steps need to be small and detailed.  Some even talked about having algorithms within algorithms, so that you might have an overarching set of instructions, but smaller sets within the larger one.  They also talked about what the robot knows and understands versus what humans understand, and that they needed to figure out how the robot is seeing things or understanding things, so that they know how best to give instructions.   In one class, that discussion led to questions about how real robots work.

What I’m now looking forward to is seeing how this plays out withIMG_20140924_134422706 actual programming.  One thing I’ve noticed this year, both because I’ve made some changes, and because I have more students, is that girls like to talk about what they’re learning.  Some of my students have even said as much, so I think I’m going to build in time after every concept to have a conversation about it.  I think it allows them to create their own ways of remembering and understanding the concept.  They use their own contexts and metaphors.  And I’m there, of course, to make sure it’s accurate.  I knew this intellectually before, but seeing it play out is really interesting.

While the Teacher’s Away

Last week, I was away on a Middle School field trip, and so I left my CS II class of 6 students to their own devices.  I gave them an online quiz to complete and told them they could use a book, Google, whatever, in order to answer the questions.  They chose to show up in my classroom during our regular class meeting and work together.  For the written answers, they were the same.  They asked me first thing if I noticed anything unusual about the quiz.  To which I responded: you mean like how everything was the same?  It was funny.

Their longest answer involved writing an algorithm to make a sandwich.  While most of them wrote a paragraph explanation, one student posted an image as a response.  The image is clearly what everyone based their answer on.  But you have to admit, it’s good CS (click to see bigger):

 

algorithm

 

After class today, most of the students stuck around to do more computing while I mostly checked email.  One student is working on “I survived the CS I exam” t-shirts.  Really, I think they should just teach the class from here on out.

 

When the tools get in the way

Back in the day, computers were fairly stripped down.  To interact with them, you used the command line.  To code, you used a text editor that didn’t look that different from the command line (emacs, pico, vi).  Even when gui interfaces came along, to make web sites, you often just popped open a text editor (which always functioned as a plain text editor) and then uploaded your files through an FTP client or through the command line (which did more often than not).   Many great tools came along that somewhat simplified this process, but some also hid this process, so that if you used, say, a wysiwig html editor, you really didn’t understand that when you saved a file, you were also uploading it.

Nowadays, people don’t edit straight html that much (outside of some professional environments).  Now, they type in boxes (as I’m doing now).  If you want to teach writing straight HTML, the tools are sort of working against you.  TextEdit on the Mac requires setting it to plain text to make it HTML safe, but even it chokes a little on things like apostrophes.  Other text editors do a good job, but then one must use an FTP client or command line, which is probably fine if you’re working with, say, 17-20 year olds, but is painful if you’re working with 13 year olds.

We’ve made a text editor plus FTP client work, but still, every class period, we run into some difficulty.  We’ve overwritten things here or there and all kinds of other things, so I’m switching to an browser-based editor that hides some of the FTP stuff.  You have to put in the information initially, but after that, it’s saved and assumes that’s the site you’re always working with.  The editor will work with several languages, which will be helpful as we begin to work with some javascript later.  Also, it shows the file structure, so that students can visually see where they are.  That should be helpful going forward as well, as we need to create folders, etc.

Teaching at this level means really thinking about the tools you’re using and whether or not they’re getting in the way of learning the things you’re really teaching.  At the college level, maybe you start out with the “tools of the trade”, but at younger levels, starting with Eclipse or IDLE can lead to frustration before students have even begun writing a line of code.  We’re not teaching software engineering after all.  We’re teaching students how computers work, and how we can make them do cool things for us with just, as one of my students put it, “some random letters and stuff.”   I’ve thrown my high school students into command line stuff and for some of them it’s mind blowing and painful.  Which is why I’ll switch to something that’s much more straightforward and closer to how they already use their computers.  I do want students to understand the innards of computers, but I don’t want them to be frustrated by it.  I want them to be fascinated by it.  So we’ll use tools that are easy while exposing some of what those tools hide.

The Hard Part of Computer Science: Algorithmic Thinking

Most students come into a CS class thinking that the real challenge of Computer Science will be learning syntax for a particular programming language.  And while curly braces and semi-colons do indeed sometimes trip people up, the real challenge is creating the algorithm you want to code in the first place.  You can always look up syntax, but constructing the algorithm is where the hard work gets done.

Dawn DuPriest and I are on the same wavelength these last few days.  She, too, is thinking about this problem, and has some good strategies for helping students through.  She’s working with 6th graders.  I’m working with sophomores and juniors and I’m having the same issue.

My CS II students were asked to write a program to encode a message and then write a program to decode a message.  The pattern they were to use was a Caesar cipher (shifting each letter over a few in the alphabet), so that the decoder could more easily be written.  This is a program I thought they could have done in a single class period (1 hour and 15 minutes), but so far, we’ve taken about an hour and a half (end of one class plus all of the next).  I wrote the programs in 4 or 5 lines each in about 15 minutes total.  This is supposed to be review, not new material.

A couple of things come to mind.  I think last year I held their hands too much, helping them come up with code snippets to solve their problems, so they can’t remember, for example, how to loop through a list.  But two, I think they didn’t abstract out from the coding they did do to the algorithmic level.  They’re not really breaking down the problem into parts.

Here’s how I broke it down:

1. Get a string via input.

2. Loop through the string and change each letter according to a set pattern.

3. Save the resulting string.

That’s pretty basic, though that second item can get broken down further, because you have to figure out how, exactly to tell the computer what the pattern is and do the substitution.  I’m not allowing the use of dictionaries/hash tables yet, so that piece is a bit tricky, and there are at least two ways to do it that I thought of off the top of my head, but there are probably infinite ways!

They have a quiz on Wednesday, which is open book, but I think I’m going to add an algorithmic thinking question to it and discuss it with them thoroughly.  They’re not going to make it through object-oriented programming if they can’t break down their problems into parts.  I’ll let you know how it goes.

We’ve already talked about algorithms in CS I, but seeing what’s happening in CS II reminds me that I need to really drive this concept home.  I have changed some things in CS I that I think will work better, including more pair programming.  Dawn found that group work really helped.  Talking through the possible strategies and having a peer steer you correctly can help.  So, we’ll see.

Net Neutrality and other hot topics

This year in CS I, I decided to start each class with a current event article.  We did this last year in my Race and Gender class, and it was a great success.  So far, we’ve discussed the naked photo fiasco, the rumor that Twitter might change its feed to be more like Facebook’s and filter stuff, and today, net neutrality.

We’ve had some great conversations around these issues.  We’ve talked about how hacking happens, from social engineering and brute force attacks to code cracking.  We’ve talked about how algorithms shape what we see on Netflix, Amazon, and Facebook.  And we’ve talked about how networks work.

And that’s just in the first 10 minutes of each class.  I really like placing what we’re doing in context.  We haven’t started any coding yet, but I plan to continue the current event thing, with the students taking over in a couple of weeks.

Saying that CS is everywhere is one thing, showing that it really is, is another!

Getting into the groove

I’m getting there . . . sort of.  I teach back-to-back every other day, and I’m working getting a rhythm to that pace.  I start with homeroom, move right into CS I.  I have a weird 15 minute break, then a MS study hall.  Then lunch, then Creative Computing, then another CS I.  Some days, I don’t have that study hall, which means I have about an hour.  This week, that slot is being taken over by meetings.  Bleh.  Tomorrow, I normally don’t have anything in the morning after homeroom, but guess what? I have a meeting.

I will get there.  I will settle into a routine, and it will be smooth sailing.  The classes are rocking.  I’ve had some technical rough spots getting software to install, but the kids are great and I’ve had some great classes so far.  They’re all really lively, and everyone seems eager to learn, so yay!  I’ll have more to say about the teaching tomorrow, but now I need to close up shop.