This summer, I have the opportunity to work with Larry Snyder from University of Washington’s Computer Science and Engineering department on his pilot of the CS Principles course.  I’m thrilled to be part of the process: I’ve expressed skepticism in the idea of a first course in computing without much programming and I’m scared of a reduction in rigor — what better way to address these areas of concern than to be part of the effort to shape the course?

Larry has been working actively on introductory courses since 1997 or so and has written a textbook on fluency with information technology, a concept defined and solidified by a committee which he chaired.  That work has defined what “the average American” should know in order to effectively leverage the growing availability and sophistication of software and hardware products.  The group advocated teaching IT fluency in three areas: skills (how to use a particular product), concepts (underlying ideas that won’t change as, for example, new versions of software come out) and intellectual capabilities (problem solving).

Now we’re tackling a related but not entirely equivalent question: what should “the average American” know about computer science?  In my mind, that’s a trickier question since computer science is a relatively poorly defined field.  Certainly, IT products generally come out of computer science, so there’s a lot of overlap, but it doesn’t feel right to define computer science in terms of its products.  What unites those working on structural problems in graph theory to those working on accessible technology?  I still haven’t found an entirely compelling answer and some would argue that they don’t belong in the same discipline/department.  It’s frustrating to think that I can’t eloquently describe my own field but I have this vague sense that computer science is about process rather than product.  This suggests that a useful way to think of the CS Principles course in contrast with IT fluency might be that it will include an increased emphasis on “intellectual capabilities” built on top of the “concepts” part without much “skills.”

Another interesting aspect of this course is that its goals are potentially numerous and conflicting.  I think it’s pretty straight-forward to define the goals for a programming course — students exiting the course should recognize problems appropriate to solve computationally, should be able to formulate basic algorithms, and should have some syntactic fluency in the language of choice.  There’s some healthy debate to have on how to reach those goals, but I think most people would agree with the basic skeleton.  Furthermore, defending those goals is pretty straightforward.  By formally expressing algorithms, students develop their problem solving skills in a systematic and measurable way.  Programming is fundamentally a creative endeavor and that is a useful and satisfying experience for students to have.  And so on.

What about a breadth course like this Principles one?  What should a student exiting the course know/understand/be able to do?  So far, the course committee has shared lots of high-level notions of what the course should convey through its 7 Big Ideas (reminiscent of Peter Denning’s 7 Great Principles), a set of general practices and a philosophical rationale for the course.  This does not yet imply any specific set of skills and understandings that a student would have exiting the course.  That’s what the pilots are for.

For the UW pilot, to be offered this coming winter, Larry and I are trying to be disciplined about using a form of backward design to try to avoid an aimless romp through “cool stuff” related to computer science.  We are trying to come up with “unit-level” goals that describe the general concept a student should come away with, breaking those down into small skill, knowledge or understanding based goals and writing corresponding sample assessment questions so that we can then work to create the most appropriate learning activities.  I don’t know whether we’ll have the discipline to stick to this process for the development of the entire course but it has certainly helped me focus my thinking and give me hope that we can weave a coherent story.

It’s interesting to ponder whether specific outcomes and connectivity between topics matter all that much.  My sense is that if this were just a college course with the goal of getting freshmen excited about taking a programming course and considering computer science, it might be ok for it to just throw as much “cool” stuff as possible in students’ direction.  I think that for it to be successful as a high school class, though, it will need to be much more clearly based on specific outcomes.  Without those, districts will be reluctant to adopt it (where are the standards it covers?), teachers will be difficult to train (should I use Alice?  Python?  How do I decide?) and students will see it as an ‘easy AP’ to pad their schedule.

To imagined or veritable readers: How would you go about developing such a course?  What are a couple of specific things you believe students marching out of the classroom on the last day should be able to do/explain/use?