Re: Any research putting c above ada?

[clines@delete_this.airmail.net (Kevin Cline)]

>> >Which, I think most people will agree, is the main goal of most people going
>> >to college.  College is not about learning, it's about jumping through all
>> >the right hoops and writing down what the profs want to see.
>> 
>> I don't recommend anyone with this attitude, because we need adults with
>> problem solving skills, not juvenile grade-grubbers.  A low GPA will make it
>> harder for you to get an interview, but a high GPA is no guarantee of a job.
>> We just turned down an MSCS graduate with a 3.5+ GPA, because the candidate
>> couldn't demonstrate any understanding of the coursework.
>
Roy Grimm <ragrimm@cca.rockwell.com> wrote:

>I'd have to disagree with your judgement of this "grade-grubbing"
>attitude.  I am a perfect example of someone who had a "less than
>stellar" academic career (graduated with less than a 3.0 GPA) but had
>plenty of opportunity to demonstrate I have real problem solving
>skills.  (I was on a team for an ACM programming contest and finished
>two programs myself while the other two members each finished one.  That
>made our team one of less than one hundred, out of more than a thousand
>nation wide, that finished at least 4 out of the 6 programs in the time
>allotted.  A significan percentage of teams didn't even finish one.)

You didn't read my post carefully enough, and evidently "grade-grubber" isn't
well understood either.  I just said that a low GPA makes it harder to get an
interview.  I then indicated that it played little or no part in my evaluation
of a candidate.  A grade grubber is a student interested in expending the
minimum possible effort to obtain a desired grade, with no interest in
mastering the subject.
>
>At a homecoming a few years later, I found out that a few people in my
>class who had graduated with a 4.0 in comp sci were having trouble in
>their jobs maintaining COBOL code for accounting/insurance type
>companies becasue they didn't know how to apply their theory to real
>world situations.
>

The probably didn't understand the theory either, but were able to memorize
enough bullet points to pass the exams.  This reflects poorly on your
instution.

>> > Anyone who doesn't
>> >believe that has probably never pointed out a design error to a prof in
>> >class. Granted this is worst case but in my (and many of my associates
>> >and friends) experience this is the way many profs work.
>> 
>> That is truly unfortunate.  However, with industry salaries for top-notch
>> experienced professionals in six figures now, it is hard to get good
>> instruction for $100/credit hour.  If you do, be grateful; it's charity.
>
>Grateful?  Charity?  Hell, I demand it be good instruction, whatever the
>price.

You can demand all you want, but if you pay a government-regulated
below-market price, there will be a shortage.

>
>> > I did have a few, maybe 5, profs who were able to teach and encouraged us.
>> 
>> Five!  That's not so bad.  I hope you learned everything you could from them,
>> and took all possible steps to complain about the rest.
>
>When they have tenure, complaining does nothing but get you chastized...
>
>> >We will always need people in academia to do research, but at the same
>> >time someone has to know how to go out and engineer solutions to real
>> >world problems. After all, someone has to keep the planes in the air.
>> 
>> Which is hard to do with no understanding of fundamental data structures and
>> algorithms.
>
>But you can teach the fundamentals in a few weeks, rather than in the
>two semesters they currently waste.  

I disagree strongly.  Obviously we disagree on how much knowledge is relevant.

>If students spent more time learning how to solve real problems, they would be able to pick up the
>theory much faster.  

I don't believe this at all.  I have known many experienced developers who
wrote ridiculously inefficient software because of a complete lack of
knowledge of operating system services, the language they were using, and
fundamental data structures.

>They would see a problem and ask the intelligent
>questions about how to solve it.  At that point, you can show them the
>theory and how it applies in that case.  

"Experience is a dear teacher, but fools will learn at no other."

I think this would be painfully slow.


>Instead, the instructors show
>students the theory, spend a long time making sure people understand the
>theory and move on to the next one.  Almost no time is spent applying
>the theory to anything more than very focused, contrived example
>problems that are easy to grade.
>
>> >I have long thought that we need to have a degree in the field of
>> >Software Engineering for those who want to learn how to apply SW
>> >technology to the real world.
>> 
>> There are many schools that have more practical programs.
>> But I believe that some knowledge of CS theory is required to work
>> effectively on new applications.  I do not recommend candidates who are
>> unable to demonstrate some knowledge of CS theory.
>
>I would go a step farther and demand that they be able to demonstrate
>the ability to _apply_ that theory.  Unless, of course, they were only
>doing theoretical work...
>
>> >CS could be free to remain dedicated to
>> >doing the pure research that so many of the profs love. It would also
>> >give students more freedom to chose their career direction.
>> 
>> Few undergraduates know enough to choose their career direction.
>> But a good understanding of CS opens the most doors, and leads to the most
>> rewarding careers.
>
>Ah, but good understanding of engineering coupled with computer science
>would not only open the door but get you all the way inside and down the
>hall a ways...
>
>> >CS covers many great things, but solving design problems is not one of
>> >them (at least in my experience).
>> 
>> There is not enough time in an undergraduate cirriculum to teach SW
>> engineering judgment.
>
>Horse Hockey!
>
>How would software engineering be any different than any other
>discipline?  Do they not teach engineering judgement to the other
>engineering disciplines?  

Engineering judgement involves combining off-the-shelf and custom-built
components to solve a particular problem in a cost-effective manner. The
number of available software components is enormous, and changing rapidly,
perhaps more rapidly than any other field of endeavor.  Understanding the
usefulness of the various tools applicable to any particular development shop
takes at least a year of full-time work.  Without that experience, it's very
hard to maek correct build/buy decisions.  It's also hard to predict the
likely requirements changes to determine where to spend extra resources for
maximum flexibility.

>> But there are plenty of excellent books on the subject. I suggest you try to
>> read one technical book a month.  Soon you will be well ahead of your
>> classmates.
>
>Sure.  If you are one of the 5% of students who are able to comprehend
>technical manuals, that's good advice.  What about for the rest of them?
>

I feel that the ability to learn from written material is essential to staying
on top of this profession.  Even if it is harder for you than some others, you
must do it anyway.  Otherwise your skills will become more and more
specialized, and you have little value to any company except your current
employer.  There are thousands of 50-year-old engineers  RIF'd out of
high-paying positions who ended up taking jobs for half their former salary.
Don't let it happen to you.  Know where your paycheck comes from.
Make sure you are contributing value equal to your cost.