Two of my core assumptions in working through the approach are: (1) if you drill down enough everyone is a hacker and (2) instructors have an intrinsic need to talk about their teaching. I want to talk about the implications of these assumptions, but first I want to offer some justification for making them and also to clear up what I mean.
I will do this via example. On our campus we have a highly dedicated and super knowledgeable (about the technology) leader on Web accessibility. His name is Jon Gunderson and he has a good and dedicated staff working under him. Over the years, Jon has taught me a lot about accessible design, though I still have much to learn. (For example, I don’t know how to use CSS and position elements on a Web page without using a table.) Occasionally in the past, I’ve taught Jon a thing or two about how instructors “think” about design. We’ve made some progress on bringing those two distinct ideas into alignment. But convergence is not yet on the horizon. While that is clearly the goal, there is some benefit in not yet achieving that goal from the point of view of understanding how content creators actually use the tools that are provided to them.
I’ve now seen Jon make the point a few times so it resonates with me that almost nobody learns how to use the Microsoft Office tools (think of Word, primarily, and also PowerPoint and for now ignore anything more exotic) via formal training and hence rather than learn “the correct” way to do things, many people “hack” solutions to formatting issues that work visually for them and so seemingly solve the problem they are trying to address when they design the document. (And I might add that some secretaries are as bad as the faculty in this regard and don’t have a clue about the appropriate use of Tabs, Indents, Tables, etc. as distinct formatting elements.) As a reader of such documents one is typically oblivious to this type of hacking, but if one is editing a document done this way, God help you. One small change seemingly destabilizes the entire piece.
I believe we all do analogous things in our teaching, because there are a lot of issues that come up which have not been anticipated beforehand so of necessity have to be addressed on the fly. This might include when it is appropriate to grant exceptions to stated course policy about deadlines for assignments, how to adjust the course schedule if a topic takes longer than anticipated, or what to do if the server acts up right before an assignment is due. My guess is that this list is the tip of the iceberg. In this sense all instructors are hackers.
Eric Raymond in the Cathedral and the Bazaar means quite something else by use of the term “hacker.” To him hackers are very good programmer who work on trouble shooting some code. Indeed, the general “problem solving” use of the word hacker is either out of vogue or hasn’t made it to such august sources of reference a dictionary.com (being a bad golfer is one definition they provide) and wikipedia.org, which has the Eric Raymond meaning and the evil alternative – folks who break into other computer systems for illicit reasons. I’m going to keep my alternative for a while in this post because part of what I’d like to discuss is how to modify the approach to be more like what Raymond means.
Let me turn to the other assumption, that instructors want to talk about their teaching. There is an important caveat. Many instructors have been scarred by teaching. The experience was unpleasant if not outright painful. And the students may very well have been hostile to the instructor’s efforts. Under that circumstance there may be very good reasons for the instructor to clam up, even if the instructor is desperately looking for ways to improve the teaching approach. So the conditions must be set to get past that initial shyness.
The second assumption really follows from the first and thus it follows from the more general idea that if one is engaged in problem solving, one typically wants feedback from others who might have a different perspective. And in reciprocation, the instructor who gets such feedback might very well be willing to provide such feedback for others, as long as on the receiving end the feedback is useful and timely.
So what I envision has faculty at various stages in their development as teachers initially interacting one-on-one with Linus Torvalds styled leader and discussions of both the teaching and possible technologies to advance the approach. This one-on-one interaction is in the style of a co-author relationship, because that most suits the cultural environment in which the faculty member operates.
In this milieu the leader offers tips and suggestions of possible things to try. At some point in the trajectory, the leader moves to suggestions that come from the problem solving/issues of other instructors. The leader needs to give a focus on common issues and then when solutions emerge try hard to transfer those among the group of instructors.
In this context, open content generated by the instructors (sharable learning objects) might be very useful as the embodiment of solutions and therefore as templates for transferring such practice. Consequently, any such approach to faculty development must include as part of the effort a repository for sharing these type of learning objects. Ultimately, instructors might go to the repository to learn about teach approaches in an unmediated way, but initially it will be the leader who recommends that the instructor look at specific learning object that might serve as a template. And conversely the leader serves in the role of encourager and provocateur in moving instructors in the community to create such objects. The leader also marshals the support resources so that the instructor doesn’t feel overwhelmed from this type of participation.
The leader also makes the ideas and findings of the members public, first in a very informal way such as via a blog, but then in a way that is more systematic and meant to be generalizable. This is what I referred to as the primer, in an earlier post. By making these things overt to the community, the leader is both encouraging the same type of social/intellectual interaction that Raymond identifies with open source software development and also aims squarely at improving the quality of instruction practice, as it is rooted firmly in the community development activity.
The key issue and what seemingly will make or break the approach is if “majority” faculty members (as distinct from early adopter faculty members) are made to feel first comfortable and then interested in seeing their questions and problem solving solutions being discussed openly by the leader. If they can be made to both approve and participate in the process then they should increasingly look like early adopter faculty, who likely will readily contribute their solutions from the start. And if that happens, these faculty members who are hackers in the original sense that I described will in the process of moving down their own learning curves transform into the type of hackers in the sense of Raymond, whose contributions have social value beyond what they use for their own purpose.
So what I’m proposing is that faculty development change from a process where pre-established knowledge from the outside is brought into the development process and where the faculty are viewed as the recipients of the development activity, to the alternative where the faculty members make new, situated knowledge in the process of their own teaching, and the assessment and diffusion of that knowledge becomes the basis of the development activity.
I wonder if this can work. I’d like to give it a try.
No comments:
Post a Comment