The following list of rules is neither complete, nor in pattern form. However, they feel like (part of) a pattern language to me, and in any case, they can always be applied to teaching patterns...
The majority of these was inspired by "Thinking, Learning, Forgetting" Frederic Vester (at least that's the translation of the title from German). --FalkBruegmann
Goals: Have them and explain them!
You want your students to be motivated? Make the goals of your course (book, ...) explicit. Explain to the students what they, personally, can gain by achieving these goals. Explain how, exactly, your course will help them get there. Be prepared to leave anything out of your course that does not contribute to the goal (sometimes, this takes guts!).
Start lessons by getting the students up to speed!
Start every lesson (chapter, ...) by asking, "Where did we come from? Where are we now? Where do we want to go (goals)? How will today's lesson help us get there?" End lessons with a summary and a look ahead.
Structure courses top-down!
Sub-topics should be presented in the order in which they are easiest to understand, not in chronological or any other order. Start by giving an overview, with which following information can be connected. Trying to go bottom-up, students easily get lost in all the detail.
Weave a tight net of understanding!
In order to tightly inter-connect all the information presented in your course, make your outline explicit, show links, draw comparisons, give summaries, use comprehensive examples. This improves learning as well as understanding.
Concrete before abstract!
Examples before rules, reality before model. Applying YouArentGonnaNeedIt
, you can't factor commonality out of two methods when you have written neither of them. Neither can you factor abstraction out of two examples when you have presented neither of them.
Beware of chunking!
Humans can only parse 7+/-2 units of information, so-called chunks, at once. But what is only one
chunk for you, may
have to be split into several parts by a novice for understanding. So: Use short sentences - only one thought per sentence, only one topic per paragraph. Explain all termini technici.
Explanation before expression!
When you explain a new technical term, do so before you mention that term. The explanation can likely be linked to something the student knows, and after that, the new term can be linked to the explanation. Think of it this way: Everything the student doesn't (yet) understand, gets put on a stack. Several items on that stack mean stress, and at some point, understanding breaks down. Optimize your explanations to keep the stack empty!
Good definitions are bad explanations!
A good definition packs all important elements into one or two sentences, without any redundancy. A good explanation is split into many short sentences, and looks at each point from several different angles for better understanding and remembering. So: Define terms after explaining them, not instead of explaining them!
Tell Me Three Times
Repitition is the key to understanding. As they say in the US Army "Tell them what you're going to tell them, tell them, and then tell them what you told them." Inform the students of what the major concepts are, give them the details of the concepts, and then summarize what you've done to ensure that they understood the big picture.
Establish feed-back loops!
No great product is made without testing. Stay in contact with novices, and ask for feedback from students after every lesson (if possible one-to-one, not in front of the whole class - critique is hard to bring up there). Have a written survey in mid-course, and try to act
on that feed-back immediately.
Examples, examples, examples!
"Example isn't another way to teach, it is the only way to teach."
Repeat, but don't repeat!
Summaries, look-aheads, examples, applications, exercises, re-wordings, ... - help not only to inter-connect the content, but also and above all to repeat it. This is the
key to learning as well as being able to
what you have learned. Why? Information that is repeated and connected in a lot of different ways can easily be retrieved in a lot of ways (like a database with a lot of indices, inversion entries and lookup-tables). This helps you to transfer your knowledge to new applications.
It is always easier for people to understand something new if you can draw analogies from their everyday world (even if the analogies eventually break down). Wherever possible, turn these into entertaining stories. This serves two purposes: Learners who are struggling to understand the concepts get an easilly-understood structure on which they can hang the new concepts; Learners who already understand the material, or who are assimilating it with ease, are kept entertained, and therefore involved with your presentation.
Also have a look at...
Does anyone here know of books that offer advice for industrial trainers?
I'm looking for advice on:
- collaborative exercises
- raising the amount of student participation in sessions
- group work
- advice on constructing sessions that apply "learning by doing" (for example programming)
Reading the book "Synergogy" [http://nim.itgo.com/edpsynergogy.htm
] changed the way I teach. I now use group sessions, and make maximum use of their writing their answers on flipcharts and hanging those up. Good for requirements and design, may not be so perfect for programming. --AlistairCockburn
, [-- fp]
What about a SmartWiki
as a platform for teaching/learning programming? -- FridemarPache
It's not a bad way to distribute notes and other materials, but what I'm really after here is a more practical teaching style.
has done a lot of thinking about how to improve the learning process. --AlanBaljeu?
Somebody once said something like:
Telling someone something is a lost chance of them discovering it for themseleves.
A teacher creates situations in which students discover and teach themselves.
see also DoItAgainToLearn