TITLE: Why Don't More CS Professors Use the Results of CS Education Research? AUTHOR: Eugene Wallingford DATE: November 19, 2018 3:35 PM DESC: ----- BODY: Over the last few days, there has been an interesting Twitter thread on the challenges of getting CS instructors to adopt the results of CS education research. Actually, it started as a thread and grew into a tree... Here's a reasonable jumping-in spot if you'd like to explore. I imagine that it's hard to get research results into the classroom in a lot of disciplines. Research can be abstract and is usually out of context for any given school. But even when research groups implement curricula and train teachers, it can be hard to spread practices that we know work well. The answer educators give for not adopting research results often boils down to, "It's complicated." Schools are different; students are different; the end goals are different. Indeed, the original Twitter thread spawned a student diversity conversation that picked up when the energy of the original topic waned. This tweet is a nice anchor for that conversation:
Majors vs. non-majors. Undergrads vs. high school vs. elementary school. Adult software developers vs end-user programmers vs conversational programmers. Different goals: authenticity, security, software engineering, algorithmic thinking, practice production. No one way.
All of these distinctions are real. I've seen several of them affect how we teach introductory programming at my school. And let's be honest: when we talk about research in CS education, we are often talking almost exclusively about teaching programming. How we teach intro programming can, though, have a big effect on student performance in later courses. But even in the face of these different dimensions, I still wonder why more of us don't incorporate more research results into our teaching. I have a few ideas borne out of my years as a faculty member. I think a big part of the effect that students have on whether faculty adopt new pedagogical approaches comes an angle not mentioned in that list: competitive pressure. Departments fear that if they adopt an unusual curriculum or an unusual first language, they will lose students. These fears manifest themselves if you propose to teach a relatively ordinary language such as Ada; they grow quickly if your approach uses an esoteric parentheses language (EPL). Parents of HS students will say, "Your competitors don't use EPL or your unusual pedagogical approach. They teach Good Old-Fashioned CS, the way it's always been, a way that's proven to get graduates jobs. Why shouldn't we send our daughters and sons to another school?" HS students and their parents do ask questions such as these, and it takes a lot of perseverance to respond over and over. Only the most committed believers can stay the course. Unfortnately, it can take a few years for the benefits of a new approach to show up in upper division courses, let alone in the performance of graduates. New curricula rarely have that much time to succeed. If the department's faculty aren't all fully committed to an approach, then as soon as enrollments dip a bit, they join the chorus. There's a scapegoat ready at hand. Even if we step back from the competitive disadvantage angle, we can see a similar phenomenon at play. The tweet quoted above list many different kinds of learners. These distinctions can serve as a handy reason for faculty not to change when faced with CS ed research that may only apply to one student population or one context. And resistance to change is a strong force. Speaking as a long-time professor, I think the most powerful forces against change arise not on the student side of the equation but on the teachers'. Learning a bunch of new techniques, integrating them into a coherent curriculum, and then mastering them is hard. It takes time profs don't always have a lot of. When they do have some time, reading and applying CS ed research pulls them away from their own research or even away from the things they like to do in the classroom. Personal confession time. This all reminds me of a conversation I had with Mike Clancy many years ago. He was part of the team that developed the idea of using case studies to teach programming. I've always admired the approach and thought the intro textbook he and Marcia Linn built around it was pretty cool. When I told Mike this, he asked, "Well then, why aren't you using them? Why aren't you writing case studies of your own?" These were great questions that took me aback. My answers sound like the excuses I've talked about in this post... My colleagues were skeptical of the approach and preferred other textbooks; convincing them to change would require a lot of work and political capital. Writing case studies is hard work, and at the time I was more excited to work on my own somewhat-related ideas. "Soon", I said. But soon never came. I sit here still admiring case studies -- and worked examples, and Parsons problems, and the design recipe, and How to Design Programs. I've incorporated the idea of design recipes into my Programming Languages course, but I haven't fully committed to it yet. The others? They are still dreams. (I did try my first Parsons problem this semester: an assembly language program in my compilers course. I liked the result and think I'll try more next semester when I teach my students functional programming in Racket.) Am I slow to adopt evidence-backed pedagogy? Lazy? Short on time? I don't know, but I suspect that there are many reasons. Change is hard. I do hope that I haven't done my students too much disservice in the meantime. At one point in the Twitter conversation that launched this post, someone wrote something to the effect, "convincing researchers is easier than convincing practitioners". But that brings to mind another question: Why aren't all CS ed researchers advocating the use of worked examples? Design recipe and HTDP-style curricula? Parsons problems? Why aren't more CS ed researchers using them in their own classrooms? Maybe they are and I haven't been paying attention. If that's so, then I doubt that many other CS profs know about this widespread adoption of advances among CS ed researchers either. Some disciplines, such as physics, seem to have developed more of a culture for incorporating education research into the classroom than computer science. Can we change that? If so, I think there is room for the CS ed research community to lead the way. But... it's complicated. -----