I know this post will bear an eerie similarity to the last one, but once again I am going to take a stab at writing a useful blog. Not sure if it will be useful to anyone else, but at least I will try to make it useful for me. My school and I have reached a tentative understanding that I will be returning to a full-time teaching load, including math, and so it seems an appropriate time to begin a more reflective chapter of my career.
So that I might be more inclined to post, this blog will start with one post per week on Fridays. As those of you who know me can attest, I tend to be a fairly rules-based guy, so I am going to try to set up a template for my blog posts, with a few key sections:
- This Week Today — with apologies to John Oliver, this will be a retrospective of the week, with my key observations on what I did in my classes.
- The Good, The Bad, and The Ugly — a section outlining one thing that worked really well, one thing that didn’t work so well, and one thing that was truly awful.
- Thoughts on Teaching — a short piece attempting to extract from my brain any useful nuggets concerning computer science, math, and/or teaching.
- What I’ve Been Reading — links to the blog posts and articles that I have read in the past week that seemed to strike a chord in my teaching practice.
- Whimsy with Wistar — something off-topic that amuses me and hopefully amuses you as well. If you don’t like it, well de gustibus non est disputandum.
That’s probably too ambitious and may prove a barrier to entry, but here goes nothing.
I’m a big fan of standards-based grading. In fact, since I switched to it midway through the first semester of last year, I can’t imagine going back. Escaping the shackles of a point-grubbing culture and refocusing my assessment on standards performance has really changed the way I teach — for the better, I hope.
But the implementation is still a work in progress. This year I decided to switch from a 1-10 scale to Marzano’s 1-4 scale, as detailed in his book. I even went to the trouble of creating a differentiated rubric that listed Level-2 skills and Level-3 skills. It was a lot of work and I’m not sure that it improved things very much.
The problem is Level-4. One of the reasons why I wanted to move away from points-based grading was to reduce grade inflation in my class. I wanted to make it really hard to get a top score. But the problem I encountered was, especially with take-home programming assignments, it was too easy for students to produce “perfect” work that satisfied all the requirements of an assignment.
Does a working program equal a 4.0? I don’t think that it should. In my mind, students need to go above and beyond the basic expectations to earn a 4.0. But it’s a bit like that old paradox: once you define what constitutes a 4.0, then that becomes the new literal benchmark that students will strive for. Marzano says that a 3.0 is “proficient”, so shouldn’t a 4.0 require students to exceed expectations.
Last semester I tried requiring my students to write me a narrative argument for why their work should earn a 4.0 if they felt they had exceeded the basic requirements of the assignment. That didn’t really work, because their explanations were really just facile restatements of the 3.0 proficiency standards.
Maybe my standards just need to be reworked so that I establish a new top tier. I can’t really figure out how to do that, but maybe other people in CS who are using SBG can help me with that. In the meantime, I am using a new rubric in my AP-level class:
|Concept can be implemented on paper.|
|Concept can be implemented with no logical errors|
|Concept can be implemented with no runtime errors|
|Concept can be implemented with no syntax errors|
In other words, to get a 4.0 you need to be able to do this stuff correctly on a test. I think this sort of fragmented rubric would get an angry letter from Mr. Marzano. But it’s the best way I can think now to reduce the “soft bump” that students get from doing their work at home with the benefit of compilers and other resources.
What do you think?
I was just reading an excellent post by Ben Wildeboer on his blog about what to do on Day One, and it made me reflect on the evolution of this curious pedagogical organism in my classes over the years. In the beginning, when I was teaching at NMH, I used to do a very traditional first-day lesson plan: pass out the course description, pass out the schedule, answer any questions, and have a nice day. (Yeah, I really used to suck as a teacher.) The only odd thing is that I used to have my students make little name tents for themselves out of manila folders that they would put on their desks for the first few days until I learned all their names. This probably wasn’t necessary, but it did provide a neat opportunity for nostalgia as I amassed an ever-growing stack of manila folder name tents.
Here at Hotchkiss, I don’t do handouts on the first day, and I don’t need the name tents. Part of the reason for both these facts is that CS enrollment here, as with many of our peer schools, is dreadfully low. (One of our neighboring schools won’t be teaching any computer science again this year because the math teacher who covered those classes left school.) Most of my classes usually begin with 2-4 students, and then I hold my breath to see how they will grow during the drop/add period. Usually I am the beneficiary of some schedule conflicts, which doesn’t bother me at all. Whatever puts warm bodies in my classroom is fine with me.
Anyway, a lot of the activities that are floating around the Web work really well with 15-20 students, but seem a bit comical with only two or three. (“Get in groups — oh, wait.”) So I made a decision a few years ago that I would reschedule Day One into Day Two. We do all that boring handout stuff on the second day of classes. Instead, on the first day, we just roll up our sleeves and get to work. After a very brief introduction, I throw my students into programming, or web design, or whatever the first unit is about. I figure, the best way to hook them is to show them what they have in store. And it certainly gets the momentum going as soon as possible.
Only one week between posts — that’s still not really what I’m aiming for, but a week is better than a month. It occurred to me the other day that even if I can’t write about what I’m working on, I could write some responses to some of the other blog posts I’ve read, which should give me enough material to write until the cows come home. I’m also adding a to-do item to spend 1 hour in professional development every other day, so that should encourage more output as well.
I was reading a great post by Frank Noschese about the value of iteration in learning and in teaching, and it really resonated with a lot of the work that I have done in teaching computer science. In particular, he talks about how many learners have difficulty trying more than one strategy, but ultimately the successful ones are willing to experiment and make mistakes.
For me as a teacher, it seems like getting students to be comfortable making mistakes is one of the biggest hurdles to overcome with new programmers. By the time that kids get to high school, they have been hard-wired to think that the worst thing to do is be wrong, and the most dangerous thing to do is to try. If I had a nickel for every time a student pointed at the computer screen and asked me, “Will this work?” — well, at least I’d have a lot of nickels.
Usually my response is simply, “Did you try it?” When I walk away without giving them the security blanket of a teacher blessing, sometimes they freak out. I try to tell them, calmly, “You don’t need me to tell you if your program works. Try running it to see what happens. You won’t blow up the computer.” Usually, they chuckle and give it a try. Still, I can see the miasma of resentment and, more importantly, fear behind their eyes sometimes. What do you mean, try it? Why won’t you help me? What if I made a mistake?
In some sense, you could really look at just this phenomenon and use it as a predictor of ultimate success in programming. People who are willing to experiment, to explore, and to really screw things up make good programmers. Those who are scared to color outside the lines don’t. It really doesn’t matter as much how well they can store the Java API in their head — they can compensate for shortcomings in knowledge way more easily than they can compensate for shortcomings in attitude.
As I usually tell my students early in the semester, programming is a contact sport — the more time you have in contact with the keyboard, the better you’ll get. But really, isn’t that true with just about every discipline?
Overall, I would have to say that today was less insightful and awe-inspiring than yesterday, but there were still some useful nuggets.
Early AM: Expo surfing
I decided to skip the keynote featuring Stephen Covey via pre-recorded video because it didn’t seem like it would be that useful and I figured I could watch the video at my leisure some other time. In the past, ISTE has had some really great speakers, like Malcolm Gladwell and James Surowiecki. This didn’t seem like it would be up to that level, and judging from the comments I heard afterwards, it wasn’t. Instead, I went back to the vendor expo to try to cover some more territory. With only an hour, I was only able to cover about another quarter of the hall. But I did talk to Texas Instruments long enough to determine that they still don’t have a curriculum in place about teaching programming on the nSpire, and talked to the guy at Digipen for long enough to make me wonder what my life would have been like if it had existed 20 years ago.
Session 1: SIGIS Meeting
I’ve attended every annual meeting of SIGIS (the SIG for independent schools) since it formed in 2008 in San Antonio (which, coincidentally, was my first ISTE conference). The group is still in its infancy, and the agenda reflected that. We spent the first half of the meeting just doing meet and greets, and then most of the rest of the meeting hearing a report about what the group had done in the past year since the last conference. I hope that as the group gains momentum, we will turn over more of the time at these meetings to discussion and business. I hope, I hope. No notes to speak of to post here.
My SIGIS meeting was so exciting that I decided to skip the SIGCT meeting and have an excellent lunch with two of my colleagues, @auntfun and @kricekrice. I daresay we spent at least as much time talking about computer teaching at lunch as they did at the meeting.
Session 2: Computational Thinking for Everyone
My original choice, a session on getting faculty to use new technology, got unexpectedly full and closed up on me, so I had to scramble. I decided to fall back on my second choice, a session about computational thinking. Last year I attended another session at ISTE about the same topic, and came away feeling about as befuddled as I was this time. I will probably reserve another whole blog post to talk just about computational thinking, but the short version of my opinion is: they’re not ready. In fairness, I think they realize that. But the CT people still have not really articulated what distinguishes it from the other habits of mind that are already well-established. If their path to mainstream acceptance continues to use the mantra “This is what you’re already doing”, then this movement is will wind up stillborn. Again, no really useful notes to post.
Session 3: Lessons Learned From the Front Lines of 1-1
I called an audible for the last session, since neither of the items I had originally placed in my schedule seemed as interesting as they had in April. I decided to go to another session about 1-1 computing. To be honest, now that I saw the people there, I wonder if I attended the same panel last year. In any case, the ideas seemed fresh to me. And I had a new perspective now after going through the first year of our 1-1 program. I also got the chance to meet the executive director of the Anywhere Anytime Learning Foundation, so that’s a good thing. Most of the panelists’ comments seemed pretty much like common sense, but they had some good answers to my question, which was about how you can increase faculty buy-in to a 1-1 program that is already being implemented. I had a thought that next year we should make 1-1 computing one of the major themes of our faculty technology expo. Here are my notes: Lessons learned from the frontlines of 1-1.pdf
Tomorrow, there will be another few (hopefully) exciting sessions, and then it’s back home to Connecticut!
I’m redesigning my applications course this summer for a few reasons: (a) after eight years of teaching the same suite, things are feeling pretty stale; and (b) I never really enjoyed teaching it that much in the first place. Instead, I’ve decided to replace it with a new course named “Digital Citizenship”. Here’s the description that I posted in the course catalog:
CO335 Digital Citizenship
This course teaches students how to express themselves effectively and responsibly on the Internet using a variety of current computer-based technologies. Topics covered include blogs, audio and video podcasts, social networking, wikis, microblogging, cloud computing, and web design. In addition to creating content using these tools, students will also study how they are currently being used and their effects on our society.
Currently the course is scheduled for the first semester, which is 12 weeks. I’ve just started fleshing out the basic structure for the semester, but here is my plan thus far:
|Week 3||Social networks|
|Week 4||Cloud computing|
|Week 7||Audio podcasts|
|Week 8||Audio podcasts|
|Week 9||Video podcasts|
|Week 10||Video podcasts|
|Week 11||Final project|
|Week 12||Final project|
Amazingly, this blog actually generated comments off of the first two posts, and I am going to try to satisfy the thirst of its ever-widening audience. (OK, stop laughing — I was being ironical.)
Anyway, two people actually asked to see copies of the standards documents that I created for my computer science courses, so I am happy to oblige. First, a few caveats are in order:
- This was my first attempt at SBG, and I created these lists on my own without consulting with any pre-existing literature in place. Anything strange you see here is just the product of my deranged mind.
- In the case of my CO451 course, I actually began SBG halfway through the course, so that document is necessarily incomplete. I hope this summer to revise all these documents, and I will definitely add standards for the first half of that course.
- Some of the standards are duplicated. This was a necessary evil that came with using ActiveGrade. The program is awesome, but it doesn’t let you call back to standards from a previous marking period in any graceful way. I needed to copy and paste them if I wanted to reuse them in the second half of a semester.
Having said all that, here you go. Just FYI, the courses lay out as follows: CO355 (Introduction to Programming) is a one-semester course offered each semester for students with no experience. It uses Alice at the core. CO451 (Programming in Java) and CO552 (AP Computer Science A) are a paired set of semester courses that covers the AP syllabus in a year.