Reflections on My First Year of Teaching

I did it.  I survived my first year of teaching.  Exams are marked, and grades are submitted.  And while I still have students concerned about their results to meet with, I am finally able to breathe and spend some time reflecting on my experience.

[image via WikiMedia]

Over the two semesters of my first year of teaching, I taught five courses, mostly for the first time.  I had more than 1000 students and around 30 TAs.  I answered countless emails and forum posts.  I assigned 32 assignments.  I gave three midterms and 7 quizzes.  I made hundreds of slides, sometimes based off of existing content, and sometimes my own.

Needless to say, a large part of this job is management — of both time and people.

It was challenging at times, there is no doubt about that.  I had to relearn a lot of the material I was teaching.  This lead to many evenings spent on preparation, especially during second semester when I had three courses I hadn't taught before.  There were times I didn't get as far as I wanted, and fumbled in class.  There were times I wanted to crawl in a hole and stay there.  But I took comfort in knowing that I would never have to teach three courses for the first time ever again.

My students were generally forgiving.  Actually, my students were amazing.  They participated in class and thanked me for my engaging teaching style.  They sent me really nice comments in email.

Sure, not all students loved me.  My style didn't suit all of them, or maybe my slip-ups frustrated them.  Understandable.  Some probably didn't want to put in the effort to get the results they wanted.  I wish I could have inspired those ones.  Maybe some I did.

The thing that makes me feel the most energized of all is thinking about how to improve for next year.  I know I need to take a different approach to teaching my arts and social science students Python.  I know I need to switch up some of the examples for my Processing class and come up with more small examples. I need to adjust how I use the animation libraries with Racket and have some ideas for how to improve the course content overall.  There's lots of talk on what to do with our second first-year programming course, and I've had fun thinking about whether we should do it in C/C++ with Think Like a Programmer.  And of course there are a million little things to get better at that I can't possibly list here.

Most of all, this past year has confirmed that teaching is what I was meant to do, and I am so thrilled to be able to come back and do it again for another year.

My FDG 2014 Cruise Ship Conference Experience

You may recall that I was going to a conference on a cruise ship in April.  Well, I'm back from Foundations of Digital Games 2014 and am happy to report that I have found another new favourite conference and community.  The conference went well and I made some wonderful friends. Win win!

It was a strange experience, being on a cruise ship for (mostly) academic purposes.  This was my first time on one, and to be honest, I actually prefer the resort experience more when it comes to vacations.  An overwhelming sense of "fake" was prevalent on the ship, and while resorts aren't necessarily better, on a cruise all you have is the boat.  No beach, no grass, etc.  I also didn't love the dark, cavernous feeling on most decks of the boat or the lengthy process to embark and debark.  Even the mall was kept dark and lit with neon lights most of the time.

But there is a big advantage to hosting a conference on a cruise ship: nobody can leave! This was really great for building community.  It was easy to find other attendees and spend some social time with them.  For example, on one of the early nights, there was a disco party happening in the mall.  At that point I was alone, wandering around, wondering what to do.

When I ran into some friends (old and new), I finally had someone to dance with, even if we were stuck with disco for quite some time.  I would not have danced disco alone, but with them, I had a blast.

I have to admit that the upper deck with the pools was a nice place to prepare for my paper presentations (lab mates, if you are reading this: pretend I prepared weeks in advance and practised at our meetings).  Sitting on a swinging chair looking out on the ocean is a good way to relieve last-minute stress.

And boy, was I stressed.  I wasn't worried about the actual presentation being good, but rather whether the audience of heavy-hitters in the stories-in-games field would think the work itself was any good.  It was a rare moment of feeling the imposter syndrome.  To make matters worse, I had two talks almost in a row! Good to get them over with, but no chance for feedback in between.

Fortunately, everything went very well.  The talk was good, and the questions afterwards were even better.  A lot of the people I was intimidated of in the first place made a point to tell me that my talk was interesting.  Later in the conference I even got to have an extended conversation with one of them, giving me both confidence and ideas.  (Learn more about what I presented if you're interested.)

After my talks and a couple of other interesting paper sessions, I escaped on my own for a bit to decompress.  The sun was starting to set, which was the perfect time to take a stroll around the boat.

The next day, the ship docked in Cozumel, Mexico, where two of my new friends and I went on a tour of Maya ruins (apparently you aren't supposed to include an "n") and visited a gorgeous beach.  I was really glad to have my talk behind me at that point as I could completely relax and enjoy it!

 

The last day of the cruise included more interesting talks and a lovely reception and dinner to cap it all off.  I left the following morning on a high, and already trying to figure out how to ensure I attended next year's conference.  I left feeling like I had finally found "my people," from my awesome roommate to the researchers with the same interests.  Thanks FDG, and hope to see you again soon!

Planning for Go Code Girl 2014: Python and Pis

Last year's Go Code Girl was a great success.  This year, we wanted to build on that as well as try something a bit different.  Keeping the same overall format, we're hosting two days of coding fun: the first at University of Ottawa and the second at Carleton University.

Instead of teaching the girls Processing again, we'll use the turtle module to draw fun pictures in Python, LOGO-style! Then, on day two, we're going to see what we can do with the Raspberry Pi.

I'm a big believer in teaching programming to beginners in a visual way.  Not only is it more exciting than printing text out onto a console, but it can help understand commands in a more concrete context.  In can even allow for an embodied understanding of concepts, for example by imagining yourself as the turtle moving around the screen, leaving a pen trail behind you.

It's no surprise that I'd favour using something visual to introduce Python.  But as you may know, I tend to favour Processing over Python as a first language.  Why use Python? Partly to get more first-hand experience in teaching it as a first language, and partly because it seems to be the language of choice for the Raspberry Pi.

I know that in the three hours we have on the second day, we won't be able to do that much with the Pis.  I want to try to give the girls enough knowledge and confidence to continue exploring on their own, should they wish to purchase a Pi of their own.  Thus, it's important that they know a bit of Python.

As an added bonus, I can experiment with the turtle approach for teaching programming to my arts and social science students next year.  I imagine it would be a big improvement over how I did it last fall.

I'll report back on how things went and provide a link to the workshop materials when it's all over.

Our Two FDG Papers On Games and Stories Are Now Online

Our two papers accepted to Foundations of Digital Games 2014 have been edited, improved, and uploaded.  I'd love to hear your thoughts on them.

A Framework for Coherent Emergent Stories

This paper is based on my thesis work.  The paper can be downloaded from the project page.

Crafting satisfying narratives while preserving player freedom is a longstanding challenge for computer games. The quest structure used by many games allows players to experience content nonlinearly, but risks creating disjointed stories when side quests only minimally integrate with the main story. We propose a flexible, scene-based emergent story system that reacts to the player’s actions while maintaining a reasonable amount of authorial control over the story. Based on the philosophy of story scenes as kernels or satellites, we define a minimal story graph that initially contains mostly disconnected nodes. Over time, the graph is built dynamically from offered to the player. In this paper, we describe the framework of our system and present an early prototype game as a case study. We end with a vision of how our framework could be used to create more coherent, emergent stories in games.

Chronologically Nonlinear Techniques in Traditional Media and Games

This paper was accepted as a work in progress.  A colleague of ours seem interested enough in working on it even further, which may lead to a journal paper in the future.  The paper can be downloaded from the project page.

Although stories in games have become more sophisticated over time, their use of nonlinear techniques has not yet become as prevalent as in traditional media like novels and films. Writers have largely excluded nonlinear techniques from their toolbox, possibly because of fears of introducing inconsistencies when player actions alter past events. However, as we show through a survey of common nonlinear techniques seen in television, novels, and film, games can and have avoided these inconsistencies while maintaining gameplay agency. Many players prefer a high quality static story incorporated into strong gameplay, making the insight from this discussion immediately useful in designing nonlinear game stories. We also discuss some ways in which nonlinear techniques can offer both gameplay and story agency, hopefully bringing the quality of game stories one step closer to their traditional counterparts.

Why Functional Programming Leads to Reliable Software

Patrick Prémont, functional programming architect from local consulting firm Tindr, came to speak to my Programming Paradigms class last week. We're currently learning functional programming in Racket, so who better to speak to the class than someone who actually uses the functional paradigm in industry? The theme of Patrick's talk was that functional programming can create very reliable software when you combine the safety of functions without side effects with the compile-time checking of a good type system.

Functional Programming - Worth the Effort from Tindr Solutions

I personally got a lot out of the talk, so hopefully my students did, too.  I appreciated hearing that real companies are using functional programming in real applications.  I've really enjoyed learning Scheme/Racket as a student, but never really heard of anyone using the paradigm beyond perhaps the ability to create anonymous functions in otherwise imperative or object oriented languages.  The pitch about reliability made a lot of sense to me.

Another theme that struck a chord was the focus on using types to make the compiler tell you when you've done something wrong.  I've developed my own philosophy of effective programming throughout my (almost) 12 years of experience, and getting the compiler to catch your mistakes is a big part of it.  I always try to write code that doesn't assume its user will use it correctly, but instead try to produce an error when it's used incorrectly.  I usually think about this from an object-oriented viewpoint, so it was neat to learn how carefully designed types in a functional language can accomplish the same.

Check out the slides above for more details, and share your thoughts on the potential of functional programming when it comes to reliable software!