cdshaw@alberta.UUCP (Chris Shaw) (03/28/88)
In article <563@psu-cs.UUCP> warren@psu-cs.UUCP (Warren Harrison) writes: >This is a very good suggestion. However, here is my problem ... how do you >justify to a student that a program to compute the sum of a list of numbers >uses a procedure? One suggestion below. >One approach that I have found >to work quite well however is in the COBOL programming course. The first few >programs involve the (extensive) modification of a working program of several >hundred lines of code. The students really appreciate the existence of comments >and meaningful variable names then. Also, the program tends to serve as an >example of the type of commenting and style I expect from the students' >programs. This is also good, but the reason why one does such stuff should be clear. >Warren Harrison >The University of Portland The suggestion follows: Split the course assignments in two phases. Phase 1 is "learning the language". In this phase they learn ALL the stuff they will need. Standard trivial assignments are handed out, and marked mainly for correctness, with small penalties for style and comments. State this up front: "The purpose is to get running programs. This will teach you the language. But realize that these are TOY PROGRAMS, and as such are not to be interpreted as stuff you will see in real life." Prove this by bringing in the source for a nice big chunk of code. Like the kernel of the nearest available OS. Phase 2: Give them a hard assignment that you couldn't do in the time allotted. To be fair, tell the students this well in advance. There is no sense in treating them like children. Give them the straight goods. "This assignment is vicious, rough and nasty. It's designed to show you how little you know." Make it look superficially simple. Then mark it as if they were all grads. No mercy. Threaten that people who hand in nothing (or null answers) fail the course. (A threat which you won't carry through, of course) Hand it back at the beginning of class and wait for the disappointed silence. Then solve it in 3 minutes. (If you can manage it. Getting something that the uninitiated can't solve and that you can explain in no time will be tricky.) This will demonstrate the following: 1) Programming isn't coding. Programming is also high-level design. 2) Discipline pays benefits. After all, you did in 10 minutes what took them 1 week. 3) They now know the language much better than they did before. Clearly this is a left-field suggestion, but I have found in my experience that people operate to your expectations, and usually no higher. Make clear that you aren't going to take garbage, and people likely won't give it to you. The purpose here is to issue a challenge that everybody will take seriously and that everybody will accept. To have "wimped out" of the challenge must be seen to be the lesser option. (Obviously, you must leave escape routes for illness and other extenuating circumstances). The challenge must have a purpose, which is in this case to teach people the importance of discipline. It will also help them see the difference between the toy assignments you handed out earlier and the real stuff they will see during employment. <enter personal experience/pontification mode> Part of the reason the phrase "real world" comes up in the paragraphs above is that I found when I did my undergrad that I learned more from my first co-op work term (after 4 months of school) than I did in the first two years of university. Unfortunately, most university students in CS take bullsh*t summer jobs, and never truly experience the relevance of what they learn until some years later. At my grad school, I am constantly surprised at how little experience the undergrads and even some of the grads have. To compensate, and to make the students understand, real problems must be presented and attempted in class. BUT: Real efforts must gain real rewards. The one or two students who do well on the satanic assignment above must be amply rewarded. Exemption from the final exam or a can't-lose final must be the reward for excellence in the assignment. All students who did significant amounts of work in the assignment should receive surprisingly-high marks when they are recorded (versus the number on their paper). At one point in my undergrad years, I toyed with the idea of switching to Philosophy from CS. (I didn't) The reason being that there was a discipline in Philosophy that was being taught semi-explicitly. The "technology", so to speak wasn't important, but how you thought about it (various philosophies) and how clearly you explained them WAS important. In CS, the discipline of thought is not explicitly taught, and I think it should be. Discipline should be explained because it buys you far more than any other aspect of the technology. In particular, the details are not important, but the way of thinking is very important. The details of Quicksort are boring. The approach of Quicksort is a general algorithmic techinque that should be given much more exposure. Somewhere in Computer Science, in the miasma of algorithms, techniques and implementations, there are a few principles struggling to get out. If taught the principles, the new student will hopefully find the details of an algorithm to be simple, and readily producible. The problem is that Computer Science isn't really science. Math isn't science either. Math is philosophy (in the broadest terms). CS is also philosophy, to some extent. The major difficulty being that people see CS simply as technique, and that solving its problems is something to be done simply by dint of hardware and software engineering. I think that there's a lot more to it than that. Witness the failure of AI to be anything more than technique and boiled-down examples with funny names that do fairly simple tasks in straightforward ways. Witness Parnas' answer to the question "Can you tell me what is a module?" (Answer paraphrased) "Of course I can tell you! I teach a whole course on it!" Well fine. But there is clearly something more going on here than, "Well, use it. It works". Parnas' lack of a succinct answer to this simple question indicates to me that perhaps more thinking about thinking should be going on, probably at the expense hacking for a solution for a specific problem. -- Chris Shaw cdshaw@alberta.UUCP (via watmath, ihnp4 or ubc-vision) University of Alberta CatchPhrase: Bogus as HELL !
warren@psu-cs.UUCP (Warren Harrison) (03/30/88)
> Phase 2: Give them a hard assignment that you couldn't do in the time allotted. > To be fair, tell the students this well in advance. There is no sense in > treating them like children. Give them the straight goods. "This assignment is > vicious, rough and nasty. It's designed to show you how little you know." > Make it look superficially simple. Then mark it as if they were all grads. > > Then solve it in 3 minutes. (If you can manage it. Getting something that the > uninitiated can't solve and that you can explain in no time will be tricky.) Real good idea. Any ideas on the assignment? I've been trying to figure such a task out for a number of years now. It is important that the students under- stand your solution, so anything too tough is out of the question. Keep in mind I'm talking people who can't understand how you can use a key value as a s sub- script. What seems even more puzzling is the ability of my current students is no where close to the level I observed 10 years ago when I did my first TAing. Has anyone else noticed this? Warren Harrison The University of Portland "The School on the Bluff"
rouilj@umb.umb.edu (John P. Rouillard) (04/02/88)
SALT (all line eaters need salt on their food)
My background in computer science has no grounding in academia. I
have worked side by side with other programmers who have B.S.
degrees (or are working toward (seniors)) in computer science.
The following three things are what I consider the most important
aspects of programming for industry.
I often find that these students CAN'T program modularly, CAN'T
give estimates of the amount of time that a project will take, and CAN'T
write code to specifications.
The reason that they have these inabilities is that they have never
had to do any of these things in their programming courses.
What I would like to see in programming courses (freshman) is the
development of a project throughout the semester. Not 3 or four
little independent programs (e.g. solving Tower of Hanoi, print "Hello
World" ...) but 3 or 4 programs that can be integrated to form a
larger program. This would allow:
1. Introduction to the language in small bytes. (weekly assignments)
2. Examples of modularization (each project is a module)
3. If you laid out specifications for each module then it would teach
the students how to write to specifications.
4. Make the students estimate the number of hours they think
it will take them. Then have them note the amount of time
that it actually takes to get things working properly.
5. For upper level courses make a larger project and have
teams of people work on segments of each module. E.G. in
data structures course one group designs a B-Tree ADT with
appropriate interfaces while another group tries to use the
unwritten B-Tree code for a cross-reference generator.
( Just wait until the two teams get together and find out that
their code won't run because somebody didn't write their
code properly. This will give them a real taste of the
outside world :-). (This method was used on me by the
teacher of a Data Structures course that was offered as an
enrichment course, no credit, undergraduate teacher.)
6. For senior level courses have the class work on a project
suitable for a master's thesis. They need to do all of the
design specs, partition the problem to the various groups
and so on.
a. Benchmarking, Code control systems etc could be
introduced in 5 or 6. Debuggers should be introduced
right in freshman year. They are really useful time
saving tools. Syntax directed editing should probabbly
be put off until after the students understand the syntax
of the language. (Teach the multiplication tables then
give them calculators.)
Granted the set-up of this scheme would take a lot of time on the part
of the instructor, but I think it would better prepare the students
for the particular niche of life that they have chosen.
The nice part of this is that the 900 man-hours (30 people in 30
hrs/semester) is used to teach them more than just the theory of
whatever they are doing, it forces them to look at a larger picture
which they may not be able to understand but can still build.
Comments on the above via e-mail will be appreciated. If you send me
flames get your mailbox asbestos lined.hsd@uvacs.CS.VIRGINIA.EDU (Harry S. Delugach) (04/04/88)
In article <1167@pembina.UUCP> cdshaw@pembina.UUCP (Chris Shaw) writes: > >Phase 2: Give them a hard assignment that you couldn't do in the time allotted. >To be fair, tell the students this well in advance. There is no sense in >treating them like children. Give them the straight goods. "This assignment is >vicious, rough and nasty. It's designed to show you how little you know." >Make it look superficially simple. Then mark it as if they were all grads. > >No mercy. > >Threaten that people who hand in nothing (or null answers) fail the >course. (A threat which you won't carry through, of course) > >Hand it back at the beginning of class and wait for the disappointed silence. >Then solve it in 3 minutes. (If you can manage it. Getting something that the >uninitiated can't solve and that you can explain in no time will be tricky.) >..... >The challenge must have a purpose, which is in this case to teach people the >importance of discipline. It will also help them see the difference between >the toy assignments you handed out earlier and the real stuff they will see >during employment. If this is what your "experience" has taught you, then it is a sad commentary on the state of things in the "real world". Perhaps some of the conditions you are trying to simulate are a source of its problems. The almost belligerent attitude recommended for the instructor-to-be sends the message to students that "the real world is cold, heartless, loathe to communicate and cooperate." Sure, there are plenty of places where this is true, but rather than teaching software engineering as a "discipline" or a set of survival skills, why not demonstrate the positive value of communication and cooperation? Unless you think they don't really have a positive value? If you want to simulate the real world to teach software engineering, then have a two-semester, full-time course, where students are taking nothing but your course. The high degree of commitment to a course that the disciplinarians require (approximating an employee's commitment to his employer) is not possible when students are also involved in other courses. Subject: Re: Soft eng in 1st yr classes.. pontification Summary: Expires: References: <555@psu-cs.UUCP> <1434@ur-tut.UUCP> <3415@bunker.UUCP> <5359@utah-cs.UUCP> <36845UH2@PSUVM> <563@psu-cs.UUCP> <1167@pembina.UUCP> Sender: Reply-To: hsd@uvacs.cs.virginia.edu.UUCP (Harry S. Delugach) Followup-To: Distribution: Organization: U.Va. CS dept. Charlottesville, VA Keywords: -- Harry S. Delugach University of Virginia, Dept. of Computer Science UUCP: ..!uunet!virginia!uvacs!hsd INTERNET: hsd@cs.virginia.edu BITNET: hsd2x@virginia
peking@sfsup.UUCP (L.Perkins) (04/06/88)
The original poster may not be aware that unlike resident undergrads, adult night-school students know full well that like is unfair, etc., etc. Why else do we go to computer lessons at night, short-changing our day jobs, our families, our health and maybe even our sanity? We don't need to contend with mind games on top of all that. Such an instructor is not going to score points with us. We know better. -- ________________________________________________________________ attunix!peking "The few, the proud, the red-haired" ---------------------------------------------------------------
cdshaw@alberta.UUCP (Chris Shaw) (04/08/88)
In article <2330@uvacs.CS.VIRGINIA.EDU> hsd@uvacs.cs.virginia.edu.UUCP (Harry S. Delugach) writes: >In article <1167@pembina.UUCP> cdshaw@pembina.UUCP (Chris Shaw) writes: >> >>Phase 2: Give them a hard assignment that you couldn't do in the time allotted. >>To be fair, tell the students this well in advance. There is no sense in >>treating them like children. Give them the straight goods. "This assignment is >>vicious, rough and nasty. It's designed to show you how little you know." >>Make it look superficially simple. Then mark it as if they were all grads. >> >>No mercy. >> >>Threaten that people who hand in nothing (or null answers) fail the >>course. (A threat which you won't carry through, of course) >> >>Hand it back at the beginning of class and wait for the disappointed silence. >>Then solve it in 3 minutes. (If you can manage it. Getting something that the >>uninitiated can't solve and that you can explain in no time will be tricky.) >>..... >>The challenge must have a purpose, which is in this case to teach people the >>importance of discipline. It will also help them see the difference between >>the toy assignments you handed out earlier and the real stuff they will see >>during employment. >If this is what your "experience" has taught you, then it is a sad commentary >on the state of things in the "real world". Perhaps some of the conditions >you are trying to simulate are a source of its problems. My experience tells me that there are big problems that one person can't possibly solve. There are medium problems that are huge amounts of work, and there are small problems that are lots of work if you don't know which way is up. And then there are tiny problems which anyone can do. By the way, I mean self-discipline: discipline of thought. I do not mean to imply some kind of grade-school detention schtick. Nobody codes isolated tiny problems for pay, except TA's for first-year courses. The purpose of assigning tiny problems is to illustrate the use of particular language features. The purpose of the "vicious problem" proposed above is to illustrate that the tiny problems are toys, are purely illustrative, and have next to nothing to do with "real life". Tiny problems are the nails with which one builds a house. They are not the house. You will find only a few first year people who believe this, however. >The almost belligerent attitude recommended for the instructor-to-be >sends the message to students that "the real world is cold, heartless, >loathe to communicate and cooperate." Sure, there are plenty of places >where this is true, but rather than teaching software engineering as >a "discipline" or a set of survival skills, why not demonstrate the >positive value of communication and cooperation? Unless you think they >don't really have a positive value? Co-operation on tiny technical problems serves no value whatsoever. Such problems are so small that it makes sense for only one person to solve them. What does co-operation buy you? In a group of N people, it's 1 worker and N-1 people watching. This teaches the value of sponging. Believe me, I know full well the value of sponging, and in the many group projects I did while an undergrad, in all but one I did most of the work, and in 1 I did the least. I felt just as bad not having done enough as having done too much. In some projects, there was too much work for one, and in other projects there wasn't, and in the latter projects, groups were inappropriate. The nasty problem should show that a disciplined approach will reap tremendous rewards. It should show that ad hoc techniques will get you there slowly or not at all. It will show that writing little programs is not like writing big ones. It will show that software engineering IS a discipline, just like any other engineering. The problem being that its principles are not clear. I believe it is CRIME to let people off easy and to expect little of them in University. What the hell IS a degree, anyway? To me, it is preparation. It should not just be the reward of being a middle-class son or daughter. University is a place where people fail. It's where you can find whether or not you have what it takes. It hopefully should show the value of HARD WORK. (Sorry, I'm getting out of hand here). Of course, real life does all these things too, but real life tends to lack guidance or standards. >If you want to simulate the real world to teach software engineering, >then have a two-semester, full-time course, where students are taking >nothing but your course. The high degree of commitment to a course that the >disciplinarians require (approximating an employee's commitment to his >employer) is not possible when students are also involved in other >courses. The problem was vicious because of the amount of thought required to solve it completely and correctly. I suppose that I must back down on some of my original statements above, in particular, the bit about the instructor not being able to solve it in the time allotted. That statement implies very large code volume. I suppose the guide should be that the student should be able to solve the problem fairly easily by the end of first year, given less than a week of 4-hour days. But my main message is this: Don't let University students delude themselves into thinking that University problems are the same as real ones. Even the vicious problem is ultimately a toy. Never let them have the chance to whine "but it was never like this at U of X". They will already know this, and they will be ready for it. As for the perfectly valid point that a "disciplinarian" course requires time, it's important tell students in advance that there will be a large time commitment at one point in the term. Requiring this commitment for the entire term is out of line, which is why there is ONE vicious problem, not 4. >Harry S. Delugach University of Virginia, Dept. of Computer Science Somebody else mentioned that as an adult student, he didn't like the concept of mind games, because he already knew what real life was about. Well true, but clearly some of the tactics mentioned in my previous posting were to motivate young folks who might feel otherwise disinclined to bother. Such stuff is probably inappropriate with people over 25 in a classroom setting, simply because such students will do what you ask, and will believe it when you tell them that the toy problems are toys. The vicious problem supplies a young person the proof that s/he no doubt desires. If you tell them that the problems they have done to date are toys, and they have done them with some struggle, they won't believe how hard real stuff can be. The vicious problem shows them. -- Chris Shaw cdshaw@alberta.UUCP (via watmath, ihnp4 or ubc-vision) University of Alberta CatchPhrase: Bogus as HELL !
mjl@ritcv.UUCP (Mike Lutz) (04/12/88)
In article <1204@pembina.UUCP> cdshaw@pembina.UUCP (Chris Shaw) writes: >Somebody else mentioned that as an adult student, he didn't like the concept >of mind games, because he already knew what real life was about. Well true, >but clearly some of the tactics mentioned in my previous posting were to >motivate young folks who might feel otherwise disinclined to bother. Such >stuff is probably inappropriate with people over 25 in a classroom setting, >simply because such students will do what you ask, and will believe it when >you tell them that the toy problems are toys. While this is generally true, like all generalizations it is subject to failure when circumstances skew the population being served. We ran a program for a local firm that was trying to retrain some of their existing engineering staff (mainly EE's and ME's) so that they could more effectively participate in the "new world" of software development. Those who did particularly well were to be considered for entry into our M.S. program (with lots of prerequisites to make up, to be sure). Our experience was that these "professionals" were more resistant to the s/w engineering concepts than any freshman class. They made your run-of-the-mill high school hacker look like Dijkstra, and they were proud of it. Needless to say, few made it into the formal program. Now, of course, the skill and interest distribution was *highly* skewed, as the really top notch ME's and EE's at the firm were obviously not in the program. The point is, of course, that age is an indicator of maturity and discipline, but no guarantee. Mike Lutz -- Mike Lutz Rochester Institute of Technology, Rochester NY UUCP: {rutgers,cornell}!rochester!ritcv!mjl INTERNET: mjl%rit@relay.cs.net