How to teach OS

[Martin P. Hellwig]

Zera William Holladay wrote:
Hi, I have a pedagogical question.

If you (a developer) were teaching a first level college course in
operating systems with the goal of (eventually) transforming each student
into a *BSD developer, then how would you teach the course?
Specifically, what programming assignments would you have?  What material
would you cover?
When you took your first course in OSes, what was wrong with it?  What
would you have taught yourself then?
I know these kinds of questions frequently pop-up on mailing lists (how do
I become a developer, etc??), but I'm asking these questions with the
intention of suggesting your ideas to my instructor so that I might be
able to do them as assignments (and get grades for them).
Thank you, Zera Holladay
Please define first what level op competence you expect of a *BSD 
developer at the end of your course, somebody who can develop _on_ *BSD 
or on and _for_ *BSD and in what language(s)?

What is the expected knowledge level of the students starting your 
course? And how do you deal with students not having that minimal 
starting knowledge?

I never followed any official programming courses, hell I never had the 
chance to study but being an administrator on a high school and doing 
sometimes replacement classes give me some basic insights on the 
pedagogical issues.

Some tips I've got from the pedagogical experts at my school.
Always try to teach in modules. How you make the modules dependence on 
your pedagogical preference and on the opinion of you direct colleagues 
if you have any.
But mostly a module taking about 60 minutes is the standard, max 20 
minutes reading/studying text and 40+ minutes working it out (dependence 
on the speed of student).

Try to excite the students before starting the module of what he can do 
with the knowledge after he mastered the module.
Make a road map of module dependencies.
Create a test suite per module with about 60 multiple choice questions 
testing every aspect of knowledge learned in that module, if you redo 
the course another semester try to increase the multiple choice question 
with again 30 question.
Don't make obviously wrong answers, try to create answers that at first 
site seems all possible (of course only 1 should be correct).
Test the students with between 30 or 50 questions per module (randomly 
choses of your 60+ questions).

You don't test the students over the entire course but if he mastered 
that specific module so you must expect that about 90-95% to 100%  of 
the answers are correct, more then 10% wrong usually indicates that the 
skill isn't mastered enough (or the explaining material wasn't good enough).
After 5 modules retest the student with about 100 questions, again 
expect about 90-95% to 100% correctness rate (luckily enough multiple 
choice test are excellent material to automate).

So how do you handle students trying to learn the multiple choice 
answers and not the material? The trick is to create the questions that 
way that if a student manages to learn all possible answers he has 
enough knowledge to master that module anyway (that is its easier to 
learn the stuff in the conventional way).

My personal experience, which I learned the hard way.
To create a good module it is required that the creator of the module 
has superior knowledge of the required knowledge, it happens too often 
that classes are given by teachers not knowing the material enough.
What happens is that the teacher is not capable enough to know if the 
student has mastered the knowledge or even worse, the teacher can't see 
if the student has learned it wrong. Nothing is more frustrating then 
being taught by a nitwit who teaches factual wrong material.

--
mph