Is There a Tech Staff Shortage?

Is There a Tech Staff Shortage?
Melvyn D. Magree
Originally published in
the Northland Reader
now the
Reader Weekly
October 14, 1999

Minnesota needs information workers (Star Tribune, August 25, 1999)

"Twin Cities metro area must solve its shortage of skilled workers." (Star Tribune, March 30, 1999)

"In a continuing effort to tackle the labor shortage conundrum, the Minnesota High Tech Association (MHTA) said ... it will spend $300,000 on an initiative to attract and train workers for the fast growing tech industry."  (Star Tribune, March 5, 1999)

From my own unsuccessful search for a programming or other computer-related job, I have found that the shortage is self-induced.

The first cause is the selection process by employers.  They either scan resumés for certain keywords or have applicants fill out "skill" sheets with similar keywords.  Almost all of these keywords are the names of products: software applications or computers.  A very few are the names of concepts like client-server or object-oriented programming.

If the applicants don't have the right keywords in their resumés or don't check off the right items in the skill sheet, they are passed over.

Employers are not interested in the types of work that applicants have done.  Employers are not interested if applicants have used a spreadsheet, a database, or a word processing program.  Employers want to know if applicants have used Excel, Access, or Word.  Employers ignore that knowledge of one product is easily transferable to similar products.

A letter writer to the San Jose Mercury News complained that employers are not interested in technical writers.  Employers are interested in technical writers who can use Frame Maker.  He went on to say that any computer-literate writer can learn to use Frame Maker in a couple of weeks and even be using it productively the first day.  (Letters to the Editor, San Jose Mercury News. January 24, 1998).

For programmers the situation is worse.  Employers are not interested in the kinds of programming applicants have done.  Employers are not interested if applicants have used object-oriented languages or visual compilers.  Employers want to know if applicants have used Java or Visual Basic.  Employers ignore that programming skills are easily transferable to similar products.

Another letter writer complained that employers aren't interested in the range of experience an applicant may have.  Employers are interested in programmers that have at least six-months' experience in Java.  He went on to say that he has used languages far harder than Java and he could be up to speed in Java well before he was up to speed in the business of the company.  (ibid.)

Yet another letter writer gave the simile that employers are looking for white eggs in green boxes.  There are brown eggs in purple boxes, so they say there are no eggs.  (ibid.)

It is as if anyone who has driven a Chevrolet for the last five years is not allowed to drive a Ford.  Or as if anyone who has driven only four-door compact sedans for the last twenty years is not allowed to drive a pickup truck or heaven forbid, an 18,000 pound moving truck.  Fortunately, the state and rental companies are more lenient than many employers; anyone with a valid driver's license may drive any of these vehicles.

My own experience includes many years of learning, adapting to, and promoting new computer technology.  Oh yes, I've also ignored a few ideas that really took off.  In general, when I've had a need to know, I've plunged in and tried a product, generally by skimming the manual and then going back for details.  I think I've had only one formal course, "Advanced Programming Techniques" in graduate school.

I started in programming with a summer job between my junior and senior years of college.  I took the job to learn computer programming, but I was assigned clerical work instead.  Halfway through the summer, I borrowed Elliot Organick's Programming the IBM 650 from the company library.  I  wrote a program in assembly language to calculate square roots and presented it to my supervisor.  He didn't know what to do with the program and passed it on to another department.  Shortly thereafter I was assigned to write a simple program to show how well dealers had met their quotas.  With a few questions to others, I completed the program by the end of the summer, handing in the documentation on my last day.

The next summer I started as a graduate assistant at the computer center of Case Institute of Technology.  The graduate assistants' first assignment was to learn ALGOL on the Burroughs 2000 so that we could help sophomores in the computer lab in the fall.  We were handed the ALGOL manual and pointed to the computer.  We had a ball!

Two and a half years later I started my first full-time corporate job at Remington Rand Univac (now Unisys).  From manuals and fellow employees I learned to use the assembler for the Univac 1107 and a rather arcane operating system.

Within a few months I was assigned to maintain a FORTRAN compiler and its runtime system.  None of us in the group had programmed FORTRAN before, but we learned quickly.  Our supervisor, who was the brightest of the bunch, never bothered to learn FORTRAN, but he came to know the inside of the compiler almost as well as the original designer did!

Later I was assigned to maintain an ALGOL compiler with a strange add-on called SIMULA.  SIMULA wasn't called object-oriented then, but it certainly added a powerful abstraction that solved more problems than simulating the behavior of real-life objects.  I thought SIMULA was the be-all and end-all of computer languages.  I fought a lonely battle for many years before the concept of object-oriented languages caught on.

Within a year or two I began contributing to the high-level design of the next operating system for the Univac 1108.  Eventually I was assigned as lead programmer to a group working on one part of the operating system.  None of us had any formal training on operating systems; we just read what we could and went ahead and did it.

After five years with Univac I transferred to Europe to support this operating system.  As part of living in Switzerland and then Italy I learned to read and speak German and Italian from books and practice; I had only a few informal tutoring sessions in Italian.

After two years in Italy I transferred to Sweden.  I learned to read and speak Swedish from books and practice with only a few informal tutoring sessions.  After one year in Sweden, I was appointed the supervisor of a technical support group.  Our daily language was Swedish.  I also taught a few classes and gave some presentations using Swedish.

One of my most interesting trouble shooting episodes occurred in Sweden.  One customer had system crashes in which a part of memory was overwritten.  Nothing was obvious to any of us from the memory dumps.  We sent a few back to the States but received no resolution.  The problem was raised to the level of a management meeting.

The attendees were Swedes, a Canadian, myself, and another American.  Most of the Swedes made introductory remarks in English, a couple did so in Swedish, the Canadian and the other American in English, and I in Swedish.  One of the Swedes exclaimed with a sigh, "Du talar svenska!" meaning "You speak Swedish!" with the unspoken meaning, "I won't have to try to speak English!"

We reached no conclusions in the meeting except that a certain program was frequently present.  The customer brushed that idea aside saying that the program didn't work.

I persisted in pursuing that program as a culprit in the crashes and finally received a copy.  When I took the program to another site, it crashed without harming the system.  The program was written in COBOL, of which I had only rudimentary knowledge from a book.  I was able to establish that the COBOL runtime system had an illegal memory reference which matched the pattern in the system crashes.

This story gets bizarre, but let me just say that I wrote a simple program that would make the same illegal memory reference.  I took it the site with the problem, it was run, and the system crashed.  Looking at the dump of the system, I showed that the memory protection circuit was not functioning.  The technicians later found that two wires were crossed in this circuit.  When they fixed the circuit, the offending program definitely "didn't work."

When I returned to the States after six years in Europe, I continued to learn and troubleshoot.  I learned more about telecommunications, databases, transactions systems, and recovery.  I sat in on design meetings on all of these concepts and did troubleshooting on some of them.  I managed a computing center.  I learned APL, BASIC, and Pascal.  I did design reviews and code reviews.  I never used a company derivative of JOVIAL, but in a code review I recognized that the programmer was abusing it by programming as in an assembler.

Eight years after returning from Europe and just about as many jobs within Univac, I joined the microcomputer revolution and founded my own company.  I learned a variety of now-orphan computers and the Macintosh, and I designed, implemented, and marketed seven products for them.  I learned object Pascal, HyperCard, and Prograph (a visual data flow compiler), and a few other development products that never got a big following.  I avoided C and the PC; why make work complicated when the computer can do it for me?

After fifteen years on my own of looking for the simple, elegant solutions that would become popular, I folded the company and made several attempts to find a full-time computing job.

Did you think that I described an impressive work history?  Think again.  I did not write in the traditional resumés style.  I wrote too much.  And I did not have many of the buzzwords that employers look for.  As I like to say, I don't have the right alphabet soup.  In fact, notice that my only reference to C and the PC were a bit derogatory, and I didn't even mention C++ or HTML.

I included this biography to demonstrate that a multi-faceted background is not desirable in today's over-specialized environment.  Employers want instant experts, not learners.  It is not just my loss but theirs.

One Twin Cities company had a "technology" fair.  One young programmer was demonstrating a project to be used by travel agents around the world.  He pointed out that the agents would be able to use their own languages.  I asked if they were using Unicode, the 18-bit character code that can provide for almost all known character sets.  He looked confused and said that I should speak to his manager.  His manager was initially enthusiastic but lost interest when he found I didn't have the right "alphabet soup" and that I didn't want to be explicit about which job title I was interested in.  I wonder if the Japanese travel agents using this system have to read and type Romanji.

I have long assumed that my difficulty in finding a computing job was only the narrow requirements of employers.  I sometimes suspected another problem, but brushed the notion aside.

Did you add up the years that I spent in these various activities and places?  It comes to thirty-seven years, which means I am well over fifty.

In researching this article, I discovered that the complaints of ageism in information technology are quite widespread.  According to some who have looked at this problem, "Unemployment among IS professionals over 50 is about 17%." (IT labor boom a mirage to some, ComputerWorld, August 10, 1998 [no longer available online])

These professionals are probably not unemployed according to labor statistics.  They have jobs such as Radio Shack manager, interior designer, or bus driver.  They just have difficulty finding jobs to match their experience.

Programmers over the age of 50 are not the only unemployed programmers; many in their 40's and even 30's have difficulty finding jobs.

James Wick, 62, feels lucky to be employed on the year 2000 problem.  Before he found that job, he had just about given up trying to convince recruiters nearly half his age that he had any worthwhile experience from a thirty-year career with several major corporations.  (Too Old to Write Code?, US News, March 16, 1998 [available in archive])

Alan Ezer took time off in his early 40's to go to graduate school.  When he reentered the job market, he trained himself in one of the "hot skills", Java.  He created a Web page showing his skills.  He selectively responded to 150 ads in which he thought there was a fit with his experience.  He received one interview in two years.  "Even though I had spelled out my background on my resumé, when they saw me, they decided I didn't have the work experience they required," Ezer says. (Too Experienced to Get a Job?, Wired, Feb. 25, 1998)

Ed Curry, 39, closed his software business and took a month off.  Two years later he had no permanent job, even though he is proficient in seven computer languages.  He said that recruiters told him that it would take too long to place him but that they could place an entry-level programmer immediately. (IT labor boom a mirage to some, ComputerWorld, August 10, 1998 [no longer available online])

A survey by the National Science Foundation and the Census Bureau found that 57 percent of computer science graduates were working as programmers after six years, 34 percent after 15 years, and 19 percent after 20 years.  Most would be in their early 40's after 20 years.  On the other hand, the figures for civil engineering graduates are 61 percent, 52 percent, and 52 percent.  (Norman Matloff, New York Times, January 26, 1998)

Norman Matloff is a widely published critic of technological hiring practices.  He has been called anti-immigrant because he questions the need to hire more foreign workers for technology jobs.  I found most of the information for this article with a web search on "Norman Matloff" which gave me given 300 references.  Just two of the first ten led to the list of articles that I cited in this article.  However, in the less than ten articles that have been published on the "tech staff shortage" problem in the Star Tribune in the last eighteen months, Matloff has been mentioned only once.  And views similar to his and of those whom from direct experience find the shortage non-existent have been mentioned just about as often.

The Star Tribune article on October 15th mentioned that Matloff had a web page but didn't give it.  It is http://heather.cs.ucdavis.edu/itaa.html.

I hope that the Star Tribune will probe this subject deeper in future articles.  If someone reports that the sky is falling, please determine if it is just an apple from a tree.

A couple of additional Web pages of interest are:
http://heather.cs.ucdavis.edu/pub/Immigration/ImmigAndComputerIndustry/SDUT.html
http://heather.cs.ucdavis.edu/mercltrs.html

©1999, 2007 Melvyn D. Magree

2014 Postscript:

Professor Matloff is still writing about hiring practices in the computer industry, including their effect on the computer systems for the Affordable Care Act.  Hint: The H1-B programmers have not been among the “best and brightest”.  See “Coding Geeks Can’t Save ObamaCare” among many, many others.