The downside, of course, is that you have to work with another person, and most programmers have a hard time doing that initially (after they try it, most like it). I’m not sure why I’m mentioning this, other than I think it’s interesting that programmers and professors have similar problems, with similar solutions, and similar barriers to adoption.

This is also about an anxiety about imposition on others coupled with the fact that to externalize what I have in mind is actually a lot of work for me. This is one reason, for example, that co-teaching is hard not just for me but for everyone I know. Collaborating with people in a teaching environment is generally not less work (which is what outsiders think) but it’s more work, because it means the collaborators have to explain and externalize much of what might otherwise be implicit and on-the-fly. Let’s take the machinima case. If I practice a bit with FRAPS and other things over the summer on my own, I can probably explain to students how to do what I have in mind well enough for them to take a shot at it, as long as I’m not too hung up about the quality or proficiency of the results. If I get more ambitious or more demanding in my expectations, however, and I turn to a partner in ITS, now I have to make time early in the semester to sit down and explain what I have in mind. I need to review with my collaborator what we have available. We may have to take several passes at it to find out what’s going to work. The results will be far better, but the time and planning involved is more considerable. (This is kind of commonsensical: better planning, better results. But on the other hand, there’s the danger of the perfect being the enemy of the good.)

There’s also a problem that someone who is kind of sporadically literate about IT the way I am has big holes in his knowledge base. Sometimes you know what you don’t know, sometimes you don’t even know what you don’t know. In either case, that can really slow things down, or if the knowledge seems too basic, it can feel terribly embarassing. I know almost nothing, for example, about the UNIX structures that underpin OSX, and sometimes that’s actually pretty relevant to things I might want to do. (I was struggling the other day with a permissions issue, for example.)

Tim–

Plenty of other faculty find ways of dealing with the problem without themselves having to do everything themselves. It sounds like the main obstacle is that you think that you have to do all the hands on work yourself, rather than planning with skilled partners to develop curriculum. Courses in video production, visual ethnography, etc. have gone on for years at our institution without the instructor having to do all of the “lab” work. How do faculty in the sciences manage experimental/applied components of instruction?

Many of the things you dream up could be pulled off, but would require a lot of advanced planning with others. For the most part, you’re used to being a solo act, right?

What about taking advantage of competencies that might exist within a class group, but not be evenly distributed? That might work for something like your machinima example, where the more technically inclined in the group might show examples or lead the groupwork?

You shouldn’t feel guilty to use technology just because you’re generally interested in it. You’re capable of teaching successful low-tech courses. But if you really think there’s value in using digital applications, simulations, experiences, etc. to teach a subject, it can be done if you’re willing to adapt your workstyle a little bit.

If you don’t have any such professors, of course, then you have a problem– you can either abandon your efforts, or begin yet *another* course, this one informal, to evangelise GIS to them. And there goes 4-8 hours a week (at *least*) you’ll spend helping them out that you can’t use for class prep or simply keeping up with your journals.

It’s not just you, though– even in IT there’s the problem of what happens when a guy on your team learns about this l33+ new program or language or what-have-you. We have to make the exact same sort of tradeoffs in terms of do we introduce technology that may perturb an existing system (but eventually leave it in a better state), or don’t touch something that ain’t broken. I suspect the major difference is that we do it more often, but you’d be surprised (or perhaps not) at how often the answer is, “Yeah, that is very cool tech– now drop it and go back to something that won’t break the world as we know it.”