[ajug-members] The Development Skill Laundry List
Keith Welch
kwelch at mindspring.com
Sun Aug 19 01:50:19 EDT 2007
The Development Skill Laundry List
One of the most disturbing and destructive trends in software development job specifications
is the increase of the length of the "skills laundry list" to gargantuan
size. I have seen ads for Java developers with over 40 skills desired or required.
Several of these were rather obscure open source frameworks. My first question was
whether or not if it was statistically likely that even a single individual possessed
all those experiences on a planet such as ours with a population with only a few
billion people.
Does anyone have time or cause even to master each and every nook and cranny in
J2EE, which many of us consider to be the core of our skill and experience? Perhaps
not. Developers who implement optimized wire protocols have little use (and maybe
a little contempt) for standard RMI. The same is true for Hibernate zealots and
raw JDBC. There are 17 major API's within J2EE, and a couple of new ones in
each J2EE release. Like the rest of you, I'll tell you right now that my current
knowledge of more than one of these API's was acquired purely for interviewing,
or is something that I currently have little use for (EJB's come to mind, which
I created a code generator for - before XDoclet). What about you? Did I mention
that J2EE was ONE of the items from the ad mentioned above?
Let's be honest here. The majority of this skills requirement bloat consists
of open source frameworks of a nature and size that they can be learned in hours
or days. Obviously, there are some major exceptions. However, do you really think
that the Commons Validation framework needs to be a pre-requisite for employment,
and that anyone that has not used it is a poser? That's what this particular
recruiter now thinks - for that position, anyway. That is patently irrational.
How the Laundry List Problem Began
Part of the genesis of the problem began as developers became comfortable with the
idea that their projects were heavily dependent on open source frameworks. For several
years, Java web development WAS Struts, for example. Managers no longer cringe when
they are told that most - or all - of the frameworks their projects and systems
depend upon are not commercial products. Most of us would agree that this is a positive
development - by itself.
However, the well-financed and long-pursued goal of creating a glut of software
developers on the part of the ITAA and others has made the profession one living
under a constant shadow: commoditization. Commoditization is that act turning a
previously specialized and unique into something undifferentiated and common. Wheat
is a commodity, for example. You would be hard-pressed to tell one grain from another.
Sun is doing the same thing with Java development in that they want prospective
Java adopters (the companies) to view the actual practitioners (you and me) as interchangable
and identical parts. Note that this doesn't work out well for either recruiters
or J2EE developers. It tends to put us both in lower tax brackets.
Can you, as an employee, claim that you are unique and valuable if you list the
number of skills required to do your job can be written in large letters on a postage
stamp ( J - 2 - E - E )? I suspect not. As a recruiter, how valuable are your services
if there are several hundred thousand developers possessing the one major skill
you have been tasked to find? Not very, I would say. So, what do you think happens?
The technical staff protects itself by padding each new job description with every
API and open source framework that the organization has even thought about using.
Does this mean that we have all become cynical and dishonest? For the great majority
of people, that is not true. However, even without an intentional agenda of self-aggrandizement,
there is another powerful force at work: self-validation. No one wants to think
of himself as a commodity - especially not a common one. We all want to be unique
and valuable. So, when asked to prepare a list of skills needed to work for the
team, it is human nature to add every little thing that you can think of.
So, what's the harm? There's lots of harm. Once a recruiter gets ahold of
that list of 40 skills, they are written on stone tablets. Try as you might to say
that some set is optional, he will try like mad to match it up precisely. To their
credit, some more experienced and savvy recruiters will adapt and start focusing
on the mandatory list of skills (if they were lucky enough to get the list that
way). However, that may be weeks or months into the search.
Also, a lot of candidates are intimidated, or don't want to waste valuable time
meeting someones unreasonable expectations. Again, this just makes the search take
longer. If you think this is all at the recruiter's expense, and are amused
at the idea, wipe that grin off your face. We are all the victim on this one. Where
do you think that supposedly rational people get off telling their congressmen that
there is a severe shortage of software developers, while you see former colleagues
waiting tables?
The fact that your recruiter has been unable to find a person with 40 unrelated
skills gets back to your VP as "there are no competent Java programmers left
on the east coast." Your CFO then writes a few checks payable to 5 or 10 of
his favorite senators' campaigns out of the company political slush fund (what,
that's news to you?) with instructions to fix their little problem. One unrecorded
midnight vote later, perhaps another 20,000 Java programmers with freshly falsified
degrees and work histories (where they pasted all 40 of those skills right out the
ad) hop a plane for the States. Polish up on those wine pouring and spatula skills,
boys, 'cause these guys will work for $10K a year if they must, to get your
job!
Not grinning anymore? I didn't think so. The next time someone asks for a list
of required Java skills, no one expects you to put just J2EE down, but show some
restraint, will ya? The same goes for interviewing. Only a real a**hole picks this
moment as an opportunity to display his astonishing command of the entire retenue
of Java's "obscure but true" file. All you have proven is that you
were a virgin in high school, and that your only true skill is memorization. You
are there only to determine if someone is a competent developer in your specialty.
So, do that. If you want validation, put up a MySpace page.
(Part of an upcoming book)
More information about the ajug-members
mailing list