Winner of SCS TA Excellence Award

I found out this week that I was one of two winners for our department's TA award.  I was nominated for my term in the fall when I TA'ed the third year graphics course for our game dev students.

It's really nice to be recognized for the effort I put into the term, from running a course blog to offering informal tutorials before midterms.  It's also kind of cool to win because I helped set up the award in the first place while I was the TA Mentor.

As an added bonus, the undergraduate TA who won actually TA'ed for me the first time I taught as a contract instructor. How cool is that?

I'm heading to campus today for our end of year reception, where we'll both be recognized as winners.

The Craft of Research

"I still don't know what the f**k I'm doing." I was so relieved when recently I heard a superstar researcher, a full professor in computer science, say this about research.  I have so much to learn about how to be a good researcher.  That's why I was really pleased with this book I just finished reading: The Craft of Research.

I learned about this book through Steph.  It was assigned for a class on how to do research that she's taking for her Masters in Computer Science.  I always wished I had such a class, so I figured reading this book might be a good substitute.

There are three main topics that make up the core of this book: figuring out what you want to research, putting together an argument as a solution to your research problem, and finally writing an effective report on your solution.

In the first stage, you have to get from a general topic to a specific question you and your readers want answered.  From that question you find your research problem, something that readers think is worth solving.  Whether theoretical or practical, your problem consists of a situation or condition, and undesirable consequences caused by that condition.

Once you know your problem, you can begin to argue the solution.  Each argument consists of a claim, backed by a reason based on evidence.  You acknowledge and respond to issues you anticipate readers will have with your argument as best you can.  You can also use warrants when needed to illustrate how your reasons connect with your claims.  Each reason or piece of evidence might require a sub-argument of its own.

Finally, once you have the structure of your overall argument, you figure out how to structure the written report.  The advice on how to approach drafting the paper in this section seems really good, and I look forward to using it for my next paper.  There are a lot of specifics on how to revise sentences to be more understandable for readers, including what kinds of subjects your sentences should have and how to use the appropriate level of abstraction.

With lots of concrete examples and really clear writing, I highly recommend this book to everyone.  It is a great way to mechanize the process of research for beginners, yet helps seasoned researchers by bringing exactly what they are doing back into their consciousness.  I imagine that many of the tips within would be useful for any level of experience.  This will be a source I will return to often.

What Double Fine Adventure Means to Me

The very first feature-length games I played were point and click adventures.  I have particularly fond memories of King's Quest and Day of the Tentacle.  But those memories were just about lost to me as that genre of games became less popular over the years.  Enter Double Fine and their recent Kickstarter campaign.

(Image from Kickstarter campaign)

When I first heard about the campaign and realized that Tim Schafer was the mastermind behind both this campaign and my beloved Day of the Tentacle, I immediately pulled out my wallet.  I can't remember how far into the campaign that was; there's a good chance they had already pulled in quite a bit of money by then.  But as I got email updates about the progress, I started to realize that I just helped make a bit of history by contributing to the most funded Kickstarter project yet.  And I helped show publishers that just maybe, at least some of the time, they aren't as needed anymore to make money making great games.

So what does the Double Fine Adventure project mean to me? It means a return of a game genre that was welcoming and accessible to a wider audience that included me (and my mom, for that matter!).  It means feeling joy while waiting for a new game that I know I will play, rather than just watch.  It also means a chance to watch the development of that game through the documentary series that will detail the progress.

Speaking of which, I just watched the first episode of the series. Maybe it's the baby brain talking, but I had a little tear in my eye.  I couldn't help but feel so proud and humbled by Tim and all he has accomplished so far.  Can't wait to see more, Tim! Keep up the good work!

Quick Tips for Teaching Mini-Courses

I've been running my 'Computer Science and Games: Just for Girls!' course for Carleton's annual Enrichment Mini-Course Program for five years now.  And so at this year's instructor's luncheon, I was asked to share some advice for running a successful course.  Below are some of my key points.

#1: Don't be Afraid to Challenge the Students

These students, who are mostly in grade eight and occasionally high school, are much brighter than we tend to expect.  I have been teaching them computer science topics since the very beginning and am always impressed with how well they understand the concepts (proven by the puzzles or discussions we have after a lesson).  Computer graphics and artificial intelligence aren't exactly easy.

#2: It May Be Better to Stick to High-level Concepts

I don't try to introduce really specific algorithms and I never do any math.  Depending on the audience, I think you could certainly do some math, but so far my course has worked really well by sticking to high-level concepts.  It's only a week, so I figure it's better to deeply understand a few things than to barely understand many.

#3: Lecture As Little As Possible

My entire teaching philosophy is based on this.  It's even more important for this age group.  I am always looking for interesting ways to avoid talking to the students.  There are always things I need to tell them, but if I incorporate doing that with discussions, videos, activities, and so on, then it doesn't even seem like I'm lecturing.  Someone at the luncheon said a good rule of thumb was to lecture only for an hour.  I agree, but add that it shouldn't be all in one chunk.

#4: Look Online for Proven Activities

Thanks to the Internet, we can find proven lessons for almost every discipline out there.  I love using CS Unplugged activities for my course because I know they work.  See if you can find something similar for your course.

#5: Try New Things

This year, I'm running an experiment in my mini-course with the help of some colleagues.  We're going to test how much of a difference story makes in teaching computer science topics.  Why not try out some new teaching techniques in your own course? If you approach it with confidence, the students will likely be forgiving if it doesn't go as planned.  And who knows, maybe you'll get a research paper out of it in the end. ;)

Lecturing for a First Year Programming Class

I gave a guest lecture at Carleton last week. It was for the first programming class that both computer science and non-major students take, taught using Processing.  I seized the opportunity to use some of my somewhat less conventional techniques and "lecture" as little as I could.

50 minutes at a time by I, Timmy

I was lucky to be basing my lecture off of a very solid set of notes.  The professor who put these together taught me my very first programming class back in 2002.  (I still have a printed and bound copy of his notes from that class.)  In my guest lecture, I covered the first part of Chapter 8: Shared Data.

This is how I prepared for the class:

• First I glanced over the notes and then started to type up the source code described within.
• While I wrote out the code, I thought about what might be the best order to present it during class, and in what chunks.  (My order did differ from the order in the notes, which makes sense - written and oral communication are not the same thing.)  I saved individual files as I went along so that each file showed a bit more progress.
• I went through the notes again and kept a detailed outline of what I wanted to explain and what I wanted to get the class to do.
• I used my outline to create some simple slides (mostly images to help explain concepts) and some printouts I wanted to make for a couple of demonstrations.
• Finally, I made a much briefer version of the outline that I could refer to during the actual class so I didn't get lost (especially useful given how sparse my slides are).

This is actually the first time I used this exact method to prepare, but I think it really helped me get familiar with the content and figure out the best way to present it. I will definitely do it again.

Here are some of the interesting techniques I used that made my lecture a lot more like a tutorial:

• I explained a concept to students and then asked them to implement it in the code (I had them download a file with an initial bit of code to start with, and offered the individual progressive files in case they could not finish the task).
• I had students read code and explain to me what was going on.
• I had students hold signs and point to each other to emphasize how variables can refer to the same data and the implications of doing so.  I gave new signs or had them destroy the current ones to illustrate changing the data.
• I asked the class many questions and sometimes lead them to ask a question they would be able to answer by playing with code rather than hearing it from me.

I was very happy with how the class turned out.  It was risky doing it this way given that I had not been their instructor since the beginning of the term.  This was also a smaller class with about 30 people present, so I'm not sure how well these things will work with a larger group (I believe it could work, but I have not yet had the opportunity to try).

What kinds of techniques do you use in first year programming lectures?