I really enjoy teaching. I think it's quite a rewarding thing to do. And generally quite fun. But *boy* is it hard work. From preparing the slides to going through what you need to teach, and the objectives you aim to reach at the end... lots of work. Every time I give a talk or tutorial I also realise that I just plain need more slides. There's simply no way around that - people grok stuff a lot more if you break it down really carefully into small components, and I'm forever discovering more ways to break down my slides to make these concepts easier to understand.
This is especially significant trying to teach XML stuff to Perl geeks. Last night trying to teach the basics of XSLT in 10 minutes reminded me that there's so much ground to cover before you can even get into XSLT itself - XML namespaces and XPath being the two core things there. But you can't do a tutorial like Hypertext - jumping right off one subject to another. It has to have a natural progression - and AxKit doesn't lead naturally into teaching XPath... So for now I simplify XPath by saying "It's unix directory paths into the XML". Which is how it was designed I guess. Anyway I hope my jumping about pointing to bits of my slides weren't too disjointed last night. I certainly realised one thing last night: you can't just teach one little bit and then expect the audience to grok a huge chunk of code just because it's using similar features... Each little bit needs explaining in detail.
Anyway... On to work. I spent a couple of hours the other day writing mkrpm.pl - a script which uses CPAN.pm to download files from CPAN, build them, pull out pre-reqs, and build a proper LSB/RedHat RPM of the module. It works *really* well, for me. But the code is awful, because CPAN.pm doesn't really expose an API, so it only worked in the most recent version of CPAN.pm... So today I'm having a look at CPANPLUS. I sent a patch to the author as it wouldn't compile on 5.6.1 with the latest Term::ReadLine. It looks nice - I can now basically go fetch(), extract(), do my make bits, built the .spec, copy it to /usr/src/redhat/... and build the RPM. Much easier than my hacky code around CPAN.pm. Neato.
The long and short of it is that it's quite rare that a technology succeeds simply on it's merits. It is much much more common to produce a product that actually solves an existing problem in a user friendly manner.
Nothing new here, but it's surprising how often this lesson needs to be learned and the number of contexts to which it applies.
Teaching anything about XML is notoriously difficult because the people who know enough about it are attracted to the technology, not to the user's problems. (I for one still don't understand the allure of HyTime, except that it provides a nice rat's nest of abstractions that will seed a thousand meaningless PhD theses.)
Most of the time in XML Club, it's nice and easy to describe what an innovative module like XML::Twig or SAX Machines does in about 45 seconds. Establishing that level of experience from ground zero is very difficult, because the simple process of converting Document A into Document B doesn't naturally lead to the discussion of xml:base, namespaces, pipelines or processing instructions. Ostensibly, that is what students want to learn, but what they really want is a way to see how their transformation from A to B is easier with the appropriate incantations of UDDI, WSDL, SOAP and REST (or Namespaces, XPath, XSLT and RELAX).
The couple of outlines I've been writing and reviewing for the last few months de-emphasize the technology and re-focus on the problems being solved (and why things like Namespaces are a good thing, instead of offering simple proof of existance through usage). This is somewhat similar to the same approach used by Abelson and Sussman in SICP: start with a common problem (lcm, gcd) and rework it until the underlying concepts are clear, and then move on to passing closures all over the place.
*: Unfortunately, the teaser is free, and the PDF-you-pay-for is about as much as the entire magazine; it's quite worth reading.
Re:Focus on the student
gtod on 2002-03-28T15:52:40
Amen. So, so much of technical literature (books, magazines, online articles) start off with "Today we'll be learning about super dooper new technology X. I'll show you how it can be used to convert widgets of type A into type B...".Of course I have no idea why anybody would want to do that. Maybe there is no good reason in which case I'd like to be able to skip the whole article. But if there is a good reason knowing it makes it so much easier to learn the technical details.
I once thought I should be a teacher, because I liked explaining things.
But it turns out that I like to explain a thing once.
So I write instead of teach.
