Mike Hewner's Homepage

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:

• CompSci 100 Feedback Summary
• CompSci 108 Feedback Summary
• CompSci 149s Feedback Summary

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

CS100 is a your basic CS2 course, providing an introduction to data structures, big O, and of course plenty of practice coding tricky problems. This course is a great favorite of mine to teach, mostly because of the office hours. It’s just fun to work with students who are just starting to get serious with Computer Science; they are still capable of having fun just getting the computer to output the right stuff.

For extra credit, we gave the student an opportunity to write a song about Computer Science. There were some super awesome submissions. One of my favorite lines is the refrain from this adaptation of Avril Lavigne’s Complicated (Noelle Suaifan):

Why’d you have to go and make Java so complicated?
I see the way you’re forgetting to import packages gets me frustrated
CompSci’s like this, you
And you code and your program implodes and takes forever to load
and you don’t insert that node and your code is the biggest mess
But promise me you’re never gonna switch your major to Art History
No, no, no

Two other great submissions:

• Far Away From Java Code by Haoran Liu and Hanxiao Mao (lyrics)
• Algorithms and Data Structures Theme Song (adapted from the Pokemon theme song) by Jennifer Villa and friends (lyrics)

Check out the complete list.

Pretty much all of these songs are about how difficult the assignments in CS100 are. Should I be concerned?

This is a post not really about what I did, but what 3 of the high-school students I worked with did. I met Gil and Claus in my automata class at GHP this summer. As part of the summer research project, they worked on developing their own kind of automata and ended up with something similar to a Neural Network. This fall, Gil, Claus, and Anirudh contacted me and proposed continuing that research but expanding the neural network connection for the Siemens Science Competition. Although I agreed to advise them where I could, this project was basically completely done start-to-finish by Gil, Claus, and Anirudh.

What eventually came out of this project was an attempt to build a Neural Network capable of optimizing the parameters of other neural networks. As the paper says:

The fundamental goal of this project is to create a backpropagation neural network that can determine the optimal training parameters to train another neural network with a different goal based on only characteristics of the training data. Such a neural network has the capability of improving the accuracy and speed of the training process for backpropagation networks used for any application.

In order to accomplish this Gil, Claus, and Anirudh researched neural networks, programmed their own network framework from scratch, and attempted to design a neural network that could help optimize other neural network parameters. Unfortunately the result they got was that the intermediate network wasn’t able to optimize properly. My opinion is their approach still has merit, and whether or not they get back to this particular project I hope they weren’t too disappointed with the negative result. This was a very cool project that required a great deal of both math and Computer Science to accomplish.

So one of the coolest traditions at in Duke is CS149s. Officially, it’s called the problem solving seminar. Unofficially, it’s weekly preparation for ACM ICPC competition. Students work hard in this course: every week they work on a problem set consisting of old ICPC competitions or TopCoder. It’s no small part from this class that Duke has gone to the ICPC international competition every year but 1 since 1994 (something like that anyway…don’t quote me on that).

Coming to Duke for the first time and never having competed in ICPC myself, being handed the reins of this course was a little bit scary. But lucky for me I had two incredible TAs – Kevin Kauffman and Siyang Chen. They helped me a lot in understanding what kind of preparation would be important and I like to think that I helped them with the pedagogical approach to teach it. I definitely changed the course – I made topics more explicit, I required a minimum number of problems each week, and I added a new post-contest project.

This year, Duke continued its streak by placing first in its region. My winning team was Jie Li, Yuqian Li, and Joe Keefer. I would like to claim some partial credit for that, but I’m pretty sure it’s strictly their own natural awesomeness. What I am especially happy about is that every Duke team managed to get 3 problems this year – including teams with non-majors and folks in intro CS. Everyone worked this year and I think it showed.

Here pictures of everyone and more stuff about the competition.

The post-contest project we did was programming ants for the AI challenge. If you’re curious, click here to watch the 8 Ant AIs we had submitted duke it out in the Ultimate Ant Throwdown we had at the last day of class.

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

One of the more interesting things that I came across in my interviews is the way CS majors decide on aspects of CS to specialize in. At Georgia Tech, students choose two of eight CS “Threads” and that choice determines about two thirds of their CS coursework. I like the idea of a flexible curriculum that lets students purse their CS interests. But, based on my conversations with students, I’m pretty concerned that many students are selecting their specializations without really understanding the trade-offs of their decisions.

I’ll be presenting a paper about this at ICER 2011. The abstract says:

As CS becomes a larger field, many undergraduate programs are giving students greater freedom in the classes that make up their degree. This study looks at the process by which students within the CS major choose to specialize in some area. In this study we interviewed student advisors, graduated CS students, and students currently in the undergraduate process about their view of CS and how they make decisions. The interviews were analyzed with grounded theory approach. The analysis presents four forces that affect student decision making. One, students often use the amount they enjoy individual classes as a sign of how well they fit with a particular specialization. Two, students often do not research, so they select specializations based on misconceptions. Three, students often rely on the curriculum to protect against poor educational choices. Four, students usually do not have a personal vision for what they hope to do with a Computer Science degree.

You can read my version of the paper here.

The final project for my game AI course was to build an AI for a modern board game.  My team selected Pandemic, a cooperative board game in which players need to both travel around preventing diseases as well as hoarding cards to “cure” diseases.

Emboldened by the success of my very simple AI for Mario Brothers, my team opted to use a simple search-based algorithm for evaluating pandemic moves.  In our implementation, game-state objects represented the state of the game, and had the ability to return all the legal moves available in a particular state.  These various moves could generate new GameState objects that represented the state after the move was performed.  This let the AI avoid understanding the many effects of various moves – the AI could simply “simulate” the move and then evaluate the “goodness” of the resultant game state.

I think this a perfect example of the sort of solution that is quite obviously a dumb idea in retrospect.  To see why, consider the answer to these two questions:

1. How many moves are possible in any given game state?  Answer: approximately 10, as long as you eliminate certain high-branching moves.
2. How many moves do you have to look ahead to plausibly identify good states?  Answer: About 20-40.

If you pause to consider the magnitude of 10 quintillion for a second, I’m sure you can identify the problem with my team’s AI.  As a result, the search tree has to be pruned aggressively.  As a result of that, the AI adopts a short-term greedy stratgey that can’t win:

Pandemic AI Video from Michael Hewner on Vimeo.

In retrospect, I wish the instructor for this class has given us a more constrained problem for a final project.  Ninety percent of my team’s time was spent on details of implementing the game itself.  For a similar project difficulty, I could have implemented 4 more sophisticated AI approaches.

You can see the code here: http://code.google.com/p/pandemic/

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.