Mike Hewner's Homepage

I’m a big believer in student feedback. Even though students often can’t articulate the source of problems, going through and reflecting is an essential part of figuring out what I want to try going forward. So even in an environment like GHP where I’m not asked to formally collect evaluations, I always do. Of course, it really helps that at GHP in particular students are relentlessly positive. Seriously my worst review this summer was “not my favorite class by any means, but still good”. I wish that’s what my worst university eval looked like.

BUT, looking at the feedback ( and ), one thing that I am struck by is how much more satisfied by student feedback that is about course content and not about me. This is something that I think the Wicked Teacher of the West said first…but I can’t find the blog post now. When I student says “It’s a really great course” that of course makes me a little happy. But when a student says “I thought it was really neat how you could prove problems are incomputable by reducing them to other incomputable problems” that makes me think I did my job. It’s always about the student’s relationship with the content, not the student’s relationship with you.

I see that a lot more in my theory of computation course than I do in my fractals class – that makes me suspect I’m doing a better job in ToC.

Theory of Computation was different this year, I think because I didn’t have the same core of super-strong students who were really loving the course. There’s definitely a class culture that develops, and I’m not yet attuned enough to think seriously about how I can help its development. The course was still good, and I think I was able to smooth out some rough edges for some students. Remaining challenging however, is the issue of the two main proof techniques we do in class: the pumping lemma and incomputability proofs. If I teach this course again I’m gonna at least crack the pumping lemma.

Fractals was better this year. I found it less stressful, and I think the students learned more. Fractal dimension seemed like a big hit this time around, so I we can explore that a little more. We kicked things off with some very simple feedback functions and Chaos – I think that helped people get on board at the get go. I think affine transformations needs more exploration discussion and play. A little tricky without computers some times.

So Duke Spring 2012 is finished, and grades are in; it’s time for me to become an ordinary graduate student again. But before I do that, I think it’s reasonable to reflect just a bit on how the semester went.

All and all, I am happy but not ecstatic with how my first semester turned out. In general I think students enjoyed my classes and they learned a lot (and my course feedback reflects this). I was able to try out some techniques I thought would work well, and in general I had good success. Of course it also helped that my students were almost always enthusiastic and extremely conscientious.

One main thing I learned this semester is that I have to be a little bit more careful about how I manage my time outside the classroom. As a professor, there’s a lot I can do to help students and in the beginning it was really easy to put in a lot of extra hours. Not that I mind putting in extra hours for the students, but time away from relaxing and sleeping takes it’s toll. Towards the end of the semester, I just got exhausted and then I really couldn’t put in time sometimes when I really needed to.

Well, enough vagueness. Here’s what my students said in their written feedback, crudely summarized by me:

I’ve also attached the official numerical feedback summaries below.

(Contains .)

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 , 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’ »

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

.

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:

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 , 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

My slides for IO (annoyingly google docs won’t preview this one)

My slides for subroutines

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