It’s a little dangerous writing about a class that I’m currently teaching, but this has been weighing on me and writing is usually cathartic. What I want to talk about is some of the challenges and frustrations I’ve encountered with my Topics in AI course, and both how I have reacted to it, as well as some remaining uncertainties. As background the course is called Topics in Artificial Intelligence, is is being offered in the cognitive science department. It is listed by the registrar as requiring either “CogSci 101” or “CompSci 201”, in quotes because that’s not the real course numbers but are representative of the department and the level.
I think the fundamental problem that I have faced is one of different expectations between my and my students, not only on the material that will be covered in the course, but also the way in which skills and abilities needed to succeed. There are many reasons for this, but I think the biggest one is simply the change in context for me: going from the computer science department of a large research university to the cognitive science department of a small liberal arts college. I simply didn’t understand the students’ interests and motivations, and in doing so had integrated assumptions into the design of my course that, in retrospect, was counter to what I wanted to achieve.
Before I go any further, I want to emphasize that I’m not blaming anyone for this. Part of me wants to even excuse myself, and suggest that perhaps I couldn’t have understood it even if I had tried, since there is no way to communicate what I now know to who I was even a month ago. But I would be damned if I didn’t try, and for other people out there who are going into departments other than their original, I hope that something can be learned from this.
Let me start with what I had planned. A lot of this was written into previous posts, but I think I need to make explicit the assumptions I made in those posts. For one, my planning revolved around students being interested in AI as a subject, and while it’s connections to cognitive science are also worth knowing, it was secondary to understanding what computers are doing when we make them smart. As a result, my syllabus is organized such that students first learn the big idea of a technique, then some details of how it works, before going back out to applications and the challenges that face the researchers and consumers.
This assumption is about as far from the truth as I can get. The majority of students in the class come from a cognitive science background, and am much more interested in how artificial intelligence can shed light on human cognition than they are in how computers can be smart in general. This means that my sequence of presentation is backwards – I should have started with the computational aspects of human cognition, then presented their AI counterparts, then address how they are inadequate. By starting with the algorithm – even when I explained how people solve the same general problem every day – I inadvertently alienated students who came in seeking the connection to things they learned in their cognitive science courses.
I think there’s a more general lesson here regarding teaching your home subject in a course from a different department, which faculty in a new department would likely face. The question is: to what extent should the course focus on your home subject as opposed to the subject of the hosting department? This is not just a question about balancing the amount of content in each, but also how topics should be introduced (as suggested above), the depth to which they should be studied, and whether what you want students to learn is the same as what the students actually want to learn. It’s all too easy to bring in preconceptions from your home subject, and do it in a way that you are not even aware the students could see things differently. I am not even talking about the “AI for AI’s sake” thing here, but things like what you expect prerequisites to cover.
Which brings me to the next point: it is really, really hard to know what students are and are not capable of. One lesson here for me is that even talking to other faculty may mot give an accurate picture of student’s skills. One reason for this is that other faculty may have a different competence scale regarding your subject – by definition, since you are starting a new department, the student skills levels are necessarily based on students who do not have extensive experience in your subject. But the other reason that assessment of students from other faculty may not help is that they may have in mind a particular way of teaching, one that they know students will find approachable. So while they understand how having students of a particular level translates to differences in the classroom, you as the new faculty do not. This difference in common ground is obvious in retrospect, but I wish I had realized it sooner.
There is one more challenge that I have yet figure out how to meet, and that’s how to take advantage of students who do have a technical background, without simultaneously confusing students who don’t have it. In principle it should be as simple as “if you know about X, then this is like…”, but somehow that felt insufficient. I did try it, but it almost felt it had a negative effect. I worry that the resulting explanation didn’t make sense to those students, and that it has led to them doubting their own ability. It’s likely that this is an unfounded fear, and that as long as I make sure that even students who don’t know X can get the concept, it doesn’t matter what students knew before.
So what have I done in response to these challenges?
The biggest change I have made is to almost entirely change the assignments. My original syllabus was heavily focused on implementation of algorithms – that is, on programming. I was lucky to find out, three hours before my first class, that only about a third of the class has programming experience. I admit I panicked, but ultimately figured out how I could get the same ideas across with a minimal amount of programming experience. I ended using IPython as the platform on which students can run code, and be able to do small-scale explorations of algorithms by only changing the numbers. Luckily, I designed the course to be driven by applications, it was sufficient to have students specify how to represent a problem for the algorithm, and the likely difficulties that someone doing so would encounter.
On a larger scale, I am reconsidering the order in which I present present material. Because the course consists of four mostly-unrelated topics, the lessons I learn from the first topic can be applied for the remaining topics without much difficulty. Within the first topic, I am also moving the discussion of application earlier, and will use that to as the backdrop for the discussion on challenges. I do think the course is better for it, and I hope that it’s not too little too late.
Finally, I am also addressing the expectations of students. My original syllabus and the belatedness of the realizations I’m having now meant that I went with the algorithmic details for the first two lectures. The technicalities are hard for students, and I’ve been trying to make sure students know it’s okay to only get the gist of the readings (and to have them cleared up in class), as well as how much I want them to come to office hours. I did emphasize these things during the first class as well, but I don’t think I sufficiently conveyed how challenging they might find the material.
I will write another post in a couple of weeks on how this turns out.