This posting continues the discussion of a non-majors course in computing, started in the March 2015 issue of ACM Inroads and the subsequent comments by Mark Guzdial.
In particular, this posting provides perspectives of Michael Goldweber and Henry M. Walker, authors of articles in the ACM Inroads issue, that respond to Mark’s blog.
Response by Michael Goldweber
In a recent CACM blog post, Mark Guzdial commented on the March issue of ACM Inroads special section on the role of programming in a non-majors CS course. In particular, he wrote somewhat critically regarding two of the articles; one authored by me and one by Henry Walker.
His comments centered around two issues:
- the lack of evidence-based pedagogy in these two papers, and
- the process whereby the content of such courses is decided upon.
I offer the following in the spirit of continuing this dialog.
Regarding point #1, I agree 100% with Dr. Guzdial, neither my article nor Henry’s article contains any evidence-based pedagogy. In fact neither article contains any discussion of pedagogy at all—evidence-based, folk, or otherwise. So while I agree with Dr. Guzdial’s comments regarding the absence of evidence-based pedagogy, they are nonetheless not germane.
As for point #2, Dr. Guzdial argues against CS faculty unilaterally deciding the content of such non-majors courses. He asks (rhetorically?) “Are CS faculty the right ones to define the learning goals for students who do not plan on a career in computer science?”
I suppose by this argument philosophy faculty members do not have the right to define the learning goals for students taking a philosophy elective, who do not plan on a career in philosophy. It appears that Dr. Guzdial has never taken part in a liberal arts or Jesuit/Catholic (or other religion-based) institution’s core curriculum war—errr, I mean discussion.
Non-major courses do not exist in isolation; they fit into the wider focus or nature of an institution such as a technical school, liberal arts college, or research university. Dr. Guzdial’s institution is a technical school where everyone is required to take a course in computing. Again, I agree with Dr. Guzdial, it is inappropriate for CS faculty to design the learning goals for a service course in isolation. The design of any service course should carefully consider the needs of the “client” department(s). If a client department requires programming, then programming must be included. Notwithstanding, my comments and Henry’s were not meant to inform the design of any course that is required by any department/program.
When Henry and I first began planning this special section, we recognized the wide variety of institutional foci and goals. Hence, we invited a set of authors who would speak to the breadth of this space as best we could, given the constraints of the medium. The goal was to present a plethora of perspectives on this question.
So, while I agree with Dr. Guzdial’s point regarding the process of designing a service course, it is nonetheless not germane. The design of a non-major’s course in computing, which is not a service course for some other department/program, should belong in the hands of the CS faculty. Students electing to explore a discipline take these courses. Surely, discipline experts are those who can best decide what to present from the discipline.
Dr. Guzdial’s comments aside, the purpose of the special section was not to discuss pedagogy or to focus on the process of topic selection. The point was to explore the question of whether programming should be one of the included topics.
There is no question that including programming is the traditional route for non-major courses; perhaps, one might say, the way white male faculty have been electing to do it for many years. My and Henry’s articles (yes, we are both white males, as is Dr. Guzdial) dare to explore what a non-major’s course might look like without including the traditional programming component.
Humbly yours,
Michael Goldweber
Professor of Computer Science, Xavier University
SIGCAS Chair
Response by Henry M. Walker
The purpose of the Special Section was to engage computing educators about the appropriate content for non-majors courses in computing, and I am delighted with the conversations this Special Section has generated.
From my perspective, initial course planning starts with content, goals, and context. After identifying appropriate material to be addressed, pedagogy considers how that material might be organized and taught effectively. Evidence-based pedagogy provides a fine mechanism to move from high-level themes to “the integration of professional wisdom with the best available empirical evidence in making decisions about how to deliver instruction” [US Department of Education, quoted in Mark Guzdial’s blog]. However, the focus of the Special Section was on the Big ideas, not on pedagogy. Once one knows what material to cover, the references in Mark’s blog to evidence-based practice may provide faculty with guidance on how to organize, plan, and conduct a course — but all of that comes after initial planning.
Returning to a consideration of initial planning, some comments seem appropriate regarding, content, goals, and context. In the language of CS Principles, what are the Big Ideas that a course should explore? As indicated in Mark’s blog, the CS Principles effort has identified seven fine Big Ideas that might be considered for a non-majors course join computing. My article, “Priorities for the non-majors, CS course”, suggests directions for identifying numerous other Big Ideas as well. My intention was not to present final statements of Big Ideas, but rather suggest additional themes and directions that might be considered. I doubted a long laundry list of possible themes would help faculty consider what makes sense for their courses and institutions; rather the point was to consider additional directions.
Mark’s blog also mentions some courses that have a programming component. For example, I have followed the development of the courses at both Kalamazoo College and Georgia Tech for years, and I certainly agree that those courses do a fine job in what they attempt to do. Similarly, the CS Principles course is well thought out. However, at least one of the Big Ideas in each of these courses is related to programming. For example, one of the the CS Principles’s Big Ideas states, “Students in this course design and produce solutions, models, and artifacts … .” If this is a starting point, then further development of a course using programming seems natural. In summary, if programming is a goal of the course, then the course should cover programming.
However, my article and the article by Michael Goldweber dare to suggest that the collection of Big Ideas need not include programming. Although we approach the non-majors course from different perspectives, we both identify a range of topics that might be considered — programming-related topics are just one of numerous candidates.
Turning to course goals, the purposes of a course need to take into account the target audience. A non-majors course for engineering students may need to address specific skills useful for engineering, a non-majors course for accountants may need to consider elements of spreadsheets or databases, a non-majors course for artists or historians or language majors may need to address other needs. More generally, if a non-majors computing course is being designed to address the needs of a client department, then the goals and Big Ideas may need to reflect some of those needs. Computer scientists naturally will have insights about what material should be covered, but the course is only useful if it connects with the target audience and their needs as well. As a separate matter, a general non-majors course may need to touch upon a range of student interests and have a hybrid target audience.
Context represents yet another factor shaping a course. Courses do not exist in isolation, and students do not take only one course in their undergradaute programs. Thus, in planning a course, one should connect themes and Big Ideas to broader goals of an overall curriculum, and these will necessarily vary according to each institution. What are the various institutional learning goals and how do they fit with departmental goals? Needs for a course naturally reflect the nature of the institution (e.g., technical school versus a liberal arts college), the role of the course (e.g., course for both majors and non-majors versus a course specifically for non-majors), and the role the course might play in students’ overall education.
Putting these pieces together, my article and the article by Michael Goldweber identify numerous possibilities for course themes and Big Ideas. With such a range of topics to choose from, it is curious that Mark’s blog states, “The claim that “significant other topics must be dropped” is an empirical claim.” If a course could cover any range of topics, then there would be no need for CS2013 to recommend about 300 hours of class time for a major in computer science. Further, the CS2013 Task Force would not have been faced with the challenge of how to shape their recommendations to fit within a realistic undergraduate program. With the range of themes and Big Ideas suggested in my article, choices are needed as well.
In summary, initial planning for a non-majors course in computing requires consideration of content, goals, and context. The articles in the Special Section identify a large number of possible themes and Big Ideas — far more than can be covered in a single course, and this requires faculty to make choices. Mark’s blog rightly identifies some successful courses in which faculty have chosen to include programming-related themes, and I have no objection to that. (To correct Mark’s blog, my article does not “argue[s] that programming should not be a priority for a non-CS majors course, as claimed in the blog. Rather I argue that programming need not be a priority.)
The point of my article is other legitimate choices are possible as well. One size does not fit all, and there is no reason to believe that one selection of themes or Big Ideas will fit all courses in all institutions.
Of course, once the themes and Big Ideas are identified, then one can move on to the pedagogy — perhaps using evidence-based practice, as Mark’s blog suggests. However, the starting point is identifying the themes and Big Ideas, not pedagogy.
Henry M. Walker
Professor of Computer Science
Samuel R. and Marie-Louise Rosenthal Professor of Natural Science and Mathematics
Grinnell College
Concluding Note
In keeping with the purpose of the Special Section to generate discussion, both Michael and Henry encourage additional thoughtful perspectives to be added to this ACM Inroads blog.
Big Ideas Can Overshadow Important “Small” Ideas
Michael Goldweber writes: “[M]y embarrassment-free non-majors course will contain units on both complexity as well as unsolvability. … One might argue that an educated population that understands the limits of what can be accomplished with computation is more important than an educated population that has spent a semester wresting with a compiler or creating games in Scratch.”
While I share his view that computability and complexity are fundamental concepts that should be studied, I believe that focusing on them is highly misleading as to what actually goes on in computer science. You can teach students that SAT is NP-complete, however, they will miss out on the more important information that SAT solving has become one of the most successful problem-solving methods in computing! SAT solvers implement very clever algorithms (with scary names like “conflict-directed clause learning with nonchronological backtracking”) and data structures (“watched literals”) that make the NP-completeness of SAT irrelevant in practice. The field is so rich that the “Handbook of Satisfiability” is almost a thousand pages long.
It may not be practical to teach modern SAT solving to non-majors, but I don’t think that a teaching an esoteric theoretical result in isolation is critically important for an educated population. Suppose that a software engineer comes to her boss who learned (only) about NP-completeness and proposed to use a SAT solver in the company’s core business. The boss would chase her out of his office for suggesting such nonsense. It is just conceivable that if the boss had spent a semester “wrestling with a compiler,” he might be more receptive to the idea that sophisticated software systems have immense potential for solving problems.