Re: Perl Instruction at NIH

Brad Lhotsky writes:

> I work as a security adminisrtator at a small NIH sub-organization.

Hi there.  I've no idea what NIH is, but I suspect it doesn't matter for
my response.

> Is there any advice for what my expectations of material coverage will
> be for a 9-4 class ?

Generally allow 5 times as long to write material as to present it; that
is, allow a week to write a 1-day course.  Possibly longer if you're new
to writing training materials.

> I didn't actually have any coding exercises, which I'd like to have in
> this new class.  ...  I'm just asking for any "helpful" advice the
> veterans would be willing to bestow on a fledgling perl trainer?

Obviously for exercises to work it has to be possible to answer them
using the material previously covered.  If you present material in what
seems like a logical order from a taxonomic point of view you may
struggle to think up exercises that are possible using only what's
already been taught.

Or you may write exercises that seem plausible, but actually when doing
them you would naturally use constructs that haven't been introduced
yet, so you end up with a roomful of people writing programs that aren't
representative of what you'd recommend.

The way round this is to work backwards:

* First write a few 'sample solutions' that are the kind of program that
  you hope folks to be able to come up with after each session.

* Then come up with some questions to which those sample solutions are
  possible answers.

* Lastly write the presentation that covers the material needed to
  answer the questions.  If you find yourself wanting to include
  something because it seems 'orthogonal' with other material you're
  mentioning but isn't actually useful for the exercises you've written
  then stop and question whether it's necessary.

  For example I've seen Perl courses where there's a section which
  covers "operators", and does so comprehensively, even though, say, the
  bitwise operators aren't particularly useful at that stage.  Similarly
  C<or> is very handy for catching errors (such as in 'open this file or
  die'); C<and> is much less commonly seen and doesn't _have_ to be
  mentioned just because C<or> has been.

Remember that presentations are good at explaining concepts, but bad at
dispensing lists for the audience to memorize.  People new to Perl are
likely to need concepts like context explaining; however once shown in
general how to call built-in functions they are likely to be able to
cope with calling C<uc>, C<hex>, C<index>, and so on without further
assistance (and those that aren't wouldn't be able to take in a
presentation in which every function was explained in turn anyway).

So make sure that you show people perldoc -f or perldoc.perl.org (backed
up with exercises that involve using functions that haven't been
explicitly explained), and search.cpan.org.

Have fun, and good luck!

Smylers