More On Languages, Programmers and the Hiring Thereof

This is an extension of an ongoing discussion Esther Schindler and I are having here and at CIO.com, which started as a discussion of programming language popularity, and has extended itself into a discussion of what sort of people one should hire. It's got a lot of "in-references", so if you're not a pretty heavy programming geek, you'll probably want to skip it.

Blake, you speak as though the choice is between the okay-quality experienced developer and the brilliant developer who doesn't happen to have programmed in, say, ObjectREXX or JavaScript or what have you. But it doesn't really work like that.

Well, yeah, it works like that when you foster an IT programming culture that favors results over dogma. Heh. It has to: You're working in Scheme or Smalltalk or Eiffel; you've just ruled out the programmer who, you know, graduated in '97 with a Java specialization because of all the money in the tech bubble.

Usually, an employer whose job req says "ObjectREXX would be a good plus" gets plenty of resumes from programmers who do have that experience.

Think if I ran an ad today for ObjectREXX programmers I'd get plenty of resumés? There's...uh...me...and...you? The same is true for a lot of great tools, like Squeak, Lisp, even regular REXX, and for that matter, even Delphi. But perhaps there's a point of agreement there.

At some level, what you're saying is: "This technology is good enough that we can afford to take a hit in the hiring department." A lot of us made that choice with OS/2, for example, and for the 10 years we used it, it was a good risk, even though it was almost impossible to find people in our area who knew it. It was just that productive.

Recently I worked with a company that programmed their tool in Delphi 7, and they had a bear of a time finding qualified people. We had some heavy discussions about better tools, because I saw that they had developed these huge systems to work around the problems that arise with statically typed languages. I'd say it actually hurt them, because to understand their code, you had to be well-versed in relatively cutting edge Delphi (even though they had stalled at D7, they were using interfaces, modeling tools, code generators, etc.).

But had they used Smalltalk, for example, they could have hugely reduced their burden, and in some respects made their code more accessible. The deal breaker was that they were pretty heavily reliant on code that others had written. I do some Java, not because I'm a fan of the language, but because sometimes that's where the code I don't want to write is.

And HR departments, keyword-driven as they are, probably don't pass along the resumes of the candidates who write, "But I can learn!" in the cover letters. So you may be happy to entertain the brilliant-but-inexperienced, and you might never encounter them.

IT really shouldn't use HR for hiring much, if at all. They're not competent to even filter out the first tier candidates. I've seen plenty of HR departments post ads where the only qualified candidates would be liars. You know, put ECMAScript and JavaScript on your resumé and see which one gets you hired.

Besides, people who can learn--in my experience, anyway--they don't advertise it because they don't realize how rare and precious a commodity it is. Certainly I didn't until, at one job, I picked up a threadbare manual for a proprietary language and environment, and coded a specimen cataloging system in two weeks, while the consultants whose proprietary environment it was were still busy negotiating their six-month/six-figure contract for the same system.

I don't say it to boast, as it was a mean feat that any reasonably competent programmer willing to learn could have done. But I couldn't, as you say, have gotten a job doing it. But I love having random programming challenges thrown at me, and I encourage the hiring of others who feel the same. In fact, the aforementioned Delphi 7 crew I worked with had a test: They gave you two hours to write as much of a program as you could. Easily one of the more fun application tests I've ever done.

Plus, of course, someone might say they're willing to learn, but they don't actually do so. It's another tangent entirely, but there's few things as awful as employing someone who really wants to be good at something but is only semi-competent.

The beauty of IT is that you can often shuffle that person off to a different role. I'm always checking out the systems guys for the latent programmer. You put people in as network admins and switch them to help desk, because they're good with people, or maybe to DBAs, or wherever.

I wouldn't recommend any hiring be done on the basis of candidate assertions. At least not ones like "I love to learn." or "I'm a real people person." But a programmer can talk to another programmer and within a few minutes ascertain what they're really capable of.

I do take your point, but I've seen lots of discussions among developers and consultants about their need to stay "relevant" with the choice of language (or toolset or whatever) they focus on. If there are lots of jobs asking for C#, and few asking for ObjectREXX, many developers will choose an option that makes them more marketable.

When I was doing ObjectREXX (and VisProRexx!), I was also doing C++, not because I think it shouldn't have a stake driven through its heart, but because my best tool for small, fast code was Borland's OS/2 IDE. And I don't keep up the unholy trinity of PHP, Perl and Python for fun (well, okay, Python is fun). And I can't write a line of Ruby without thinking, "Well, this is just Smalltalk for the faint-hearted."

I get the need for relevance. But if I saw a guy whose career path went from C to C++ to Java to C#, I'd hesitate before hiring. What does he do for fun? Because I'm not interested in hiring a programmer who doesn't program for fun.