September 27, 2008, 12:03 PM — Knowing Java is not knowing much. Knowing C is not knowing much. Same for Javascript ECMA 262. The same is true for many other languages. Not all of them, but many of them.
What am I talking about? Well, I am a little frustrated at the moment at the common industry practice of simply requesting expertise in a particular programming language - like Java or C++ - as if that knowledge had a whole lot of meaning. It doesn't, and it is often dangerous to read too much into language knowledge when searching for expertise.
What am I talking about? Well, most mainstream programming languages are split into three pieces: the core language, a finite set of bundled libraries and the potentially infinite set of third party libraries. Generally, when I need to find programming help, I work backwards through that list. For example, lets say I need Eclipse RCP talent. First and foremost I need people familiar with Eclipse RCP. This implies knowledge of a huge set of Eclipse APIs, which brings with it the need for SWT knowledge - itself a huge API. Oh, and somewhere down there in the bowels of all of that expertise, is the Java language itself.
Do you see what I'm getting at? A developer who "knows Java" but does not know Eclipse or SWT is not very close to meeting the need. Running an advertisement that asks for Java experience is not going to cut the mustard. It can take literally years to become comfortable with some of the big ticket Java APIs. The same goes for C++ APIs. The same goes for Javascript APIs.
To see this - starkly - in the case of Javascript, it is worth perusing ECMA 262 a formal expression of what it means to know Javascript. Not much there huh? What you really need (probably) is expertise in JQuery or YUI or XUL ...
I think part of the problem is that sometimes simply naming a language does carry with it, implications of knowledge of the surrounding libraries and application stack. Visual Basic is a good example. It goes without saying that a VB programmer is skilled in the arts of wielding the Microsoft Windows APIs. A Visual C++ programmer is almost guaranteed to have important skills that go way beyond the C++ language.
Bottom line, if in doubt, spell it out. If you really need someone to program in C++ against an Oracle back-end, spell out the Oracle bits. The C++ bit on its own probably will not get you what you want.
Oh, and finally. Don't underestimate the amount of time it can take to "pick up" a new library or application stack. I have heard hiring conversations that go like this "We need an SWT app. Joe has worked with Java before, so he can pick it up.". Danger. Danger. Joe can most likely pick it up for sure but it is highly unlikely to be a wet afternoon's work. Not by a long shot.
To paraphrase John Maynard Keynes: APIs can stay impenetrable longer than your schedule can stay acceptable.
