A rough return to teaching

I’ve spent the past few summers (minus last summer when I was on sabbatical) teaching in a summer high school program. The program consists of 3 weeks of morning classes and afternoon guided research with a faculty member. I really, truly enjoy it. Teaching high school students is an interesting challenge. And by and large the students have been thoughtful, engaged, creative, and eager to learn. (It’s also very gratifying to see some of them as Carleton students post-high school!)

So when my colleague approached me last fall about teaching again this summer, I agreed. The program, I reasoned, would give me the opportunity to ease back into teaching before returning to the classroom in the fall. Plus I already had curriculum and research projects ready to go. What could possibly go wrong?

Suffice it to say that my envisioned triumphant return to teaching was anything but.

The actual mechanics of teaching? That went easier than I anticipated. The rust fell away quickly, much to my surprise. Being in front of students felt natural to me, and I found my teaching groove in short order. Pacing was still tricky at times, but pacing is always a bit of an inexact science.

What I didn’t anticipate, and what was roughest about re-entry: the small but active minority of students in my research group who decided early on that what I was teaching, human-computer interaction (HCI), was not Real Hard Core Actual Computer Science Because We’re Not Programming 24-7. And the undercurrent of disrespect for my authority, and for my RA’s authority (also a female computer scientist).

Now, I should pause and make it crystal clear at this point that THIS IS NOT NORMAL FOR THIS PROGRAM. The vast, vast majority of students are respectful and open to learning, and to expanding their ideas of what computer science is. I can count on one finger the number of research students I’ve mentored in this program who have been actively disrespectful of me and the subject matter. Sure, I’ve had some students in the past who were openly or less openly skeptical about the merits of HCI as a computer science field, but by and large those students at least came to appreciate what I was trying to teach them in the end, even if in the end they decided it wasn’t quite their cup of tea. And I’ve had some really interesting conversations with the objectors that have not only strengthened my framing of my material, but have also led me to reflect on what material I choose to include and how I include it. Both of which make me a better, more effective teacher in the end.

I spent a lot of time and energy during the program reflecting on where this particular strain of disrespect originated. Part of it likely relates to the HCI = Not Real Computer Science attitude, which is certainly not limited to the students in my class (and is still somewhat pervasive in the field, unfortunately). Part of it also likely relates to the general bro-ness and toxic masculinity that has always surrounded computer science, something that’s come into sharp focus lately with any number of recent news stories. Why did it emerge in force this year, and not in previous years? That, I’m still trying to figure out.

It’s been a very long time since I’ve had to deal with this level of disrespect in the classroom. I’ve been at Carleton long enough that I’m part of the fabric of the department — I am “accepted”. Gaining seniority (in age and in status) over the years increased my credibility with the students, giving me more authority in their eyes. The close-to-gender parity we have in our faculty also helps quell at least some of the disrespect. So I was caught off-guard.

Once I recognized what was going on, I went into damage control mode. I summoned up my Authoritative Teacher persona from the depths — she hasn’t been around much since my pre-tenure days. I blinded them with science — or, at least, hit them hard with the scientific basis for every psychological or design principle we discussed. I randomly threw out my credentials, just to remind them that Yes I Do Know What I Am Talking About As I Have A PhD In Engineering And Years Of Experience. I occasionally let out my Inner Bitch and used my Evil Mom Stare with abandon.

But I also second-guessed almost everything that I did, and said. I put up my guard in ways I haven’t had to do in a very long time. Teaching, and every single interaction in this program, took up at least twice as much of my mental and emotional energy. Teaching in this program is normally draining, but this year, at the end of the day, I truly had nothing left in my tank. And that was not fair to my family or to myself.

Lots of people have asked me if I’ll teach in the program again next year. I honestly don’t know. On the one hand, I still believe strongly in this program. I have met and worked with so many incredible teens and young adults in this program. By and large, my students are thoughtful, creative, eager to challenge themselves, whip-smart, and funny. Most of my students did outstanding work on their research projects, and embraced the experience and challenge from start to finish. And I enjoy serving as a role model to high school students, both as a female computer scientist and as an HCI researcher. But on the other hand, this summer exacted a huge toll from me. I was exhausted, and bitter, every single day. Why does it feel like it’s just my responsibility to hang in there, fight the good fight, and change their minds? How productive, and happy, would I be if I didn’t have to deal with this crap?

Hopefully, I won’t experience anything like this in the fall when I return to the classroom full time. Or, if I do, at least I’ll be prepared to recognize it and deal with it. That, I suppose, is the sad silver lining in this experience.

 

I survived

Paper chain link The paper chain link shown on the left represents the end of a long, difficult, stressful 6 months.

In my last post, I talked about how I made this paper chain as a way of both coping with my stress and reminding myself that this really tough period in my life was finite. At the time, the chain had 44 links, one for each day until the last day of classes winter term. As I write this (Tuesday evening), the last day of classes for winter term is tomorrow (Wednesday). After tomorrow, the next time I will teach a regular class will be September 2017 (!) — due to a combination of a teaching-free term this spring (though I’ll still have my chair/administrative and research duties, and probably a couple of independent studies) and a sabbatical for the entire 2016-17 academic year.

In retrospect, I probably could have more easily handled just one term of what I’m calling “extreme teaching” (2.5 courses), than two terms in a row.* Around week 7 of winter term, I reached the point where I was so mentally exhausted that I couldn’t imagine being able to put together another class plan, write another test question, deal with another set of office hours, talk to another student. (Granted, that week we also had 2 job candidates on campus, so that may also have sped up the mental exhaustion.) I really had to push hard to stay minimally on top of things. The chain was really helpful that week for maintaining perspective on the situation. Leaving town for SIGCSE last week also helped, as it gave me some much-needed physical and mental distance from campus. But overall, it was a tough slog.

I do try to learn something from every situation I’m in, no matter how good or bad, and I certainly learned some valuable things from this extreme teaching experiment:

  • Sleep matters. Oh, does it matter. A few weeks into fall term, I decided that I was going to prioritize getting 7 hours of sleep per night, even if this meant that things weren’t going to get done. (Those of you who know me in real life know that this is a HUGE mindset shift for me.) Getting 7 hours of sleep, I believe, kept me sane, and it made me more productive and focused.
  • Teaching 2.5 classes effectively while also chairing a tenure-track job search and a department is pretty much impossible. My saving grace was that I’d taught my two “regular” classes multiple times in the past (and one of them this past fall), so I had a pool of resources from which to draw. I also made a conscious decision to change very little about either class—this was not the time to innovate!
  • Protecting junior faculty is a noble goal, but should not come at the expense of my own health and well-being.
  • Being honest with students often pays off. I was up front with my classes about my crazy schedule this term. I was also up front with my Software Design class about the things I was learning alongside them (because I didn’t end up having as much time between fall and winter terms to learn a couple of new packages/tools that they were using this term). Now, the reason I can get away with this is because I am old a senior member of my department, and carry a bit more authority in the students’ eyes. I could never have done this while a junior faculty (and certainly not as the only woman in the department as I was back then). The one downside is that I think sometimes students were reluctant to come to office hours for fear of “disturbing” me, so if I had to do this again (please, dear god, no), I’d be more explicit about office hours being for THEM.
  • Things may not get done on my perfectionist schedule, but if I keep plugging away they will eventually get done.
  • Many deadlines are more fungible than you think. Also, if you have a track record of being highly dependable, people are more willing to cut you some slack if you need it. I am so grateful for the people who recognized I was struggling and gave me extra time to get things done/in.
  • The self-care experiment worked. I didn’t always do what was written on the paper link, but if I didn’t, I improvised with something else. For instance, if the link said to mediate for 5 minutes but I knew I’d be too tired/busy to do so, I’d take the “scenic” walk back from my classroom building to my office so that I’d get some extra thinking/outdoors time instead. I ended up doing something for myself every day.

Spring term will come with some challenges of its own (including trying to hire a visiting faculty member in a really tough job market!), but I am looking forward to having time to work on outside-the-classroom projects that have been on my list for a while and, more importantly, time to think and reflect in general. While I don’t think I’ll be making any more paper chains in the near future, I do plan to continue to incorporate some regular self-care into my life. And while I wish I hadn’t been quite so busy these past six months, overall I really enjoyed the work I was doing and all of the fabulous students I had the pleasure to teach these past two terms—and many days, that alone was enough to keep me going.

* The normal teaching load at my institution is 5 courses per year (2-1-2 or some similar combination). As department chair, I get a course release, so my load is 4 courses per year. This year, that was supposed to be distributed as 1.5-2.5-0 over fall-winter-spring. But when we failed to hire enough visiting faculty, I deferred my course release to a future year to teach an overload in the fall (so we wouldn’t have to cancel a crucial core course for the major). Hence the 2.5-2.5-0 “extreme teaching” load.

Gearing up for the start of a new academic year

Monday marks the start of a new academic year at Carleton—it’s the first day of classes for fall term. As I write this, it’s the Friday before classes start, and I’m in my usual Friday-before-classes-start full-fledged panic about the start of the term.

office

I don’t look very panicked in this picture, though. (H/t to my colleague Dave for taking this photo.)

I’m actually in pretty good shape compared to previous years in terms of preparation. I’ve got the first week’s worth of readings and daily assignments posted on Moodle for both of my classes. I have a vague sense of what I’m doing on the first (and second, and third) days of each class, although I still have to find/tweak my handouts for the first day (and print out my photo rosters!). I revamped the problematic rubric for the first major project in my Computer Networks class. I’m in conversation with all three of my Comps (senior capstone) groups to nail down specific meeting times (two of the groups are sharing a class time slot so we need to subdivide the slot, and we won’t need the full time slot for the third group).

I also locked in specific times for research on my calendar and filled in my known meetings/obligations, too.

So why am I so panicked?

Some of it is just general teaching nerves. I’m meeting a whole bunch of new-to-me students on Monday. Surprisingly, I only know about half of the students in my Computer Networks elective (a side effect of having so many majors is that I no longer know all of our majors). I’ve taught a few of the students in my Data Structures course before, but most of them are strangers to me right now. I know that in a couple of weeks, the students will be familiar to me and I’ll have a good sense of the dynamics of the class and of individual personalities, but meeting new people is stressful.

A lot of it is a sense of dread over my workload. We failed to hire all of the visiting professors that we need to staff our courses this year. This means that we are still looking to hire people to teach Intro in Spring term (and maybe Winter, too), and that we had to cancel a bunch of classes, but it also means that I am teaching an overload so that we did not have to cancel one of our core courses for majors in the fall. Also, due to some bizarre scheduling constraints, all of my courses are loaded into just two terms (Fall and Winter). So, originally I was scheduled to teach 4 courses this year (1.5 in the fall, 2.5 in the winter, 0 in the spring). Now, I’m teaching 5 courses, with 2.5 each in fall and winter.* Luckily, they are all repeats for me (and I teach one of the courses twice this year), but that’s still a considerable load.

Adding to the workload, too, are my chair duties, which on top of the usual chair shenanigans include running another tenure-track search (our third in three years, which means I’ll have run a search in each of my 3 years as chair). Plus two of my junior colleagues are being observed in the classroom this year, leading up to a tenure review and a third-year review next year. (Which, thankfully, I won’t have to chair!) So there are meetings and all sorts of other things related to preparing my colleagues for their respective reviews too.

On top of everything, there are other changes, which adds to the general stress even though the changes are positive. I’m loving my new office and my new neighbors, but still getting used to being 2 floors separated from my colleagues. (I can tell I’ll be running up and down the stairs a lot this year, which should at least keep me in shape!) We have a brand new faculty member who’s awesome and wonderful and has lots of questions about how things work here—which reminds me of how much mentoring/protecting of junior faculty the senior members of our department are doing and will need to continue doing over the next few years. My family’s all still getting used to the new schedules at home, since school started for my kiddos this week.

Finally, next year I’ll be submitting my materials for promotion to full professor. While I’m confident about my case (I have tremendous support from my department and have a solid case), nothing is guaranteed, so there’s a general background stress around “have I done enough? should I have done things differently? what do I need to do this year to shore up my case?”.

All of this has led to some sleepless nights recently and a general sense of dread about the academic year ahead. I like to go into the academic year on a positive note, but at this point I’ll take “semi-well rested” and “prepared enough to muddle through”.

I sometimes start new academic years by picking a theme or resolution for the year. If I had to pick one for this year, it would be “self-preservation”. I know things will be tough until the spring, so I’m going to focus on ways to do my job while not burning out. I’m going to focus on survival and not reinventing the wheel (i.e. revamping things in my classes just for the sake of revamping them if I have something that works well enough already). I’m going to (and have already started to) say “no” with abandon (or, “I’d be happy to participate, but not until after mid-March.”). I’m going to stop at “good enough”.

But I know I’ll also do what I do every academic year: have the privilege of meeting, teaching, and learning from an incredible group of students. And that’s what keeps me coming back year after year after year—even the years I know will be challenging.

* The half course in fall and winter is for advising Comps—we get one course credit spread over 2 terms for every 3 groups we advise.

Reuniting with an old familiar course after a long layoff

As you could probably tell from the radio silence, things have been crazy around here. December and the first part of January were a blur of grant writing (and frantically finishing up simulations/analysis to generate data for the grant proposal) and job applications, and oh yeah, some holidays and travel. And in the midst of this craziness, class prep for a course I last taught in Spring Term 2012 (almost 3 years ago!): Intro to Computer Science.

Intro CS used to be my bread-and-butter course. I taught at least one, and typically 2, sections of intro each year through most of my time here. Intro is probably one of the most challenging courses to teach, partly because students come in with wildly varying backgrounds and partly because there’s so much to learn and grasp early on—the learning curve can be steep, and trying to keep track of all the syntax while also learning to think in a completely different way about problem solving is tricky and can be daunting. But it’s precisely because of the challenge, and because the students learn so much and grow so much over the course of the term, that it’s one of my favorite courses to teach.

Recently, we’ve handed over much of the teaching of intro to our visiting faculty. Part of this is because we often haven’t hired our visitors by the time we have to craft the next year’s schedule, so it’s easy to assume that whomever we eventually hire can teach intro. Part of this is also to give our new and visiting faculty a break—by teaching multiple sections of a course over the year, they are doing fewer new-to-them preps, which eases their burden. And our visitors tend to do a nice job with the course. The price of this, unfortunately, is that old fogies like myself don’t get the pleasure and the privilege of introducing students to the discipline like we used to.

Last year, when I was making the schedule for this year (one of the “perks”(?) of being chair), and weighing everyone’s teaching preferences, I saw that I had an opportunity to teach a section of intro, so I scheduled myself for one of the sections.

The re-entry has been a bit rough. Fortunately a lot of what I used to do and a lot of my old intuition about how to approach various topics has come back as I’ve reviewed my old class notes and my sample code. We’ve switched from Python 2 to Python 3 since I last taught, which I’ve taken as an opportunity to rewrite most of my sample code (which also helps with the recall). However, I tend to over- or underestimate what we can get done in the course of a 70 minute class (mostly overestimating at this point), and I’ve forgotten just how much trouble students have with a few key concepts early on in the course. My timing is off, too—I feel like I’m spending too much time explaining things and not leaving enough time for coding and practice in class—but I think I’m starting to get a better handle on that mix of “talk” and “do”.

There have been some benefits to the long layoff, though. I have some new ideas that I’ve been trying out—for instance, starting class by having students work on a problem by hand for 10-15 minutes, to get the intuition behind whatever we’re coding up in class that day—that I might not have considered if I was teaching intro more consistently. I’m reading the textbook more carefully (because none of the readings are familiar anymore and I’ve switched textbook editions), so I have a better sense of the level of preparation students have when they come into class after completing the daily targeted readings and practice problems. I’ve done more live-coding in class, because as I’ve been re-working my code examples I’ve noticed places where it would benefit students to see me code and think out loud in real time, rather than just walking them through pre-written code. Basically, I get to see the course with fresh eyes, without all the stress of it being a completely new prep.

So I’m immensely enjoying the intro experience again, and while on balance the layoff was partly beneficial, I hope that I don’t go quite such a long time between teaching intro sections again.

The art and science of choosing textbooks

Even after 11+ years of teaching, I find that selecting textbooks for a class is much more of an art than a science. Sure, I can apply “scientific” principles to selecting a textbook—evaluating how certain key topics are covered, weighing the ratio of code to theory, vetting the explanations and examples—but in the end, I never quite know how my choice will go over. In the best case scenario, I identify a book that both my students and I like and find effective. But honestly, if I can at least identify a book that we can both tolerate, I count that as a win. Sometimes, even with my careful selection process, I get things wrong. And sometimes, a book that’s worked wonderfully in the past falls flat with the next group of students.

I found myself in that last situation last spring, when I taught Software Design. In the past, I’ve used a particular textbook for the design patterns portion of the course. I like this particular book a great deal: it’s irreverent and clever, but most importantly, it presents each design pattern through the lens of an extended example, coded up in Java. In the process of developing the example, the students see a lot of code, and are also introduced to the pitfalls and common variations of each pattern. The students also see examples of each pattern in practice, giving them context for the usage of each pattern.

Last year, for the first time, my Software Design students complained about this textbook choice. Loudly. They hated this book. It’s too long, they said. It’s too condescending, they said. It lacks gravitas, they said. (OK, they didn’t say exactly that last one, but that was the gist of the criticism.) Basically, they wanted a textbook that was more textbook-y and less over the top.

I’ve refrained from assigning the Gang of Four design patterns book in the past. Not because I don’t like it—on the contrary, it’s a fabulous reference book, and I do use it often in my own work. I don’t assign it because the usage examples are rather sparse and there isn’t a lot of code in the text. I just wasn’t convinced that it would work in my class. But, since the criticism was so strong last time around, I decided to give it a go this time around and see if I had better success.

The verdict? This text hasn’t worked well at all for this group of students. As I suspected, the students are having a lot of trouble figuring out when or why to use each pattern. The lack of examples and lack of code is negatively affecting their comprehension. (And the few examples in the Gang of Four? My students don’t find them convincing.) I’m having to do a lot more PR work in class to get them on board with the concept of design patterns. I’ve spent almost all my class time in this part of the course lecturing (lots and lots of lecturing, which I typically try to avoid) and walking through examples, when normally I’d set up an example, walk through part of it, and leave the rest to my students to develop, so that they get some much-needed practice with the patterns.

Next time I teach this course (which, sadly, won’t be for at least 2 years), I will go back to the Head First book. I do think some of the criticisms from last year’s students are valid, but if anything this term’s experience has underscored just how important good, extensive code examples are in learning a difficult concept or set of concepts. This experience has also helped solidify in my mind why I choose to use this book, and I’ll be able to make a stronger case for it with the next batch of students.

Now, if I could just find a Data Structures textbook that I don’t absolutely abhor….