[clug] Writing Training Materials

Ian Matters iristech at gmail.com
Fri Mar 24 21:05:30 UTC 2017

Thanks Paul for your positive contribution.

Cheers, Ian Matters

> On 25 Mar 2017, at 7:39 am, Paul Wayper via linux <linux at lists.samba.org> wrote:
> On 23/03/17 22:25, Bryan Kilgallin via linux wrote:
>> Jeff:
>>> Anyone know of any good references on writing training materials?
>> I did a graduate diploma in Tertiary Education. That was at Darling Downs
>> Institute. Which became the University of Southern Queensland.
>>> I (or
>>> someone else) might be need to write some in the near future for work
>>> and I'm looking for something to give me a way to approach it.
>> Take a course such as the above. This isn't trivial!
>> Supposed training presentations are often bad, in various ways.
>> I've seen:
>>    * overcrowded, too-small text that was illegible;
>>    * books written in a language other than the reader's;
>>    * a topic irrelevant to the audience....   
> Bryan, if your only contribution to this conversation is to tell people that
> they're doing it wrong, then please don't reply.  It contributes nothing to
> the discussion.
> We should all aim to give constructive information answering the question.
> Re Jeff's original question:
> I don't have any good references, sorry :-)  But I do think there are a number
> of basic things involved in training people well:
> * Outline what you're teaching at the start of each section, and conclude with
> a summary of what they've learned.  It's hackneyed but it works.
> * Involve people often.  Simple questions like "has anyone here used git?" or
> "can someone tell me the differences between TCP and UDP?" are common fare,
> but they still work.  One trick I learned last year is that if someone asks a
> question, see if anyone else in the class can answer them.
> * Aim for blocks of no more than an hour, which is people's usual
> concentration span.
> * Look for a natural progression or story in what you're teaching.  This often
> takes the form of what people want to achieve, and then how this new thing
> you're teaching them helps with that.
> * Avoid correcting people individually if possible.  Instead, try to
> generalise that out - e.g. "OK, I can see a few people are still having
> problem creating a merge request, so let's go over those steps again."
> * Your only form of humour is lightly self-deprecating.  Never make a joke at
> anyone else's expense.
> * Use different media.  There are three basic forms of learning - textual
> (i.e. reading text), visual (drawing diagrams) and auditory (listening to you
> speak).  Most people find one of these three to be easier.  So mix them up to
> give everyone the best chance of learning.
> * Everyone learns better by doing than by watching or listening.  So aim to
> include practice sessions.
> * For practice, make sure you have printed material for each person that gives
> them the commands or the steps of what they're doing.
> * There'll always be people that learn faster than others.  Think of ways you
> can engage those people - either get them to help someone else, or get them to
> try something more advanced, or have them find something out - or just ask
> them to wait quietly.  Try to avoid having them go ahead.  It's not a game to
> see who can get to the end of the training material quickly.
> * Always practice your material.  Allow at least two run-through sessions
> where you talk through the class material and then sit down and do your
> practice work.
> * In your practice, look for friction points - places where everyone's waiting
> for something.  For example, it takes time to hand out sheets of instructions,
> so consider how often you have to do that and try to minimise the amount of time.
> * Ask for questions regularly, especially before you've given the summary.
> That's all I can think of right now :-)
> Hope this helps,
> Paul
> -- 
> linux mailing list
> linux at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux

More information about the linux mailing list