Posts tagged pedagogy
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!
Having just struck upon the similarities between Pink’s six new senses and Gardner’s multiple intelligences, I continue to be fascinated by examples of folks employing these ideas in creative ways: enter Basildon Coder, recently highlighted on Slashdot for describing a Wodehouse-ian approach to code refactoring. As always, I look at this and start to ponder how to use it in the classroom with my students: one of the real challenges that my students face is not the development of new code (although that is challenging) but figuring out how to use a body of code written by someone else (me, their classmates, some godawful Windows GDI API, etc.). I have been struck by the difficulty my students have faced this year in grasping the 50,000 foot view of coding — perhaps a visual representation like this might be a first step. Sort of a Powers of 10 for programming.
A rather substantial constellation of coincidental events over the past week has gotten me thinking about how we approach project-based learning: a course-planning conversation with the genial mad scientist whose classroom I share, happening to reflect on my experiences in graduate school last year as I walked past the Kennedy School of Government (not my alma mater), pondering a spring of senioritis, and trying to figure out which of many projects I most wanted to tackle myself over this break, ranging from budgeting curriculum development grants to grading to just plain building code.
Right now I’m starting to overhaul my computer science courses for the 2008-2009 school year, while simultaneously talking with my colleague about a potential joint course in 2009-2010. I have a strong personal preference for project-based learning as a teaching tool because I believe that it provides both an engaging and demanding environment in which students are challenged to learn more in order to do more (rather than just to keep me off of their backs). I also think that projects are an ideal forum in which to draw together the disparate strands of a student’s education — helping them to accomplish an integration for which there is rarely, if ever a formal structure at any level of education. (Perhaps the course on How to Make Almost Anything at MIT is the exception.)
Some of this is based on my experience working with summer programs where we pushed students — during their vacations, in the wilderness — to take on an ambitious personal project over the course of the summer. The outcomes of these projects reflected a great deal of real learning, as well as some very idiosyncratic fascinations. I worked with students who were mapping and analyzing the population of our program over the past three-quarters of a century, students who were focused on writing collections of place-based poetry and short fiction, students who were determined to build a new tool that the expeditions could use in years to come. Anything and everything. But the key was that, by and large, students were genuinely excited about these self-designed projects and put in far longer hours and more effort to complete these projects than they would with normal schoolwork (as I know based on some conversation with their school faculties). Engagement and the discovery of an intellectual passion are no trivial accomplishment for an adolescent summer.
Two summers ago, the faculty reading for my school was Thomas Friedman’s The World is Flat, a book which raises some interesting questions about the direction of education and economics (I suggest skimming liberally through the early chapters… I think it got interesting around page 600 or so). In large part, Friedman’s argument (which is not novel to the educational world) is that those who are able to integrate knowledge and create and construct new ideas based on that integration will have the whip hand in the world of tomorrow (a phrase normally uttered only in echo chambers).
Where in our schools do we offer those opportunities, practice or guidance for our students to integrate the knowledge that they have learned in each discipline. Certainly our instinctual tendency is often to “silo” that education, each discipline focusing exclusively on its own branch of learning, without substantial interaction with other disciplines, or alternatively engaging with other disciplines only as subservient tools of our own, intrinsically more important, discipline. (God knows I’m guilty of this: I’ll look at anything, so long as I get to write some code to work with it down the road.)
As we each start to move towards a project-based curriculum, rich with alternative assessments and challenges to individual student’s passions and interests… we’re going to burn the little puppies right out. This realization came to me as I walked past the Kennedy School, where I took a superlative accounting course last spring — the only course in which I did not have a final project. None of my final projects connected with any other final project, and several were in areas in which I had but marginal interest. This is not something unique to me: all of our students take classes in which they are only marginally interested, in order to fulfill requirements (yes, I’m starting to think about course selection advising as well!).
If every class is so well-designed that it uses the breadth of our pedagogical knowledge and the entire scope of our educational best practices, no student will be able to take a breath long enough to even start to integrate what it is that he or she is learning through this process. How much more powerful would it be for us to guide our students towards a grand, culminating project that required them to draw on multiple disciplines, integrating their knowledge and uniting their teachers as a team in support of this creative work?
Perhaps this is an overly idealistic rendering of the scene, but as I discussed curriculum planning and projects with my mad scientist friend, it became rapidly apparent that the most interesting projects were those that would require more than just one of us (and often more than just one or two of our friends and colleagues) to accomplish. This will require a culture shift at my school. But it will accomplish three major feats, if done well:
- Engagement. These projects will be truly fascinating, whether it’s developing a process for fermenting ethanol, building a room-mapping robot or carving giant toltec figures in the landscape.
- Authentic Challenges. These projects are clearly not artificial: students working on real problems (often with real professionals) are challenged to learn real things. With careful design, they might even learn the real things that we want them to learn!
- Integration. These projects will drive faculty to role model and guide students through making connections between distinct educational disciplines in new and creative ways, in order to accomplish the overall goal.
So why is there a picture of my cat on a table up above? Because I’m struggling with all of this at once and finding it fairly overwhelming. If you click through and look at the list of texts, you will either wonder if I’m trying to build SkyNet by myself, or if I have technology-induced ADD. I suspect the latter. But my hope is that out of this chaos, I will be able to start to bring first order, and then some new ideas for the coming year. And then maybe I can look at training the cat to stay off the table.
When I was in college, one of my friends posted a letter-sized sheet of paper labeled “the angry list” by the exit from her common room. She/we had plenty of legitimate things to be grumpy about (boyfriend, professors, the iniquities of life — normal college stuff) and this was a way to vent relatively quietly. Another friend, to balance the karmic scales of their common room, posted a list of things that made her happy on another letter-sized sheet of paper.
Over the course of the year, the angry list was filled, removed and replaced with some regularity. And the happy list was filled, expanded and grew and grew. By the end of the year it covered the entire wall and, if I recall correctly, there wasn’t really room for the angry list anywhere — a project that had been abandoned months earlier, in any account. Some of us would walk down the hill to their common room just to post something else on the happy list. And there were repeat appearances of some things (food and relationships figured largely, although there was a fair amount of nerdiness at large on the list as well).
I’ve been thinking about the happy list over the past couple of weeks. It’s January (soon to be February), the absolute nadir of the school year. A couple weeks ago we started our schedule review process with an expert who presented data that bore out what we all already knew instinctively: student (and faculty) enthusiasm and performance dip noticeably here in the midyear (she had some slick ideas for ameliorating that, of course). There’s lots to wear on us, everything from exams (not nearly as fun to write or grade as they are to take, I assure you) to budgeting for the coming year to curriculum review to end of semester course evaluations and fretting about students and advisees.
A friend poked her head in my office a while back and said, “I’m broken.” After a quick conversation, mostly to clarify what kind of broken she meant, not that she was referring to a mental rather than physical sensation, it was clear that both of us were feeling the strains of the season. Since then I’ve spent a lot of time thinking about, well, the angry list. The things that didn’t go well in the past semester. The plans that failed. The work that didn’t pay off. The people with whom I disagree. The projects deferred and delayed. The gratification denied. Generally, the stuff of the angry list.
Which brought me to the happy list again. Which is one of those things to hang on to (like thank you letters from students and their families) in the “rainy day” file. I am feeling especially resolved to have fun in the coming semester, and I’ve been thinking about the things that make me happy in the classroom and in my work. And I’m going to try to do more of them, and to avoid the things that don’t (a list I decline to make public — but that I’m sure you can imagine).
- Student-designed projects (especially ambitious ones that succeed)
- Learning with my students (I like teaching them stuff I know too, but this is really fun!)
- Meetings for a purpose, rather than out of habit (both with my colleagues and with my students)
- Providing feedback and guidance for next steps (rather than a grade and an ending)
- Making things that seem hard possible (especially if I can help someone else do the real heavy lifting)
- Sharing ideas that are exciting to me with my colleagues and students
- Sharing ideas that are exciting to my colleagues and students (with me)
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.
Having just driven my sister to the Philadelphia airport, I am reminded of the value of education founded in general principles, rather than a rote memorization of steps to accomplish specific goals.
I grew up in Philadephia and I have no idea where I am or how to get there on most of my trips. This is doubly true when driving to the airport. I simply know a route (in the case of the airport, for many years all I knew was that if I got in a particular lane on the expressway, I would eventually end up at the airport). I don’t know the geography. If I had to leave my route for a detour (as I did a year or two ago), I would have no idea how to recover.
Compare this to my knowledge of Somerville, where I lived for nine months and drove far less than when I was in Philadelphia (and yes, the walking knowledge is part of my point). Somerville was the the third city in four years that I had lived in, and I had developed a different approach to learning the lay of the land than my approach to Philadelphia. I got lost. I got lost a lot. I printed out directions to every place I wanted to go, but when I thought I saw a shortcut or knew my way, I took it. Sometimes this went badly. But I rapidly developed a much better sense not just for routes, but for the entire geography of the city (I can’t speak to Boston, but this worked in Cambridge as well). I had taken enough wrong turns that I had a sense of how the streets were connected (even if I didn’t always know the names).
I started working in IT when I was in high school, supporting my school’s AppleTalk network and doing odd consulting gigs along the way. In the consulting, I had several regular clients who hired me to help them learn how to use their computers. These regular clients took copious notes as I explained to them how to perform various tasks on their computers (use a word processor, print, save a file). Those folks who noted down that the menubar was where actions (or, in one English teacher’s case, verbs) were stored, that each window represented a file on the hard drive, and so forth, were rarely heard from again: they had grasped the general principles of the situation. The ones who titled their notes “How to Save a MacWrite File” and then took step-by-step notes… those were job security. Not only did they tend to lose their notes (notes more akin to a treasure map than to knowledge), but they were unable to generalize from those notes to other related concepts like “How to Save a MacPaint File” or “How to Save an AppleWorks Spreadsheet” (and they weren’t entirely certain that a file and a spreadsheet were the same thing).
Why do I mention this? The takers of step-by-step notes, maps to the hidden treasure of the Save command were learning how to use their computers by rote memorization, with no real understanding of what they were doing or how discrete parts of the process they had learned could be applied to other, similar situations. They were driving to the Philadelphia airport.
When confronted with an alien technology (or landscape or process or culture), our natural inclination is to find out how to do the few specific things that we need to do (order food, print a paper, hail a taxi, etc.). If we learn those tasks in isolation, without learning the underlying and fundamental principles that define how that technology or landscape work, we continue to operate in alien terrain. It’s quicker and easier, initially, to have our cheat sheet than to probe the situation and figure out how the dang thing works.
The temptation when teaching students (or faculty) how to use technology is to provide the step-by-step directions, neatly illustrated with screenshots, describing how to perform X, Y or Z task that needs to be done for the assignment. I have certainly been guilty of this myself, even as recently as this fall (I tried to have the best of both worlds, describing the steps, but also what the steps were doing… but I have little confidence that anyone read those longer explanations under the time pressure of September and the start of classes). These cheat sheets prevent us and our students from learning how to use the system.
Earlier this fall, a fellow teacher described his approach to teaching his students how to use different web sites. He doesn’t. He gives them the URL of the main site, tells them what to look for, and gives them an evening to poke at it to figure out how to get the information they need out of it. They might collaborate and share their learning. They might intuit how the system works. They might not get it that first night and have to seek help from their peers. But they don’t have trouble with the second assignment: they have learned how the site works on that first evening.
This seems like an argument for teaching by not teaching. Rather, it is an argument for teaching by coaching, by presenting challenges to our students for which we have adequately prepared them and allowing our students to strive and succeed. The role of the teacher is not to be the master of all knowledge, but the sage adviser capable of guiding students to the knowledge. In practice, this is not easier but rather much harder than traditional teaching: it’s easy to tell someone else how to do something, to explain what you know so that they might understand it. It is much harder to create a situation in which genuine learning can take place, to not interfere while that learning is going on, and to help facilitate and process that learning during and afterwards.
This is the challenge for teachers of technology.
Rather than teaching our students how to use a specific technology to perform a specific task, we need to present our students with appropriate tools and background to learn to use those tools. Academic computing is often relegated to computer applications classes, where students learn skills devoid of context, or to specific projects where a student “learns PowerPoint.” Instead, we need to think more broadly: what are the academic computing skills that we wish for our students to have? How can we challenge our students to develop those skills? How will we know when they have attained this knowledge?
Do we want our students to learn to use Word and PowerPoint? Well, not really: I don’t care what programs they learn to use. Let’s rephrase the question: Do we want our students to learn how to develop and write about their ideas and present those ideas in a clear and compelling manner? Hell yes. We have several tools available to facilitate this, including Word and PowerPoint. But these are just tools. Offering a class in computer applications is like offering a class on pencils: everyone involved will want to gouge out their eyeballs by the second hour. These tools have to be learned as just that: tools, part of a process larger than themselves.
The great fear of teachers who are asked to use fancy pants technological tools in their classes is that they will need to know more about these tools than their students. I ask instead that teachers know more about the skills that they wish their students to acquire, and be willing to coach students towards honing those skills while using technology, rather than teach students to use specific tools.
Certainly a teacher can’t ask a student to use a tool with which they themselves have no familiarity. But if this is a tool that is supposed to help a student achieve and exhibit the desired skills, and the teacher is him or herself a master of those skills… shouldn’t it be incumbent upon the teacher to either a) be familiar with the tool or b) reevaluate whether or not the tool is itself useful to the skill? (I’m eating my own dog food on this one: I’m writing this blog!)
This fall I have worked with a number of teachers who want to learn specific tools to enhance their own teaching. This is how these tools will end up being taught, not because we have a mandate that all of our graduates should master the Microsoft Office suite. In much the same way that a history teacher who doesn’t use outlines for his or her own analyses is going to be less well-equiped to teach his or her students to use outlines, a teacher who doesn’t use technology is going to be ill-equiped to teach their students. (And, by corollary, leaders in schools should also be using technology to support their work with faculty — same reasoning: if it’s really a useful tool, we should be using it!)
All of this brings us back to the key point however: we don’t really learn until we have had to get ourselves unlost. And, as teachers, we need to be willing to let our students get lost. Not terribly, Robinson Crusoe, Moses-in-the-desert, talking-to-our-volleyball lost, but lost on the way from Someville to Cambridge. Define a bite-sized goal for our students and ask them to chew it on their own: ask them to learn to use a technology on their own. Give them a introduction, point them to the areas they will need to explore, and let them explore!