Summer in the lab

The exams and projects have been graded, the grades have been submitted…it’s summer!  And summer around here means…research!  And research students.  So I thought it was a good time to write a “state of the lab” post, which I haven’t done in a while (possibly ever).

This summer I have 4 students working in my lab.  None of them have ever done research before, and none of them have taken any classes related to my research area—they are all fairly new to CS.  So as a research mentor and advisor, I have a bunch of tasks to accomplish this week:

• Get my students up to speed on the project.  In order to understand what they’ll be doing, they have to understand what we’ve already done, as well as the motivation behind this work in the first place.  This year I spent a lot of time the first day talking about the history and evolution of the project, to give them a sense of “place” and context for the work.  They also read past papers written by the research group as well as at least one paper from a lab doing related work—this gives them a sense of how different researchers approach the same problem.  Finally, they take a look at the code and data (at least a small subset) that we’ve written/collected so far, to get a sense of what they’ll be working with all summer.
• Get my students up to speed on the relevant background material.  As I mentioned, none of my current students have taken a course in computer networks.  So on Day 1 I gave them a crash course on networks, and the next day they had a crash course on streaming video.  In addition to (textbook) readings, this year I also gave them some of the labs that my networks students do in class, so that they could practice with the concepts as they read.
• Get them to touch a piece of the project.  I feel it’s really important for the students to develop a sense of ownership over the project as soon as possible, so that they feel invested in it.  This year, I’m having the students analyze some data that I’ve recently collected but haven’t had a chance to fully analyze.  Not only does this task get them working with Actual Data, but it helps me see how they’re thinking about the project, too, through the decisions they are making about the analysis.
• Teach them the tools they’ll be using on the project.  We use a lot of different software on the project:  packet sniffers, routing tools, version control, and 2 different IDEs.  So part of this week was spent practicing with these tools, so that their use becomes second nature.

Yesterday, we took a field trip up to Macalester to meet with CS faculty and research students from Macalester and from St. Olaf.  Each student gave a short talk on their summer research.  It was neat to hear about the research happening at our peer schools and to get the students together to meet and network with each other.  Even though my students had only been on the job for 3 days, they gave a great talk on the project!  They clearly understand the project and the work, and I’m excited about what they’ll be able to accomplish as a result.  (I think my “state of the project” talk on the first day really helped them put their talk together—they were able to clearly articulate why we were doing this research, as well as how what they’ll be doing will fit in to the project as a whole.)

Next week, the students will get to delve into the code base for the project, and start changing the design of our measurement tool.  I’m especially excited about this part of the project because it’s been on my to-do list for quite some time.  I’ve already had some good preliminary discussions with my students about the experimental design, and I suspect that these discussions will help guide the software redesign.  Hopefully the tone, and framework, I’ve laid down in the first week will help the students to make good progress next week, and in the coming weeks this summer.

Advertisement

A feel-good story for finals period

It’s finals period here at Carleton, and while I’ve spent most of my day so far wrestling with Moodle, tracking down missing grades, writing rubrics, cursing my large class sizes, and questioning my decision to not give a multiple-choice exam in the bigger of the two classes, I’m in a great mood overall.  Why?  Because my Intro students presented their final projects yesterday, and their projects rocked!

I’ve taught intro more times than I can count since I’ve been here, and every time I give the same project:  write a game or a simulation.  This project does a really nice job of requiring the students to synthesize and utilize everything they’ve learned, from specific programming concepts to design, implementation, and testing.  It also allows them a great deal of creativity—they get to select the game or simulation, and thus they get to explore their own passions and interests.  The one downside is that the students never got to see each others’ projects, except if they happened to be working in the lab at the same time.

A few years ago, a student emailed me after the class was over, asking if I could post the projects on Moodle.  I realized then that I was missing out on a great learning opportunity here!  Having students present their projects would give them valuable technical speaking experience, plus they would be able to see what their classmates had done (and possibly pick up some tips and tricks as a result).

So I started, last year, requiring students to present their projects during the scheduled finals period for our class.

The presentations run “science fair” style:  everyone sets up their projects on one of the lab computers, and then everyone walks around the lab, playing the other games and running the other simulations.  Students take turns walking around and answering questions about their own projects.  Each student fills out an evaluation sheet for every other project:  they have to mention one thing the project does very well and one thing that can be improved.  The class also votes on the best projects in various categories.

This little experiment has been more successful than I ever imagined.  The students get a real kick out of seeing each others’ projects.  They have to be prepared to answer questions from me and from their peers—they have, in a short time, become experts of their own projects, and enjoy showing off what they know and what they’ve learned.  It lends a celebratory atmosphere to finals, and ends a class on a high note.

But more importantly, there are conversations that occur among the students:  give-and-take on programming styles and choices, implementation details, and aesthetics.  As I went around the room yesterday, interviewing the students, they mentioned how they were going to incorporate suggestions from their peers—“I never thought of doing it that way until someone else suggested it” was a common phrase.  The peer feedback has in the past, and no doubt will this time, lead to better submitted projects overall.

What I really enjoy, though, is the obvious pride the students exhibit in their projects.  Students who barely said 2 words to me all term enthusiastically discussed their projects and the inspirations for their games and simulations.  They eagerly walked me through their code, pointing out things they were especially proud of in their designs.

Requiring presentations is definitely more work for me, logistically and time-wise.  But it’s definitely worth the expenditure in both areas.  And having better projects and happier, more engaged students is worth the relatively small investment.  I can’t imagine going back to the pre-presentation days!