It is perhaps fitting to write a blog about teaching programming while I sit here and monitor my students as they write the final exam. I did my other exam yesterday (same class, another lecture section) so the grading is very fresh in my mind.
For the last few years I have been teaching one of the first three courses in our major, and all of these involve programming. I tend these days to make my exams open book, open notes, open anything-printed, but closed to anything electronic. I don’t know how long the closed electronic can survive, but I don’t know another way to keep the students from getting too much help from outside. I do not mind if they print off piles of paper, but I also try to warn them that they need to have indexed all their material. I have seen too many students frantically searching through a thousand pages of stuff looking for the one relevant paragraph. Given the level of detail, I don’t mind that they would have written down good versions of code, provided they know what that code does… (I am thinking here of the question that asks for code to link a node into a linked list, and the thee students yesterday who wrote out the code to unlink a node … what were they thinking?).
By making all my exams open notes, I can’t ask some of the simple questions like definitions. But I can ask them to become good librarians and good at finding the references to the material. If they can properly index and organize the details, they have probably learned the material. And perhaps through sheer repetition, they might come to understand the precise way in which things are said and written. In general, their writing is fuzzy, which I think is because their thinking is fuzzy. But this isn’t a discipline where fuzzy thinking is a good idea.
For various reasons, I have been reading a lot of books of late “about” software and about how computing is changing the world. Dreaming in Code, by Scott Rosenberg; Distrust That Particular Flavor, by William Gibson; Programmed Visions, by Wendy Chun. I have also been working with faculty from across campus on digital humanities projects. We live in this strange world in which really great ideas all come down to the issue of SMOP (a Small Matter of Programming). There is a huge amount of work in getting a big software artifact written and tested. There can be major issues in dealing with APIs. All that cool stuff is available for programming iPhones, for example, but it is necessary to understand the classes and methods and how they interrelate. The big issue for me, after a long time teaching, is how to balance the need for “skill” in programming with the need for knowing how to think about putting the small pieces of code together. We still drill students in arithmetic and spelling, probably on the basis that they need to be facile with the basic skills in order to deal with higher concepts. Programming is much the same, except the skills are harder to learn and the higher concepts much harder to understand when they are fuzzy. We can read a bad essay and know that it is bad. It is harder to look at bad code, or to run bad code, and know why we don’t like what we see.
Duncan Buell
CSTA University Representative