Posts tagged Computer Science
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!
No one. That’s who. Well, not as many of us as we might have thought. Since the real power of “thinking like a computer scientist” is leveraging abstraction as a means of managing and containing complexity, it makes sense that we are moving away from an era in which every computer scientist needs to have a soup-to-nuts understanding of computers. No single human being can full comprehend an entire computer system, and it’s not clear that we should be training computer scientists with this as a goal.
But this does raise some questions about how our students will handle the abstraction of concepts that they don’t fully (need) to understand.
“God, grant me the serenity to accept the things I cannot change; the courage to change the things I can; and the wisdom to know the difference.”
– Reinhold Niebuhr
I gather that Alcoholics Anonymous has appropriated this prayer. I think I’ll follow their lead. Preparing for exams is always a whirlwind, and it turns out that helping ninth graders prepare for their first cumulative exams of their lives is particularly tornado-esque.
Along the way, our faculty — before the end of the first semester — finds itself already looking ahead to the coming academic year. And I find myself trying to figure out how to write a course description of a computer science course that will appeal to girls without scaring away boys and vice versa. Or, really, appeal to a high school student while simultaneously communicating gravitas to that student’s parents, adviser and college counselor. Oh, and me. Perhaps especially me: I have to teach the courses in the end.
And I find it oddly difficult to be fully serious while writing these course descriptions. Oddly and dangerously unserious. It could be exciting.
My first year teaching, a bright young thing just out of college, I spent the summer before-hand in a state of panic: I assumed that, having gotten a job teaching AP Computer Science, that I would now need to be an infallible expert in computer science. This level of pressure had me practically hyperventilating before my first class.
Fortunately, what gradually became apparent to me (and has been reenforced often since, even as recently as my most recent evaluation this fall) is that the value in my teaching (and, I presume, all teaching) is not in what I can explain to the students, but what I can help them explain to me. And things get really exciting when my students get to explain things to me that are new to me. In fact, the most freeing moment I have had in the classroom was the first time I said, “Gee, that’s a good question. I have no idea. Let’s figure it out.” The practice of working as a collaborative team to solve a shared problem is real, and it is true learning.
Previously, I alluded to the idea of being willing to get lost in the hinterlands on the way to our educational destination. In this scenario, the teacher serves as the knowledgeable and resourceful guide. My best service to my students is to help them prepare for that journey, to load them with the background knowledge they need to tackle real and challenging problems. In this, the question of how and what to communicate to my students arises. I don’t want to tell them too much, for fear that they will come to rely on me, rather than their own intellect, for answers. But I certainly don’t want to tell them too little, for fear that they will never emerge from the hinterland.
This fall, as my computer science class can attest, we have swung both ways, but I think we’re finding a happy medium. As we reach equilibrium in that state of my life, I am turning my attention more directly to the other part of my life, working with faculty on uses and goals for academic computing. And I find myself in a similar bind. What and how should I be communicating? In a previous incarnation of this position, at another school, I believe I said too much and limited the creativity and actual learning of my colleagues. At the same time, I cannot rely on my colleagues now, who are working the so-called “triple threat” while striving to consistently improve their own teaching, to just “figure things out” on their own.
I think that this is exactly the situation for which we must prepare our students: we want our students to be able to lead, but to be able to collaborate with their colleagues to achieve the best possible results. How then, do we prepare our students to do this? And can we use these same tools ourselves to accomplish these same goals for ourselves (surely we should be as good at this as we would like our students to be, and if we’re not… now is an excellent time to get better!)
I believe the first step is to actually consider the nature of the communication that we are doing and to try to use appropriate tools for the problems at hand. Traditionally we are used to face-to-face meetings (which occur in real and simultaneous time for all participants, in a single location), mail (snail or electronic, it amounts to an asynchronous discussion occurring in multiple locations), or some telephonic communication (simultaneous real-time discussions occuring in two different locations). These same basic limitations apply to our communication with even the latest technology (are we in the same location or different locations? Can we talk at the same time or different times? Will this conversation take place all at once or over the course of several communications?)
But we have new tools that let us make better use of both our synchronous and asynchronous time. Consider the process of developing a joint document (a proposal for a new course to be taught by a team of teachers, for example). With our triple-threat schedule, we may only be able to find one quick time for a face-to-face meeting, but we can use wikis and other shared document tools (e.g. Google Docs) to share a single, evolving draft of our writing. Technologies are coming into play to allow us to do the same for video and audio editting.
Similarly, if we want to work the kinks out of a new idea, we would normally try for a face-to-face meeting (with a whiteboard, of course). But what if we blogged the idea, and then the discussion takes place in the comment threads? The same conversation can now take place asynchronously. Or perhaps we want to thread several discussion topics together, as in a discussion board, allowing for more free-wheeling discourse. Or we would like to link together connected ideas in different threads with hyperlink references.
What this describes is a new paradigm for communication. Processes which are traditionally thought of as happening synchronously and face-to-face can now be done asynchronously and at a distance. And this is what we need to be preparing our students to do. And the tools that we can use as teachers to work together in an increasingly pressured educational environment to squeeze the greatest result out of our efforts.
This does not supplant our traditional communication approaches, which still have great strengths (tone, inflection and body language, anyone) but complements them, allowing us to collaborate in a broader array of challenging situations to get more done with greater coordination of effort and less coordination of schedule.