taylor@hpdstma.hp.com (Dave Taylor) (07/29/88)
I think that a lot of interesting points have been raised so far in this
discussion, but I'd like to add a few of my own (not necessarily unique).
The basic question that this all revolves around, I think, is Why are
people taking the class? For the most part, when I was in college (UCSD
for my undergrad work) I was in the class to learn as much as possible
about not only the subject matter but solution methodologies, debugging
techniques (something that is *never* taught), and ways to ensure that I
would be a success as a programmer were I to choose it as a profession.
By the numbers:
1. to learn the subject matter
Learning is by doing, so the part of programming classes that
I best remember is the homework assignments (which I always
did as soon as they were assigned). I always did my own work,
but working in groups was educational too, leading to:
2. to develop the ability to communicate with my peers in a
work/project situation, and to work with a group
This is another skill that isn't really taught, but is
instead thrust upon the students. Why not classes on "how to
work with people" and such instead of the typical fight for
control/lack of initiative/crummy partners cycles that go on?
3. to learn how to communicate my solutions to an impartial, but
knowledgeable third party
If the grader didn't like the way I programmed (which happened
a couple of times) then I'd get poor grades on my assignments.
If it didn't make sense, if it was confusing, if it wasn't well
and thoughtfully commented, if ... well, it's another skill
that serves well in life.
4. to learn how to solve problems
This is probably one of the so-called metagoals of a college
education - to learn how to approach a problem and dissect it,
then solve it. In programming, this sometimes required that you
experiment with algorithms, and sometimes required that you
learn how to use outside reference works:
Part of problem solving is to solve problems that are raised
by the particular implementation (eg. debugging). That is, as
mentioned above, sorely lacking in current CS coursework.
5. to learn how to use reference material
I believe that there are certain classes of assignments that
are best and most reasonably solved by consulting a reference
work like Knuth and using it as the basis for your own
implementation (properly cited, of course). There are also
others that are better left for the student to experiment
with, however ("what algorithm works best in this situation"
is a good experimentation example, and "what's the best way to
implement this algorithm" is a good reference example).
Without totally belabouring the point, I think we can probably
agree that there are a number of problems that are best suited
for either learning by experimentation or learning by leveraging
off of other, standard reference works (by way of example, art
classes use paintings from other painters, music classes use
music from other composers, writing classes and other writers,
even hardware design classes and other designs (also known as
the Verezano Narrows Syndrome ;-)). The class of problems
in the middle, that could be done either way, is probably
best left to student initiative, with the grader encouraged to
rate them based on *initiative* and *thinking* demonstrated,
rather than whether it's the optimal solution or not...
[in real life we rarely have time to find and implement the
optimal solution; if it's "pretty good" then it's probably
good enough to get on with the job...]
Thoughts?
-- Dave Taylorreggie@pdn.UUCP (George W. Leach) (07/30/88)
In article <2155@hplabsz.HPL.HP.COM>, taylor@hpdstma.hp.com (Dave Taylor) writes: > I think that a lot of interesting points have been raised so far in this > discussion, but I'd like to add a few of my own (not necessarily unique). [NOTE: Lots of excellent points deleted that I completely agree with Dave on. I would like to point out that before one can build upon the work of others, one must fully understand the fundamental concepts behind that work. One can not learn this by blindly applying the results of others' work without a solid grounding in the basics ] > The basic question that this all revolves around, I think, is Why are > people taking the class? For the most part, when I was in college (UCSD > for my undergrad work) I was in the class to learn as much as possible > about not only the subject matter but solution methodologies, debugging > techniques (something that is *never* taught), and ways to ensure that I > would be a success as a programmer were I to choose it as a profession. Right! And many students *DO* fall into this category. The problem is that others are motivated by other aims. For some a degree in CS means a job. For others, perhaps a promotion. For some, it may be used as a stepstone towards an ultimate goal of getting into management. Whatever the motivation, some people are driven by factors other than the desire to learn. For those people the ultimate goal of a course is a good grade, regardless of the amount of informaition derived from the course. That is why people avoid certain courses and instructors, etc..... The question is, should those of us who are concerned with learning, need also to be concerned with preventing those who are not from gaining the same recognition, in the form of a degree, as we achieve. Or should we just MYOB and be content with the fact that we earned the degree? -- George W. Leach Paradyne Corporation ..!uunet!pdn!reggie Mail stop LF-207 Phone: (813) 530-2376 P.O. Box 2826 NOTE: codas<--->pdn will be gone soon Largo, FL 34649-2826