Mike Hewner's Homepage

So I haven’t had much opportunity to post about my classes at Duke, but it has been very cool. I’ve found students at Duke to be very conscientious and smart, and my office hours have been very busy which is always fun. Of course there’s still plenty of the usual student foibles to contend with – but if students were virtuous and self-motivated all the time, I’d probably be out of a job.

This semester I’m co-instructing CS100 – a data structures course that occurs as the second course in a CS major but also accommodates a good number of non-majors. One of the perks of this job has been the opportunity to observe my co-instructor Owen Astrachan’s lectures. Owen definitely has one of the most refined lecture styles of anyone I’ve worked with – he’s got a whole repertoire of jokes, dances, and asides to keep students engaged. Not only do these little diversions keep interest in what can be a fairly lengthy 80 minute lecture, but I think it sets the tone of the course as much more relaxed and fun than what you get just looking at the webpage alone. I definitely have some work to do in getting myself to Owen’s level, lecture-wise.

But in my own lectures, I’ve been very self-conscious about designing each class myself. I take my cue from Owen on the content covered, but I have my own ideas about how to convey them best. My experience suggests that you’re much better off designing your own class and making your own mistakes. Standing up in front of the room holding some other professors notes (no matter how brilliant) is gonna guarantee a medicore class at best. If you design the lecture with a modicum of care yourself, even if it goes completely off the rails you’re likely to do better.

Of course, once you get out of that “off the rails” class, you might take a few hints from the experts and change your style appropriately.

But, after a semester of this, I think I’ve got a structure I’m happy with for this large lecture style class. Here’s how I do it:

1. Prep work. Because most of the lectures I teach are officially considered 160-person, lecture-style ‘recitations’ I’ve been able to get away with requiring students to do a 1-hour-ish prep for each class (which I always collect and check for participation). This is just as awesome as you’d expect. Sometimes I use this as a review of topics covered elsewhere I don’t have time to do in class, sometimes I use it give students an example of the kind of problem we’ll be doing more of in class, and sometimes it’s an introductory problem that I’ll build off in class.
2. As you sit down. I always give students something to do as they sit down and get ready for class, which I put on the powerpoint as they arrive. Students are somewhat blase about actually doing it (bad)…but I still like it insofar as it sets the expectation that you are already in your chairs and working the minute class begins.
3. Running slides that convey the learning objectives. I know a lot of older professors scoff at the idea of learning objects that you spec-out in class, but I love ‘em. Mostly, it focuses me when I’m planning the lecture to decide exactly what I want to cover, keeping in mind that if students learn more than 2-3 things in class it’s a miracle. But I also like making it explicit to the students what my plan is: we’re not just having a chat, if you have finished class and you don’t know 1 2 3 then at least you know what you ought to be looking up. My slides always look like “After class today you will be able to … 1 provide the definition of words a b c 2 code programming problems of type d 3 explain why the efficiency of e is f. Then at the appropriate points in the lecture I have sides that are like “At this point in the lecture you should 1 know the definitions of a b c *next up is* coding programming problems”.
4. Active learning regularly. Wherever there’s a concept that’s important and they won’t grasp it immediately, I have some on-slide multiple choice. If I feel like it would be better served in some other way, I’m also willing to have a worksheet students fill out in class. But usually multiple choice with hands works. Only trouble – not every student participates in the in-class multiple choice, and it’s often hard to know when we are done and we can begin discussion. I’m considering clickers for next semester.
5. In-class coding. For a class like this which coding is a large part of the final goal, I like to have at least 1 in class programming exercise that the students submit (Duke has a great system that makes submission very easy). For one thing, it breaks up the 60-minute-doldrums…I feel like I pretty much have to move out of the lecture mode and force students to work on a problem that takes at least 10 minutes without my direct intervention. For another, it clarifies how what we just talked about will relate to the actually nitty-gritty of their assignments tests and projects. The key difficulty here is difficulty…students are very willing to stare blankly at the screen, not asking for help for 10 minutes. I’ve had some luck with providing a range problems…implement 1 function where you only have to write 1 line in my pre-written code, another where you basically copy the first and change a couple things, and a third that’s a new variation.

So yeah, nothing fancy but it has been working well for me. If you’re curious in practice, here’s a video of my class on trees:

The second class I taught at GHP was Theory of Computation (entitled “Does Not Compute”). We approached the problem of machine equivalence. This class was a lot of fun and students seemed to enjoy it. You can see my feedback, if you’re curious.
Continue reading ‘GHP Theory of Computation Class Summary’ »

Ok, so my good intentions to blog weekly about my teaching at GHP didn’t quite happen. It really is amazing exactly how intense teaching at GHP is, at least for your first year. Between majors, minors, all the various side projects, helping students after hours, and then prepping classes you are basically working every minute 7am-11pm (or later). After a while, it got to where I started daydreaming about taking naps. But I really don’t want to sound like I’m complaining…GHP is definitely one of the coolest teaching things I’ve ever done. But not a lot of blogging time.

So, here’s what I did in my fractals class:

Continue reading ‘GHP Fractals Class Summary’ »

The best part of the class was definitely mocking the stupid behavior of the wombats

Mark recently asked me to teach a guest lecture in his Media Computation data structures class.  The lecture was an introduction to the Simulation engine Greenfoot.  The goal was to introduce the idea of simulation, toss out a few key bits of terminology to prep students for later classes, and get students playing with the Greenfoot engine.  The course was 50 minutes for a class of 25 (though, in practice only about 15 or so showed).

Mark gave me some slides, I made a few modifications:

• I moved a few of the definitions to the end of the lecture.  Mark said the main goal was to get them playing with Greenfoot, so I figured I’d get to them if we had time.
• I turned a few question slides into concrete student activities.  Mark may have intended that…I adjusted them to my taste (mostly putting them in a multiple choice format so it was clear to students that would be accountable for the answers
• Cut a few slides, replaced some of the code heavy slides with live coding…once again could very much have been the intentio

What Went Well

Students responded well to the activities.  They also quickly warmed up to me, responded to my jokes, seemed to pay attention.  Reintroducing humor into my lessons has been a goal of mine, so I was happy with that.

What Went Poorly

We ran well over time, didn’t even finish the main coding activity (got to a chunk of it).  What made me feel especially dumb was that I wasn’t keeping close tabs like I should so I didn’t even adjust properly.  I was really glad I moved the less key slides to the end.

Part of the problem was I wasted time on the code reading activity.  The other issue was keeping the students in sync with me as we went through Greenfoot took a lot of time.  Very often I had to go back because somebody didn’t see how I added walls to the simulation or whatever.  In retrospect, I think I would have taken a page from Just in Time Teaching here…get the students ready to rock with a small tutorial assignment beforehand, so you can dive right to the interesting stuff in class.

But, excuses aside, letting class time get away from me was really bad and there’s really no reason it should have happened.

Tidbit

As is my custom, I had students fill out feedback forms.  This time though, I included a few content level questions on my forms:

1. Why do Computer Scientists think building simulations is a skill almost anyone could benefit from?
2. What is the difference between continuous and discrete simulations

I handed out these forms at the beginning of class.  I was curious to see if the students would answer them as they went or do it at the end.  The result was they did both, but I think either way it caused the students to pay more attention to what was going on in the definition part of the class.

Feedback

Student feedback summarized here.

My Slides

My slides.  I made it to slide 25.

So today I taught a database class in the Rapid Prototyping course I normally TA. This class is three hours long and when the schedule calls for a lecture it is brutal. This being my second time at the podium, I was somewhat prepared. I structured the class into lectures interspersed with various activities: a semi-multiple choice worksheet thing, some group work on a DB schema design, a fairly long section of independent/group coding on some SQL challenges, and then a live coding section with me at the helm (and them, at least in theory, coding along with me).

Overall, I think the lecture was good although my jokes fell sort of flat. I’m not sure if it was me, or the time in the semester, or what. I think I need to work harder at the onset to establish that there will be jokes, so that people know it’s OK to laugh. As it is, I worry they may be a little stunned and not sure what’s humor and what’s not sometimes. With activities, jokes aren’t as necessary to keep people conscious, but I’d still like to integrate them better into my style.

I think the activities worked well to break up the lecture and as usual they got almost universal positive feedback. I actually asked the students to install software (RazorSQL) on their laptops before class: I was actually gratified to see almost everyone did. It made me think that large scale coding exercises can really work, which is good news because I think it’s easy to let syntax wash over you if you don’t have to fight the compiler and think about it carefully.

As part of my prep for the class, I built a demo app. Basically we talked about 4 different ways to store data (flat file, pickle, XML, and DB) and I wanted them to have example code for each of them, even though we really only went into detail on the DB code. I’m not sure the time I put into that app was well spent; I really underestimated how long it would take to get it written. I sort of hope Keith uses it next year because I think it is a neat reference, even if we really don’t have time to walk students through it. The detailed work I had to do building the database part of it was extremely valuable though; I was able to discover all sorts of funky bugs and discuss them in class.

Stuff:

1. Summary of student feedback
2. My sides (well actually Keith’s slides with some additions of my own)
3. My Sample App – 4 Different ways to write a file in Jython

I’m acting as an unofficial TA for an unusual course this semester: “Rapid Prototyping”. This is a course for students with non-CS background: the goal is to get them up to speed with the basics of quickly building UIs and other apps for research. It’s not a gentle introduction to programming; after half a class on loops, objects, data structures, etc the class move quickly into building Java (Jython UIs and a variety of other fairly tricky topics).

I got the opportunity to teach that “recap of all CS1 (in a different language you don’t know) + building UIs” course. Three hours to cover a great array of topics, going off slides that the main professor prepared. Even just keeping the students semi-conscious for 3 hours is definitely a bit of a challenge (thought these are all graduate students so it’s better).

What I did:

Part 1: Language Intro: The main things I thought about was trying to reach lower skilled students and keep everybody interested for the whole time.

I supplemented the existing sides with 8 exercises designed to highlight what I thought were tricky things. I used my usual “ghetto clicker” technique of having students hold up fingers to indicate solution 1 2 3 etc.

Pros. The initial activities did well: most students had to think a little but in the end most got them right. Plus after the questions I would tend to get a little flurry of questions to help clarify understandings even from the people who did get it. Coding ones seemed to work given the talking and the fact that we could contrast the syntax between correct and what they wrote. This (as usual) also got good feedback in the mini-surveys I passed out. Plus, just helped to break up the lessons a bit.

Cons. Questions about finding bugs proved a bit problematical – I think I need to make it concrete by labeling the lines and asking to pick which one has the bug. Also a problem was knowing when students are done…need a way to figure that out even with the ghetto clickers.

Part 2: Java UI basics: I wanted to keep things practical so I opted for live-coded examples + the original slides.

Pros: Generally this went pretty well and I could hear a little flurry of typing whenever I started so people seemed to be keeping up to type as I did. Might be possible to leverage this into a more hands on activity where not everything needs to be coming from me. Got one enthusiastic respond from my surveys.

Cons: Obviously took some time but I think it was well spent. Major issue here was just exhaustion on my part – 2.5 hours is a long lecture. I think I need to plan more carefully at the end…I tend to plan beginning to end which leaves the end a little weaker. Maybe the other way would be better.

Part 3: Random stuff and talking about the assignment: I followed the notes with this, but it was difficult because it was unclear exactly how things fit together, which stuff was more important. Maybe rushed a bit. I think we could easily have taken the “learn about the assignment stuff” offline…and gotten more time. But what would we have done? If I had to do this again I might have tried to put some longer coding thing in the middle so that both the students and myself would not be so tired at the endpoint.

My Slides!

So working here at GHP, one of the things I get to do is teach seminars. Seminars happen outside of the usual classtime…they tend to be fun special-interest type things. I’m planning on doing a couple but I decided to do the first one on the Unix Command Line. Many of my students have installed Linux. Many even have feelings about which distro is better. But yet most of them have never used the command line. This is very nostalgic for me: ah for the halcyon days of my youth! I made it my business to install every distro yet basically had no clue what one would actually do with a distro once installed. Of course in those days just getting X to work was considered a major achievement.

So anyways I figured they should at least have exposure to some of the cool things you can do with the command line.

I organized it as a “scavenger hunt”. Basically I divided my students into 4 teams and then gave them a list of 30 things to figure out how to do on the command line. The rule was that everyone on the team had to be able to do everything for the team to get credit…when teams called me over I would quiz random team members. This was necessary because we had extremely varied levels of experience…I didn’t want the experienced people just going off and leaving new members to get frustrated.

Basically the whole thing worked like a charm once everybody started working (getting everybody started and on the same page was a bit of a pain). I never cease to be amazed by how much more intense student focus is when they’re working on concrete activities rather than listening to me lecture.

By the end, even students who basically had never worked with Unix before thought the whole thing was pretty cool. The teams basically only got through item 10, but when I asked them who wanted to continue the scavenger hunt next week everybody raised their hands. When I asked them if they wanted to just come back and continue from where we left off or research stuff outside on their own, two of my no-linux-experience girls argued that they just couldn’t wait till the next seminar without playing with it some more.

Funniest thing: a couple of students told me confidentially that they completely understood playing around with the command line for fun, but they weren’t completely convinced that it could actually do anything useful. I found this neat because it seems like normally people feel like command line stuff could be useful, but don’t want to actually go through the bother of learning. That said, I want to provide some persuasive examples next time about how command line stuff can be useful for real.

So unixy friends, here would be two helpful hints I could use from you:

1. What are some simple and concrete things you can do with the command line that even high school students could understand is awesome
2. I could use a few more items for my list of 30 command line things. I compromised with the girls: I asked everybody not to research stuff before the seminar so that all the teams could start on the same footing. But I said that I would make an auxiliary list of challenges for people who just couldn’t wait to play with in the meantime.

So I had a very nice leisurely lecture prepared that talked about the stack, buffer overflow attacks, and C varargs functions. We were going to do a few different activities and maybe even a live coding exercise which I’ve been wanting to try. Then I get an email from my practicum professor saying he wants to cover the stack, C I/O, Buffer overflow attacks, varargs functions, and malloc all in one class session – less than a day before I’m scheduled to speak. That’s over 50 unplanned slides worth of material, jammed into a 90 minute session that already felt a bit disjointed.

I was not feeling the love at that moment.

But what the heck. I figured this would be the sort of real world teaching experience I had been warned about.

Here’s what I did:

• Eliminated some of my more time-intensive exercises, or replaced them with quicker versions
• Cut a variety of content that I felt was less important, and distributed it as handouts + an instruction to read the book
• Created my “exploding kitten” exercise, designed to let me move through the malloc material slight faster. Basically I labeled certain slides with numbered kittens, and as I moved through the students had to record what deadly malloc error each kitten referred to. The idea here was that students would pay extra attention when they saw a kitten, and would know if they missed something so I could go back to it.

All this and I still had to end only 1/3 of the way through malloc.

So looking over my video after the fact, I felt confident that I had completely screwed everything up. But when I tabulated my student feedback, everything was pretty positive. Most common negative feedback: too much material and too fast. I can’t say I disagree.

Here’s the handouts, the powerpoint for the first part, the powerpoint for the second part.

You can watch me here: (part 1) (part 2) if you’re curious.

I’m staying home sick today so I’ve had time post a few things that have been in my blogging backlog.

So a few weeks ago I gave a talk about IO and subroutines in the introductory architecture course I was observing. This is the sort of course that CS survivors have nightmares about. The course consists of:

1. lecture – 90 minutes of agony in which the professor describes breathlessly how exciting interrupt driven IO is and you consider stabbing yourself in the eye with a pencil
2. lab – a frenzied rush to finish the lab assignment and get out before the TAs get in lecturing mode and you have to hear about interrupt driven IO again
3. and homework – in which you realize you don’t understand interrupt driven IO after all at 4am in a darkened lab attempting to understand a textbook that seems to have been translated from the original Latvian by babelfish

Now the regular professor is a great speaker who can make even the most mind-freezingly boring topic seem hilarious and interesting. Seriously, this guy went on for 15 minutes on the PDP-8 and while it was going on I completely believed it was exciting and extremely relevant to my life. He also has a grizzled war-vet kinda aura about him that suggests he takes no crap; if he was my professor I would live in mortal fear that if I don’t learn assembly he would one day swoop down upon me like batman and leave my bloodied body hanging from the Klaus rafters as a warning to the other slackers.

But education psychology research has long shown that funny lectures and the occasional beating can only get you so far, especially in this modern age where every laptop provides an infinite supply of funny cats. More to the point, expecting students to remember 8 different details about the way memory mapped IO and subroutines are implemented in assembly is just asking for sadness at exam time unless you’ve built in a little bit of practice and reinforcement.

What was most gratifying about the lecture was the fact that students really seemed to enjoy the activity I had them do. I was pretty concerned that since their regular instructor basically runs a straight-up lecture, they would be resistant to doing anything. Apparently there were a few slackers in the back not working but in general people seemed to do the activity, talk about what sounded like the right stuff after they did the activity, and rate the activity highly on my student feedback forms. Look here if you’re curious on the feedback I got http://bit.ly/aiElj0.

I chose the activities I did (fill-in code blocks and finding bugs in existing code), partly because they were easy, partly because I think students think of coding as a very authentic activity, and partly because I could have specific right answers to hold students accountable and give them feedback. I worry a bit that if I were to teach several consecutive lectures, keeping activities like these fresh could be a problem.

What worked less well was my complex datapath handout. I upped the ante on myself here, because this was something not really covered in the professor’s initial lecture notes. Even the book didn’t really explain this very well: I had to go in and look at a really obtuse and scary state diagram to figure out what was going on. And I have had theory courses, so I assure you that if I say a state diagram is scary, it absolutely is. But I felt understanding the connection between memory mapped io and the hardware was important, and I felt that it would help reinforce the datapath analysis they did in the previous chapter.

So I made a complex diagram. And it took me a very long time. And then in the end, I felt it was confusing. Next time I’m going to put my complex diagram on the fancy overhead box and take some highlighters to it. That will help I think.

My handouts
https://docs.google.com/fileview?id=0Bzy7KJkG2NnQZDBlNzA5YWMtMDg0Ni00NjFmLTg3N2MtOTdkYmY4N2ZmOTNi&hl=en

My slides for IO (annoyingly google docs won’t preview this one)
https://docs.google.com/leaf?id=0Bzy7KJkG2NnQZGM4ZWQ4MjAtNjc5YS00YzI4LWE2MmMtMTE0NzU3MmNhMWNk&hl=en

My slides for subroutines
https://docs.google.com/fileview?id=0Bzy7KJkG2NnQMGU2Y2I5YWMtMGRkOS00NmM3LTgxNmMtMzY4NDhiYTc3MTAx&hl=en

Video of me (part 1 & 2)
http://play.media.gatech.edu/v/public/buzzbox/cetl.gatech.edu/CETL_Practicum/mhewner3-2010-02-23A.mp4
http://play.media.gatech.edu/v/public/buzzbox/cetl.gatech.edu/CETL_Practicum/mhewner3-2010-02-23B.mp4