Teaching Philosophy
My teaching philosophy is based on an APPLY->TEACH->REAPPLY approach. This approach is derived from my experiences teaching computer science courses, and partially from my own experience as a student in these areas. I have found that on several occasions I grasped the concepts being taught in a course more strongly after revisiting the content in later classes. I believe the reason for this deeper realization was due to my attempts to implement and exercise ideas from previous courses outside of a prescribed assignment. I see no reason students should have to experience learning after the fact, and that teaching can be enhanced by making better use of context during instruction.
This perspective on education is captured nicely in David Perkins’ “Making Learning Whole” where he develops his arguments on education around a simple metaphor of playing a game, and provides a set of very practical principles. Perkins’ major argument is that formal learning often excludes students from “playing the whole game,” and instead introduces them to many elements that will be important for issues further along in the curriculum. Teaching with this sort of piecemeal collection of topics and issues can create a situation in which students struggle to see the point of what they are learning from a holistic perspective.
To provide a more top-down perspective on the topics I teach, I often attempt to incorporate real-world forms of problem solving that make use of significant amounts of trial and error so as to build a stronger context for learning. Doing this typically involves a project based approach, where students suggest projects or a problems they would like to investigate and start immediately using what they already know. For instance, after a few rudimentary lectures, a student may state the desire to implement their own blogging software. At this point I would ask them to think abstractly about how something like this would be constructed, teasing out thoughts like, “I need a place to store what people write.” At this point, I would suggest that they start researching how arrays, hashtables, and lists, work to see whether such data structures would offer a good solution, and then let them attempt an initial implementation on their own. Of course the student’s first attempts tend to turn out poorly, but this approach provides the necessary context in which they can be guided toward developing better solutions for the problems that have arisen during their initial implementations. Indeed, using something incorrectly is an excellent way to realize how it should be used appropriately.
This method is at the core of how design is taught within Indiana University’s Human-Computer Interaction and Design program, but I have also found it very useful for teaching physical prototyping, programming, and Logic. In situations where I have had students building physical prototypes, I describe the different electronics that could be useful for adding sensing or motor articulation to their projects, but for the first pass I put them in charge of generating the initial ideas for their prototype. We then begin discussing possible issues and alternatives before actually constructing the first incarnation (alpha). This first version is often flawed and impractical, but is valuable in that it always parks a wave of new ideas and realizations that are quickly incorporated into the following beta version.
These flawed and impractical initial prototypes are where the learning really takes place within this teaching approach. In my experience this process has been highly engaging to students. The act of selecting their own projects and examples makes the coursework more interesting and engaging to the student, and quickly churning out solutions so that their faults can be more clearly analyzed creates several learning situations and “ah ha” moments. I believe this approach ultimately provides deeper understanding, and ultimately better students.