A new CSC 151

CSC 151, Functional Problem Solving, is Grinnell’s introductory course in computer science. It’s a course that of which I am quite fond, and which I teach regularly. What’s special about the course? Many things.

We teach the course in what we have variously called collaborative laboratory style, workshop style, pair programming, and flipped classroom [1]. Students do a short reading in advance of each class. During class, they work in pairs on a series of problems we’ve designed, while the faculty member and class mentors peer of shoulders asking questions and making suggestions [2]. We’ve tried a variety of mechanisms for pairing students; these days, we randomly pair students approximately every-other class period. We also talk explicitly about why we use this model [3] and how pair programming should work [5]. Since most students learn more by doing than by listening, this model helps them develop a stronger understanding of the material. We hear that it also helps build community in the department.

We use Scheme [6] as the language in the course. I’m pretty sure I’ve written about the reasons before, but it never hurts to restate them. We chose Scheme because it has a relatively simple syntax [7], because the core language is small enough that a student could master all of it, and because it provides an excellent platform for learning important techniques like recursion and higher-order programming. We continue to use it because we’ve found that students learn well in an interpreted environment [8] and, as importantly, because it appears to level the playing field a bit. In introductory CS, there is always the concern that students with some programming background will intimidate those who lack programming background. Because most students who have learned to program are accustomed to manipulating state and have not used higher-order approaches, they often find themselves as challenged as the new students.

We also theme the introductory course. Rather than having students work on a set of disconnected problems, we try to make the course focus on a primary problem domain. For the past decade, that domain has been image making and manipulation [9]. We adopted that domain because evidence from the literature suggested that it was particularly successful at retaining women in the discipline. We’ve found many other benefits, particularly that students can see many of their errors. We shouldn’t have been surprised. Papert wrote about the same issue decades ago.

At the time we developed the media computation version of the course, the department had assumed that it would create multiple versions of the introductory course, with a variety of topical foci. However, the media computing course proved successful enough, and the burden of writing readings and laboratories for 50-or-so class periods provided burdensome enough, that the department did not develop alternatives. Still, our intuition that themes are helpful was a good one; Maria Klawe has noted that many CS departments that have successfully diversified their population of majors use themes. It seems that it may matter as much that you have a theme as what the theme is.

After more than twenty years of workshop-style teaching, about twenty years of Scheme, and ten years of media computation, it’s time for a change.

It’s not so much the time that has elapsed that leads to the intent to change. Rather, a variety of factors have come together. First, the faculty made changes to the course timetable a few years ago. That change has made it difficult to offer classes in our traditional form of four fifty-minute sessions per week. Second, we are finding that the platform we developed for media computing in Scheme feels increasingly fragile. Third, while the evidence is good that media computation helps departments retain women students, the evidence that it helps us recruit and retain students from other underrepresented groups is less good. Finally, as we consider issues of accessibility, a course model that focuses on images and requires a particular platform [10] needs updating.

Don’t worry! We’ll still teach the course using workshop-style pedagogy and we will continue to use Scheme [11]. What we are changing is the topic of the course and the offering model. Rather than meeting in four fifty-minute blocks per week, the course will meet in three eighty-minute blocks per week [12].

What about the topic? As part of the College’s current Data Science Initiative, we will make aspects of data science a focus of the course, particularly techniques for harvesting and cleaning data. An advantage of teaching data science in the introductory course is that after using tools to do data science in the beginning of the semester, by the end of the semester students will be able to build the tools themselves. To continue the department’s efforts to encourage diversity in the discipline, we hope to explore issues of computing for social good, a topic that has shown particular value at attracting students from a variety of groups traditionally underrepresented in computer science.

This undertaking is large. In addition to developing an overall structure for the class and writing approximately forty daily readings and forty corresponding laboratories, we will need to build appropriate libraries and identify useful data sets and projects [14]. Because accessibility is an important focus both at the College and in the department, we will also consider accessibility issues in the design of the course, including accessibility of the programming environments we ask students to use.

Other than that big picture view, what will the new course look like? I have no idea. We may move to the WeScheme online editor because it uses WAI-ARIA to provide additional support for visually impaired users. We will keep a project toward the end of the semester. We will teach recursion and higher-order programming. Beyond that, I’m not sure. But that’s what the summer is for.

[1] Okay, we’ve never really called it a flipped classroom. But the flipped classroom methodology is quite similar to what we use.

[2] We play a much more active role than in a typical constructivist classroom. Experience suggests that it works well.

[3] Computer scientists [4] often work in pairs. More importantly, almost no matter what you do, you will end up doing some of your work with others. It’s useful to get experience working with a wide variety of people early on in your career.

[4] Well, software builders.

[5] We rely on a rough driver/navigator model and have students read about and discuss the model early in the semester.

[6] Or Racket.

[7] The syntax is simple once you get used to all the parentheses as well as the Polish notation.

[8] We use DrRacket.

[9] We sometimes refer to that as media computation.

[10] Linux.

[11] Okay, maybe you worry that we will continue to use Scheme. Deal.

[12] Yes, that’s a nice gain in time. For my classes, it may be even more, since I tend to ramble a bit at the start of each class, and now I’ll only ramble three days per week rather than four.

[14] I forgot to mention. Students speak highly about the a program is worth a thousand pictures project that serves as the capstone of the current version of the course. We therefore plan to identify a project of similar scope and complexity.

Version 1.0 of 2017-06-05.