Archive for the ‘programming’ Category

Fri 1/6: Wrestling with SBG

January 6, 2012 4 comments

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?



Categories: CO552, compsci, programming, sbar

Tue 8/16: The value of iteration

August 17, 2011 Leave a comment

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?

Categories: compsci, programming, teaching