battis.net and I'm all out of bubble gum…

I’m in the throes of reworking my Introduction to Computer Science course for the coming fall. I was thoroughly dissatisfied with how I taught the course this year: I’m at the stage of teaching where I know how I want it to go, but can’t always make it happen. Of course, this may not be a stage, but could, depressingly, be the existence of a grown-up.

I have divided the course into three broad areas that I think are most important to cover: computer science (as a discipline: concepts like variable scope, Boolean logic, object-oriented design, and so on), programming in Java (concrete details like how a for loop works or how to declare a class) and design and implementation. Design and implementation is actually really the core of my fascination with this course: how do you teach problem solving? And how do you get students to apply those skills.

In doing this, I’m plowing through a lot of articles.

  • Jason Tselentis does a great job of identifying the challenge (with a special focus on graphic design problem solving and software, to be honest), although what he’s really talking about has more to do with my general challenge in academic computing: developing able and fearless tinkerers.
  • Anthony Cowling goes into much deeper, and more software specific, detail, pushing the idea not just of scaffolded design education, but helping students learn to assess the quality of design (subscription).
  • Phillip Greenspun tackles not just the problems of teaching problem solving and design, but discusses MIT course 6.916, on developing web applications with an eye towards developing broadly competent and self-reliant alumni. Again, his basic ethos flows directly into my primary concern in any approach to academic computing: are we teaching a shamanistic approach to computers (“follow these specific steps in this order and it works.”) or are we supporting the development of true independent learners who can sit down and “just figure it out.” Greenspun and I are in the same camp, supporting the latter option.
  • Gary Pollice wrote a great article describing his introductory software engineering class — which touches not just on design, but on teamwork. Again, he’s preaching somewhat to the choir as I read about his students working on semester-long courses with real clients.

Of course, the challenge is now to boil down all these design concepts into something that is useful not in a first-year computer science or software engineering undergraduate course, but in a first-semester high school course. How much do my students really need to know about UML, CRC cards, flow charts, eXtreme Programming, incremental development, rapid prototyping, functional requirements and use cases? Not a whole damn lot. Mostly, I want them to learn to enjoy the process of rigorous problem solving as manifest in learning to program a computer.

But I’d certainly like them to not be starting down the garden path of bad habits based on ill-considered pedagogical frameworks.

Ah, for the days of Pascal as a first programming language!

June 26th, 2008

Posted In: Computer Science, Educational Technology

Tags: , , , , ,

css.php