Skeeve's tale of woe (Re: [LINK] MCSE tale of woe) illustrates a pattern
I think has long existed an academia where practical, rigorous,
engineering subjects are taught. I wrote about this a few years ago on
Link, I think.
The people who run the institutions have to hire teaching staff, but
they have no idea how to tell whether the potential teacher has genuine
expertise about the subject they will teach - except by referring to
paper qualifications.
Some people who are vitally interested in a rich, deep, important,
ever-growing and demanding field often couldn't be bothered with paper
qualifications. There are exceptions, such as in medicine, where you
rightly have to have the qualifications before being able to practice.
It is too often true that those who can't do, teach. Furthermore, those
who can't do, or who don't even really understand the field, are often
tempted to get paper qualifications as a job ticket.
Quite a few people have no innate capacity for understanding anything of
genuine engineering complexity. They may not even appreciate what it is
they don't know about engineering, so they may consider themselves
qualified and useful if they pass the various formal tests. They may
be good with word associations, playing the academic game etc. but those
skills are useless when confronted with a complex and unknown situation,
which must be resolved using high level debugging skills and with a
great deal of knowledge of the many technologies and human factors in
the situation at hand.
There seems to be a self-perpetuating cycle of people with paper
qualifications being less likely to possess the real knowledge of the
field for which they are supposedly qualified.
These people with paper qualifications are hired to run the courses, set
the exam questions and therefore control many factors which determine
who will be the next generation of paper-qualified people, what of value
they will know, and what they will think they know.
I once encountered a fully academically qualified electronics engineer
who did not know the resistor colour code. This is like a computer
engineer who can't instantly tell you that 0011 1110 is 3E in hex or
that 0D 0A is a newline for Windows machines.
Real skills with complex technologies are hard to teach, hard to provide
a genuine learning environment for, and hard to examine. It may be
easier with software, web design etc. But electronic hardware and real
live computer administration presents many challenges to the educator.
I used to work at a TAFE college 20 years ago. There were a few really
keen teachers who were dedicated to making the best of things for
students, with as much hands-on experience, building and debugging
electronic systems as possible. Most of those teachers wouldn't cut it
as a technician - but they were training people to be electronic
technicians. None of them had any real-life work experience in
electronics. (The electrical trade section was entirely different - all
the teachers there were sparkies from way-back, and they did great work
training apprentices.)
One of the technician teachers asked me why I squirted water onto the
cleaning sponge of a soldering iron. Clearly, he had never used a
soldering iron properly. Another asked me to check the calibration of a
new oscilloscope. "What sort of errors does it have?" I asked, thinking
perhaps he was being fussy about one or two percent. He replies that
some channels seemed to be out by a factor of ten. He had never heard
of oscilloscope leads with x10 attentuators built into them - as
virtually all oscilloscopes have. These same teachers would be leading
a class of calculator-pressing young men (and sometimes an intrepid
young woman) through phase diagrams, AC and DC equivalent circuits, real
and imaginary currents, Norton and Thevenin equivalents etc. etc. (as
per the exam requirements) yet if I had walked in with a BC108
transistor (a common or garden transistor) virtually none of the
teachers would know it was an NPN, have any real idea of its maximum
voltage and range of beta (current gain) or be able to tell me which
leads with emitter, collector or base. The same goes for most of the
students - with the exception of those students who had an at-home
interest in electronics.
None of this high-level mathematical stuff is any use at all unless you
have a hands-on physical-feel understanding of electronics. Design
without long experience repairing equipment is madness. Many design
issues are not related to things which can be expressed mathematically.
So much depends on "common sense", physical robustness, serviceability,
thermal design, resistance to dust and vibration etc.
It takes years of genuine work experience to develop the debugging and
general knowledge skills to be a decent technician. (I don't care for
the "technician/engineer" "officer/grunt" distinction at all.) I don't
see how those skills can be acquired in an academic course alone - and
most courses do emphasise the importance of work experience.
Since academia is often poorly paid compared to those who really know
their stuff, especially in IT (there was a phrase like "gold collar
workers" or similar), why would anyone with genuine expertise become a
teacher? Few do - but there are people who like the social contact of
teaching, the different working environment, and who have both a passion
and an aptitude for inspiring and helping people to learn. But even
then, they have to teach by someone else's syllabus - probably the work
of a paper-qualified committee. As teachers, their main task is to help
students pass the exams, not to help them really learn what they need to
be useful in the real world. The teacher's performance, for official
purposes, will be judged on their student retention and pass rates, not
on how well those students actually perform in the real world in the
years and decades to follow. Full time teaching typically means that
they do not get to extend their skills or remain up-to-date with
changing technology.
I think it is really difficult to reliably test people's real skills in
electronics, computing etc. So much of electronic and computing work
involves debugging really tricky situations that it is impractical to
set up such situations in an exam situation. Even for a skilled
person, the time to resolution may vary enormously due to perfectly
sensible decisions about what path to pursue first. Resolution may
take much more time than would be suitable for an exam. Also,
resolution involves access to web sites, discussions with colleagues,
discussions with the people who run the system etc. It involves
personal skills and a well developed capacity to look beyond the
purported problem space into other related matters. For instance,
the customer may report a problem in some specific way, but the real
problem may lie in other equipment, in their usage of this or other
equipment or in their faulty expectations and understanding etc.
Many problems are intermittent. I once had a DX7 musical synthesiser
which crashed and clobbered its battery backed up memory - but *only*
when first turned on after being not used for a week! Eventually, by
good fortune, the problem became more prevalent and I was able to use
heat to prove it was one custom LSI chip, which must have had a faulty
pin driver which was corrupting the data bus when first turned on.
That resolution took a month!
You can see the results of paper-qualified people being isolated from
the real world in the many security vulnerabilities found in Microsoft
software. When Outlook (Express) hands an HTML email to MSIE, and MSIE
finds an attachment with a mime type indicating it is for Media Player,
and Media Player looks at the file and decides it is not the right type,
and then hands it to some other thing which decides it is an executable,
and very helpfully *runs* it, then you know that this whole system was
put together ("designed" seems too strong a term) by people who had not
the first clue about security.
Another problem is the vastly expanding need for technical expertise.
In the early to mid 20th century people with a technical electronic bent
did "radio". Then it became electronics. Then computers and software
was developed. Now we have various aspects of electronics, programming,
system administration, computer building and repair, web site design,
database management etc. Each of these fields keeps growing more and
more complex, and being useful in one field often means having a working
knowledge of several others. Yet there is a constant supply of people
with minds which can *really* do this stuff well.
I think that the increasing complexity of everyday things acts as
a real impediment to anyone wanting to learn many aspects of
technology.
My first electronic devices were things such as a 1940 Mullard valve
radio. With a little theory, it was perfectly possible to understand
the whole thing without a schematic. Even without a databook, you could
see what the valves were (rectifier, beam power tetrodes, pentagrids,
pentodes etc.) and see their pin connections. Then you could draw the
circuit in an afternoon, and with a multimeter and perhaps an
oscilloscope you could fix faults and modify it.
Now, with LSI chips, surface mount etc. etc. most everyday items are not
at all amenable to understanding, debugging, repair or modification.
Also, I think the educational system has been run by humanities types
and an increasing proportion of women, who generally have no
understanding of or interest in engineering. There was even a fashion
against science and engineering at one stage - as if these were the
roots of war, power elites and environmental destruction and so should
be avoided.
I don't know any teenagers now who are anything like as advanced in
electronic understanding as I and my radio club colleagues were. (The
Camberwell Grammar Radio Club no longer exists - we used to do all sorts
of things there, including ballistics research and 40 metre amateur
radio.) Some young people in their late teenage years may be getting
into computer programming - which when I was 14 meant hand-punching
cards in a cut-down version of Fortran, to be transported to Monash
University and run on the Control Data 3200 and returned with a
print-out a week later!
But even in computer programming there are pervasive problems. There is
a generally low standard of documentation of the code inside the source
files - which I put down to it being done mainly by young men under the
influence of young warrior/hunter instincts, which have them strut their
stuff, showing what they can do, but not giving anyone any clues at all
about how they do it. This is a field where some more feminine, English
sentence, communicative aspects of humanity are sorely needed! Another
possible factor in the too-terse, badly expressed, badly laid out or
non-existent comments is that it takes up too much space in printed
books, which constitute a guide for many programmers.
There are a number of vicious circles at work here, including:
1 - Increasing complexity and pervasiveness of an increasing number
of technologies while there is a finite number of people with the
mental makeup, skills and passions to do it properly.
2 - Widely deployed systems written in lousy ways (Microsoft, for
instance) firstly setting low standards by which others are
judged and secondly requiring vast armies of people to mollycoddle
the second-rate systems into working as desired.
3 - The vicious circle of academics being chosen only by paper
qualifications, of there being many reasons why good technical
people do not become teachers etc.
4 - Many people with good technical skills being hobbled by their own
lack of human communication skills, including their inability or
unwillingness to clearly document their work for the next poor
sod who tries to understand it, which will probably be themselves.
So, when debugging or extending the software, they spend
excessive time trying to understand what was in the original
worker's mind (probably themselves) rather than using that knowledge
from good documentation and therefore going straight into the fray
fully informed.
5 - Complexities of everyday electronic items being not at all conducive
to teaching or understanding by beginners. Compare a PC or video
game, to a crystal set or superhet radio.
6 - Pervasive and generalised factors mitigating against patience and
long attention spans, including massive exposure to TV and
video games, and also potentially problems with nutrition,
mercury in vaccines (http://www.autism-mercury.com) etc. which makes
many people too scattered and impatient to spend years learning
something difficult like electronics or computer programming.
I just got an email from a journalist friend. The company she works
has ten or twenty staff or so. She regularly uses free web-mail and
personal email accounts, because of unreliability of the office email.
She just wrote to me that she has had no email on the office system for
two weeks, and virtually none for the two weeks before that. She also
wrote that some co-workers can't access their hard drives. I don't
have to mention which company's software is involved in this - and how
most of the trouble seems to have arisen due to the Klez worm which
relies on this company's software's well-known vulnerabilities.
Complexity, when badly done, turns into a terrible mess.
- Robin
----------
For Link list information see http://sunsite.anu.edu.au/link/
This archive was generated by hypermail 2.1.1 : Sun Jun 30 2002 - 03:10:03 EST