Bob La Quey wrote:
My point is that getting a student to a certain benchmark is
a lot easier with a good learner. After all that is the definition
of a good learner.
That's true.
My experience was that the teacher was only rarely of real value
in imparting knowledge. I can think of three instances during a
long period of being "taught." Mostly teachers seemed to require
attendance at boring sessions which were covered better by books
and the literature.
Well, I never *require* attendance at lectures for technical subject
matter. If I'm not lecturing well enough for you to want to attend,
then don't. I used to even record my lectures--the result was a mixed
bag. Nothing negative about the recording (in this age of cell phones I
have to assume I'm being recorded anyhow), but it was an annoying amount
of work for me to do the conversion, compression, upload, web page, etc.
However, there are some classes that depend on class participation where
I understand the mandatory attendance. Language classes, for instance,
demand participation.
I'm sorry that you had so few good teachers. I can think back to quite
a few teachers and mentors who made things a lot easier and better for
me. I can also think back on quite a few that wasted my time.
I do hope we get back to trying to figure out what programming
is though. Instead I suspect the thread will rapidly degenerate
into a debate on teaching and education :( Please folks do change
the subject line if you feel compelled to go that way.)
Well, part of the reason for arguing this way about programming is to
show that we're not solving a fixed technical problem like a hard
science. We're moved firmly in the direction on engineering, and I'm
arguing that we've moved much further than even that.
We're in the realm of social science, and that's a very different beast
from hard science. It becomes far more difficult to make good
predictions and choices. Defining a "good programmer" has many of the
same difficulties as defining a "good teacher". Who gets to judge?
What should the end product be? How do we test that?
As for the people who want to equate programming with engineering and
say "Well, they handle all this complexity." I like to point out things
like The Big Dig, The Three Gorges Dam, etc. The results of those
projects resemble most software project fiascos quite well, thank you.
Encouragement is important, but there is value in the knowledge and
experience of the teacher.
Give me a good guide to the literature. Then leave me alone. I can
use my time more effectively if left to my own devices.
I suppose you could argue that computers are extremely poor
learners so that is why they are hard to teach. As far as
I am concerned that simply stretches the metafor to the
breaking point. Human based metaphors for programming or
computing mislead more often then enlighten.
Sometimes. However, a computer is *truly* stupid. Programming a computer
is explaining things to a very obedient, but very dumb automaton.
So is that what you consider teaching in this case?
You have just said that teaching a bright student is hard.
Now you are saying also that teaching a dumb student (a computer)
is also hard. I am getting the feeling that you are arguing
"Heads, I win. Tails, you lose." for your metaphor.
I am _not_ buying that argument :)
That's fine. :)
There are lots of things were dealing with the median is easier than
dealing with the tail. Normally, the difficulty in dealing with the
very top is a very different difficulty from the bottom. However, we
often understand the problems of dealing with the median fairly well.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
