[KLUG Advocacy] Let's get this CS v. CIS v. moron v. other party started -- WAS: Oh, the joys of upgrading!

Adam Williams advocacy@kalamazoolinux.org
Thu, 2 Jan 2003 10:03:00 -0500 (EST)


>>It is the complete lack of clue about things like version control that bug 
>>me. Not that they don't know how to use CVS, but that they don't get it, 
>>even the "why".
>The why is more tolerable then the care why.

So true.

>>And having to explain to a CIS person how to read a basic UML class
>>diagram?  And object inheritence in OO?  The difference between a thread and a
>>process?  Constraints in relation databases (or even what the "relational" part
>>of that description means)?  Seriously, why not just grab a high-school graduate
>>and teach him what he needs to know,  your going to be doing it anyway, and
>>he'll do it for less money and with less attitude.
>This is coming from the double E that hated my engineering job and
>decided to move into the information systems field.

Right, so if you don't know a few things thats understandable.  But you 
learn.  Someone graduating with a 4+ year degree damn well oughta know 
such things.  I learned such things on my own because (a) I have had very 
little formal education and (b) that which I had didn't teach me what I 
needed to know.

>CVS: Learned that it existed and the why from you and learned to use it
>from your and other documentation.  Use it on a daily basis now.  It is
>beyond wonderfully important to the work I do now.  

Glad to help.

>UML class diagram? 

UML is an industry standard way to diagram the relationships between 
entities, with things like use-case, etc...  Very much like s standard 
entity relationship diagram, only for anything.  Lots of people don't know 
UML, I only know some.  But a CIS graduate dawm well should!  One can 
create a UML diagram that easily expresses what it would take dozens on 
pages of "prose" documentation to do. 

>I suppose this is some sort of class inheritance diagram.  Don't 
>know what UML stands for.  

Universal or Unified Modelling Language

>Object inheritence:  Thank you "Learn C++ in 21
>Days" or whatever that book was.  

That sort of covers OO ideas.  But OO ideas are helpful for even 
scripting, certainly for PHP, etc...  And even applications such as mail 
servers and the like are starting to use it.  It has nothing really to do 
with programming,  it is a way of thinking about data.   Even in 
programming OO is language independent.  GNOME is all written in C, which 
is not an OO language, but is entirely object oriented.  The result is 
even a person with crappy C skill can read down through a page of code 
from some uber-app like GNOME Meeting and say "Ha. Yep. Ok...." becuase 
you have at least a general sense of what it is doing.  Responsibility for 
various thinks (text,fonts, internationalization) are broken up into 
operational containers, etc... This is a good way to think of systems 
from a single app up to an entire enterprise. 

>processes are spawned and threads can be compiled in.  
>That's the best I can do there.  

But I could explain the significant differneces to you in about five 
minutes (because of other stuff you know).  You'd immediately realize how 
important the distinction is for things like performance.  A CIS graduate 
oughta just know.  And this isn't about programming.  OpenLDAP has a 
configuration directive called "threads",  which one can't really use 
unless one knows what a thread is.

>So I understand some of these things but not all.  In the net use
>example, if there is more than one way to skin the cat it's OK with me. 
>If a test asks how to get the ip address from my system and the accepted
>answer is ifconfig and I put ip addr show, I'm a deviant, right.

I think that would be far to simplistic of a question to really learn 
anything about about a students competence.  It doesn't touch on the 
theory.  Better would be "Given interfaces ... and a routing table ..., 
what interface would a packet with a destination address of x.y.z.1 be 
routed through."

>Let me get back to the point here -> It's not always what you know, it's
>your ability to learn.  My engineering degree's information did not help

Right,  but learning is built on top of learning.  A degree is supposed 
(at least as I understand it) imply that a strong foundation of learning 
has been laid.  That way the employee can begin to acquire site specific 
skill almost immediately, and "we" don't have to rehash the fundamentals.

>me in my engineering work much, but the ability to learn did.  More
>important were abilities to adapt socially to customers, supervisors,
>peers, customers, purchasing agents, presidents, customers .... (did I
>mention those annoying customers).  I feel a degree is mostly just a way
>for society to put a "This person can learn" sticker on you.

It should be,  unfortunately I don't feel that it is.

>The other thing that has been missing from this thread is discussing how
>Information systems relates to a businesses ability to make money.  Who

Usually accounting classes, etc... are required in a course.  They were 
for me.

>cares about being able to describe object inheritance if the business
>software your business uses to run is written in some form of BASIC. 
>Information systems is about making businesses run more efficiently and
>that is done by business information management.  (Of which my inability
>to compare and contrasts threads has absolutely no bearing on.  If it

Threads/proccesses might matter if you needed more performance but had a 
budget of $0.00.  That relates to efficiency.

>does please explain why and I'll try to prioritize learning yet another
>topic.)  These important interactions between businesses and their
>information can be learned best on the job or through internships.

Right, site specific, or possibly industry specific information.  But this 
can be learned much more quickly if a strong foundation of general 
understanding already exists.

>Learning is not the result of the activity of teachers, learning is the
>result of the activity of the learners.  I just like the statement and
>it may fit in this thread somewhere if not here.  Teachers are just
>there to keep the learners between the "lines" and inspire.  The lines
>are the requirements of the course.  Inspiration is a tough nut to
>crack.

I agree.  Mostly I think this is a discussion of there the "lines" should 
be,  and possibly why their position isn't more obvious to those of us 
watching learners come out of the gate.