[KLUG Advocacy] (no subject)

[Robert G. Brown]

On 01 Jan 2003 00:49:19 EST, Dirk Bartley <bartleyd2@chartermi.net> wrote:
....
>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.  UML class diagram? 
>I suppose this is some sort of class inheritance diagram.  Don't know
>what UML stands for.  Object inheritence:  Thank you "Learn C++ in 21
>Days" or whatever that book was.  Thread and process:  Processes can be
>spawned and threads can be compiled in.  That's the best I can do
there.  Constraints in relational databases: mostly from experiences and
>what I can remember form your database presentation.

The above indicates a superficial knowledge and understanding of these
topics, but also a realization about their potential. That's an important 
step, because it acts as a motivator for learning more about these topics. 
Superficial knowledge and appreciation of a topic are natural steps toward
deeper knowledge, familiarity, and focus on a particular specialty.

I'll take one example, that of inheritance. You're not going to gain a 
lot of insight into this topic through anything like "Learn C++ in 21 
Days", although careful reading and experimentation will show you some
of this stuff. You'll know how to do it in C++, and you may be able
to write some interesting code, but in my view, you're not going to 
really see the value of OO this way. There are compelling reasons for
this.

C++ does not require deep adoption of OO methodologies or concepts, and
most language manuals (reference or tutorial) don't give primacy to
OO. There's too much underbrush, too many of the things that Stroustrup
would tell you are there to make "A better C", and not enough inbuilt
support for stuff that OO really demands, as a discipline. Don't get
me wrong, I'm not knocking C++ (in THIS discussion :). If you want to
write some practical code that uses some aspects of OO, C++ is OK as a
language, but if you want real insight into OO with an eye toward seeing 
what's REALLY going on, there are far better places to start.

>....if there is more than one way to skin the cat it's OK with me. 
Actually, this is a very old argument in the computer industry. How
many catskinners do you want, or need? What's the "right" answer 4? 
11? 40? As many as there are developers?  There's no good, single 
answer here, except that we probably don't want TOO many, and that 1 
is probably too few. There may be different right answers at different
times in the life-cycle of the product.

>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.
Yes, in some sense, you are. Perhaps we need to define "deviance" a little 
more clearly, and it also reveals another issue.

Tests can easily enforce standards, even if we don't intend them to do 
so. If I write a test so that I only accept ifconfig as an answer, then
I am in effect stating that you must reply with that to pass muster as 
a recognized worker in the field. In effect, the answers are a series of
passwords for becoming credentialed in the field. If it's always fairly
easy to pick up some other approach to doing something, then it's also
easy to adopt something that is not acceptable as a test answer, and
you're going to get more "deviants" in this environment.

If I'm more interested in determining your understanding of principles,
I may write the test so that a variety of answers is acceptable to a 
question where ifconfig is an answer. I'm allowing you to express your 
understanding in any number of ways, but I'm also implicitly stating that
any of these ways are acceptable means of communicating those ideas in
practice. There aren't any (or many) cases of "deviants" in this kind
of community.

In effect, testers make some interesting choices. Do we end up with a
discipline that speaks a highly uniform language, and may have some 
blind spots because of uniformity, or do we prefer a community of
somewhat freer speakers, with fewer standards, but perhaps fewer
blind spots? I'm simplifying, this topic may deserve its own thread.

>....It's not always what you know, it's your ability to learn.
Preach it from da hills, Brothah! This is the CRITICAL ABILITY in this 
business. We all have to learn some technology or another, and all of
them have life-cycles. As the life-cycle winds down, we have critical
choices to make... pick up an emerging technology? Change career path?
Buy time by moving to a place that uses our strong technology, but is
earlier in the life-cycle? Something else?

>...More important were abilities to adapt socially...
Something the system does NOT teach; but does offer some opportunities
to cultivate, in an insufficient, informal way. Even so, the system 
manages to sort out the better ones from the the others in this regard.

>...I feel a degree is mostly just a way for society to put a "This 
>person can learn" sticker on you.
That's about right; ability to attain a degree ought to contain an
element of this. Surely more advanced degrees have this as a REQUIREMENT.
In a formal sense, a PhD is evidence of some original contribution to
the field of study; the person has not only learned the field, but has
mastered it to the point of contributing something original and non-
trivial.

>The only thing I can't understand is the difference between 119 credits
>which is unacceptable to employers and 120 that is because it comes with
>a piece of scratch pad paper.  (So this means it's the employers I have
>trouble understanding.)
Employers (actually, most organizations) are credential-oriented. They
want some evidence that an individual has "made the grade", meets some
minimum standard or requirement. There are plenty of reasons for this,
two of the clearest and simplest are that since management is not going
to be capable of determining who is good enough to do the job, they want
some indication of such from an authoritative source, and there is a 
need to show that due diligence has been practiced in staffing the organ-
ization with competent people.

>The other thing that has been missing from this thread is discussing how
>Information systems relates to a businesses ability to make money.
IMO this is another thread in the rope for sure, but I feel the entire
rope is predicated on the notion that a disciplined, scalable set of 
systems to handle information is the lifeblood of any business, and most
organizations.

>Who cares about being able to describe object inheritance if the business
>software your business uses to run is written in some form of BASIC. 
Because the stuff is only implemented in BASIC this week, and OO is not
merely a way to program, but a way to think about dealing with information
in a systematic, scalable way. Next week, next year, it's going to get
implemented again, and visualizing the interfaces between the new system 
and others, as well as how the new system is designed, is going to benefit
from OO disciplines, regardless of the language being used to implement 
the new system.

>Information systems is about making businesses run more efficiently and
>that is done by business information management.
Sometimes it is. It is often the difference between doing and NOT DOING
business. This is something a lot of people in business are only starting
to understand. I'm not talking about merely competitive pressure (although 
that's important; I'm going to beat you in the marketplace if I have fewer 
costs to pass along, since I am more efficient), but that automating and 
scaling the handling of information will change the kind of business I can 
do, and provide me with new opportunities. I'll give some examples if
you like.

>...my inability to compare and contrasts threads has absolutely no 
>bearing...If it does please explain why and I'll try to prioritize
>learning yet another topic.
Let's go forward 5 years. You've become a manager, in charge of making
buying decisions for the IT segment of your employers organization.
The purchase of one product over another may well rely on the technical
details, such as the differences between threading or some other tech-
nology detail (like what OS they require, or run on). Are you able to 
make good decisions in this area?

Yes, that way lies madness. Someone in such a position can't know 
every detail of every technology. However, it does help to be able to 
goad subordinates, often by asking the right questions, and not be
buffaloes by salesmen and aggressive software marketing types. So SOME
familiarity is important, and more quality at this level is better.

>These important interactions between businesses and their information 
>can be learned best on the job or through internships.
They can be; it doesn't mean they are. IMO Internships are valuable for
a number of reasons, this among them. This cries out for a good mentor.

>Learning is not the result of the activity of teachers, learning is the
>result of the activity of the learners.
**VERY** important point, and well stated. 

>Teachers are just there to keep the learners between the "lines" and 
>inspire.  
I hope so, if true, it's indicative of a very good class! Instructors
on this thread, please confirm or deny. As an instructor, I confirm 
this.

>Sorry for Rambling
That's OK, we need more "ramblers" like you! :)

						Regards and HNY,
						---> RGB <---