5 things I learned this term

1. Carleton students will put the work in, even for low-stakes stuff.
   As part of my flipped classroom experiment this term, my Intro class had daily assignments based on the readings. Sometimes these were short programs, other times they were pen-and-paper algorithm development exercises. These were worth 5 points each and account for 10% of the course grade, and as long as they handed in something related to the assignment, they got full credit. This was my way of getting them in the habit of daily practice with the skills in a low-stakes manner. I was not sure if the students would “mail it in” just to get the points. What I actually found was that the students spent as much time and energy working on these assignments as they did the larger projects. In fact, I had to go into class at one point and remind them to put an upper limit on the time spent on the exercises, after hearing about one particular assignment that the students spent hours on! (Oops.) Carleton students continue to impress me—they are fully dedicated to their learning, and that makes my job much easier for sure.
2. I am incapable of “quick-grading” anything, even low-stakes stuff.
   My intent with the daily exercises was that I’d spot-check them, giving a little bit of feedback where necessary, so as to minimize my grading load. In reality, I found myself giving extensive feedback at times, and spending more time grading these than I expected. As I fully expect to do the flipped classroom (or some variation) for my fall courses, I need to think more carefully about managing the grading load.
3. Never underestimate the power of 25 minutes in getting things done.
   This was supposed to me my “light term”, but it certainly didn’t feel like that! Between research demands, teaching demands, and the demands of some new and significant service projects, I was swamped and often overwhelmed. (Add in 2 kiddos that kept getting sick, and the subsequent Sick Kid Shuffles required to deal with that.) I found little tricks like the pomodoro method (set a 25 minute timer) and #madwriting helped keep me on track and on task during my busiest/most overwhelming days. In fact, 2 short bouts of #madwriting in a single day led me to finish drafts of 2 sections of a particularly problematic conference paper. I’m a convert!
4. Managing my email reduces both my workload and my stress level.
   Checking my email less frequently this term (twice a day during the day, once total on weekends) and limiting the times I respond to email had 2 interesting effects. One, it was amazing how many problems solved themselves if I didn’t respond immediately. And two, my stress level went way down, because I didn’t feel obligated to respond to things immediately.
5. Carleton students, for the most part, do well with autonomy.
   Ultimately, with my flipped classroom, I made the students responsible for learning more of the details of concepts and programming (the different variations of for loops, the many ways one can structure an if-else clause, etc) on their own through the readings and exercises. Class time was for larger projects and problem-solving exercises, where we applied the material. I left it up to them to try out the examples on their own. I did not cover everything in class that would be on the quiz. And—lo and behold, they took responsibility for their learning, and ran with it. I joke that the less I talk, the more my students learn. More seriously, my job really is to provide the framework and the roadmap for my students’ learning, and to design the experiences that will help them master the material. (Ditto for my independent study—I gave my student a lot of control over projects and readings, and in our last meeting of the term she mentioned how much she appreciated this and how this strengthened her learning of the material.)

Advertisement

You can’t go home again

Next week I’ll be in Chicago for the NCWIT summit*. Carleton’s an Academic Alliance member so I’ll be representing us there. I always look forward to the summit—this is my third one—but I’m especially excited about this one because Chicago is my grad school home.

I’ve been back to Chicago a number of times since I graduated, but I’ve never made it back to campus. My advisor left right before I finished, so that’s one big tie back to campus that’s not there anymore. But I still do have a number of ties there, and so this year I decided that I’d make the time to go back and visit my home of 5 1/2 years.

I’ve spent a good part of this week setting up meetings and letting people know I’ll be on campus. It’s awesome (and a bit weird) how many people remember me. Especially since it’s been…let’s say, a number of years…since I graduated. Of course I’m eager to discuss research with like-minded people, so I dutifully did some poking around on the various labs’ and groups’ sites.

In the process of poking around, I learned two things that really shouldn’t shock me anymore, but still did:

1. I have zero research interests in common with my old lab. Zero.
2. My research interests are much more aligned with the CS faculty than the ECE faculty.

Now, you are probably thinking “well, DUH! You are a computer scientist, after all!”  And yes, you’re absolutely right. I’ve identified as a computer scientist for at least 9 years now, and probably longer since the switch to CS really happened during my post-doc days. But part of me still identifies more as an electrical engineer. That was my undergrad identity. That was my grad school identity. That’s what I thought I was going to be when I grew up. Identities are hard to shake, apparently, even if they don’t quite fit anymore.

The thing is, shaking that identity, and taking some risks to do so, opened up a world of possibilities that wouldn’t have existed had I stayed the course. My postdoc, my current position, and all the research opportunities of the past…bunch of…years, none of that would be possible if I hadn’t decided to assume a new identity as a computer scientist. And of course, it was my time at my grad school alma mater that put me in the position in the first place to make that identity switch—where I gained the confidence in myself, and constructed a support group, and worked on the right research projects, to allow me to ultimately explore and eventually assume the computer scientist identity.

So I’ll visit my old lab and my thesis committee and reminisce a bit about my engineer-self. And I’ll make some new acquaintances as my computer scientist-self. And I’ll feel equally comfortable in both worlds, even if I can’t exactly talk research with my old lab anymore.

* If you are a reader of this blog and will be at the NCWIT summit next week, please introduce yourself and say hi!

 

The (research) definition of insanity?

This morning I had a deeply satisfying research session. I sketched out plans for a new testbed (related to the grant application I’m working on currently). I defined “roles” for each system within the testbed. I identified the main research questions, and even set next steps. I was feeling good.

One of the “next steps” involves solving a rather tricky problem…one that sounded familiar. On a hunch, I went back into my research notebooks….and found notes on the same tricky problem, from at least three different occasions, dating back to the spring of 2010. A tricky problem that, obviously, still remains unsolved, despite my best efforts.

The famous quote by Albert Einstein states that “insanity is doing the same thing over and over again and expecting different results.” Clearly solving this problem is necessary to moving this particular line of research forward. Clearly I’ve not been able to jump this hurdle in the past. Does this mean I’m foolish for trying again?

On the surface, yes, I am crazy for repeating my past failures. But on the other hand, each one of my previous attempts taught me something about the problem, something which I applied the next time to the problem. And each previous attempt also taught me that I was not quite ready to solve the problem—I didn’t have enough information, didn’t know enough about how the system I’m designing and developing behaves. In the interim, while I was off solving other problems and tinkering with the system, I gained (or so I’d like to believe) valuable insights and knowledge that should get me closer to the solution.

And then there’s that little thing about how my biggest breakthroughs tend to happen when I revisit old failures…and finally see that little nugget I failed to notice before, the key to solving the problem.

So as usual, I’ll plunge ahead in my normal insane way, trust my instincts, and hope that the fourth time’s the charm.

Image credit: http://www.rudecactus.com/