DragonFly BSD
DragonFly users List (threaded) for 2005-03
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: How to teach OS

From: "Martin P. Hellwig" <mhellwig@xxxxxxxxx>
Date: Fri, 04 Mar 2005 18:29:22 +0100

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.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]