TITLE: Express Yourself AUTHOR: Eugene Wallingford DATE: September 15, 2012 10:04 AM DESC: ----- BODY: One of my CS colleagues gives only multiple-choice and true/false tests. He swears by how well scores on them track with performance on programming assignments, which he views as a valuable form of consistency. And, boy, are they easy to grade. I'm not a fan. I can't recall the last I time used them. If I ever did, it was surely for a narrow purpose, say, to test quickly the student's familiarity with vocabulary. "Choose one" questions are too limiting to be used wholesale, because they test only recognition, not recall. They certainly can't test the synthetic skills we need as programmers and solvers of problems, and those are the most important part of computer science. My course this semester has brought this idea to the forefront of my mind again. I've helped students a lot on their first two programming assignments, as they learn a little Java and revisit the concept of modularity they learned in their Data Structures course. I've been struck by how often they cannot talk about their code. When I ask "What is this statement doing?" or "Why are you <x>?", many struggle. They want to answer in terms of the code they have written, either reading it back to me in English or telling me the code that surrounds it. This is true for almost any value of <x>. This week, "assigning a value to this variable" and "using an if statement" were common topics. Most of these students had a reason that they wrote the code they did, even if it was merely a reaction to a specific behavior they observed in the compiler or executable. But even in the best cases the idea is usually not clear in their minds. Unclear ideas are nebulous and rambling. This is why the students have so much trouble trying to express them at all, let alone concisely. Perhaps it's not surprising that students at this level struggle with this problem. Most are coming directly out of their first-year courses, where they learned a single programming language and used it to build data structures and small programs. They are often able to solve the tasks we set before them in these courses without having to understand their own programs at a deep level. The tasks are relatively simple, and the programs are small enough that bits of code cobbled together from examples they've seen get the job done. It takes practice to learn how to think at a higher level, to express ideas about solutions and code without speaking in terms of code, or even the solutions they have settled on. To learn learn such skills, students need practice. The professor needs to ask open-ended questions in class and out. Asking good questions outside of class is especially important because it's in the hallway, the lab, and office hours where students find themselves one on one with the professor and have to answer the questions themselves. They can't fall back on the relative anonymity of even a small class to avoid the hard work of forming a thought and trying to say it out loud. They also need practice in the form of homework questions, quizzes, and even tests. Each of these exacts an increasing level of accountability, which creates an increasing sense of urgency for their efforts. One of my favorite experiences as a teacher is when students visit after a course is over and tells me the pride they felt while taking the final exam and finally -- finally! -- feeling like they could express the thoughts they had in their minds. That's a proud moment for the teacher, too. The first four weeks of this course reminds me that one of the essential goals for the intermediate computing course is to strengthen the skills needed to reason about ideas and express them clearly. When students make the move to a second programming language and a second programming style, they have to come to grips with the fact that programming is not just about Python or Ada anymore. In fact, it never was. -----