The Pain/Gain Scale
One of our former PhD students is now on the faculty at Swarthmore and he suggested to me the pain/gain scale as a way to determine if the degree of difficulty in assignments was perceived to be worth it. This seemed like a fine idea, so I polled students on the two major assignments completed so far, asking them to rate on a scale of 1-5 the amount of pain the assignment caused and the amount of gain they derived. The results are fascinating.
Here is the histogram of the responses:
At first I thought that Assignment 3 was really nice correlated, but
then I calculated the ratio for each student and graphed that -- it
tells a different story:
While most people found the ratio about 1:1, there were some who clearly suffered and others who had a blast. I have not done further analysis, correlating these ratings with how well groups did, but I found it interesting nonetheless.
The Partially Flipped Class
The astute reader will have noticed that while upholding my deal that I will not make students prepare for class while they are also implementing processes, building a VM system, or making a file system recoverable, it's been difficult to maintain the energy and enthusiasm of the flipped classroom. As I entered the homestretch, I decided to try an experiment with what I am calling the partially flipped classroom. I take my lecture notes and I break them into two parts -- a short intro (6-8 slides) and the rest (10-20 slides on technical content). I present the intro and then I dispatch the class for 15-20 minutes deriving from first principles some of the challenging aspects of the particular topic and approaches for addressing those aspects. For example, on Tuesday I was teaching virtualization. Now that they had built major pieces of an operating system and become intimate with other parts of the OS, I let them figure out what the big problems were in building a virtual machine-based environment. The groups each came up with excellent lists, which we then pooled. When this was all done, we'd covered much of the material in the rest of the slide deck. So, I was able to breeze through the rest of the deck relatively quickly and I knew that they had a much more complete picture of the topics, because they had largely derived them themselves. It felt very good. I repeated the process on Thursday with security. I introduce the three A's of security: Authentication, Authorization, and Access Control and then let them play around with identifying what can go wrong if you fail to address each aspect properly and then proposing approaches to solving it. This week, we'll be able to breeze through my slides on the topic relatively quickly, because most of the ideas came up in discussion. That will leave us time to talk about a few real world exploits.I think this is the approach I want to try for all the material that I had been teaching "the old way." I'm pretty sure that with some careful thought I can make it work and we may be able to maintain a higher level of energy and engagement during the roughest parts of the semester. We shall see!
The Flipped Exam
Thanks to the wonders of Facebook and my friend Jill Levien, I was introduced to the idea of a Flipped Exam. Now, I don't teach game theory and I'm not entirely sure how this would work for my class, but I found it intriguing, so I posted it to our class discussion board with the directions "Read/Discuss." And my fabulous students engaged!Student1: We should have such a final exam: the entire class: write as much as possible of an operating system in 24 hours together. editdelete Student2: While I do think there is a place for individual examinations, the current educational system overvalues such tests. My basic understanding of the "real world" is that most projects of any real significance are done in teams, be it research, commercial products, etc. Sure, there have been cases of lone wolfs that create paradigm shifts or fantastic projects (and this should be encouraged as well!), but teamwork is ultimately a skill that should be encouraged, not subdued. (24 hours might be a bit short to get much functionality done on an OS even with a full class of people, but I certainly wouldn't mind a collaborative written final). Student3: Synchronizing >40 people would be so much fun... Student4: I really like that idea. It will be a fun, collaborative experience, and we'll end up synthesizing the entire semester together into one glorious product. Student5: This idea was the first thing I thought about as well. I think it would be fun, maybe not necessarily writing a whole new operating system, but writing another subsystem for OS/161. TF1: Rob Bowden: Networking!! Student5: Indeed that would be fun. Student6: so punny Student7: You get a synchro bug! And you get a synchro bug! Everybody gets a synchro bug! Student8: I find this much more reflective of how the world actually works and I think it reminds people that the best answer is 99% of the time not produced in solitude. I'll second Student2's final suggestion as well. Student9: If it's a coding assignment, maybe we'd need (want) groups of a smaller size. 45 people can't all be coding at the same time, so it seems as if the exercise would likely devolve into "Okay, you two/three/four code, we'll just watch...and write a DesDoc? And, uh, run tests!" What about five partitions of nine, sorted day-of? You've got 24 hours to do what you can on [subsystem], working with some, all, or none of your tablemates. Coordinate sleep, food, and synchronize your watches...here's an assignment spec, go!Right now I think I'm still going with the individual exam, but I'll definitely have to think about the concept of collaborative exams for the future. I am glad the class (or at least a subset of it) thinks that working together would be fun.
No comments:
Post a Comment