Interestingly, I disagree with almost everything you say below. Of course
PARC is unlike almost everywhere else :-)

Unless you're in a very, *very* different library than mine, "all the
low-level stuff" written in C and variants are at a low-enough level (and in
very specialized domains) that I'd never have an expectation that anyone
working in the library would mess with it. I presume there are people in
research libraries that muck around with C/C++, rolling their own libraries
and what not, but I've been at Michigan for six years and I haven't heard of
it, here or elsewhere. For most of us, I think, doing something in C is
premature optimization.

I hear the assertion often that a programmer needs to know C/assembly so
they can truly understand how the machine is working at a deep level, and
I've grown over the years to dismiss that assertion. Almost no one who makes
a living programming in libraries is going to do a better job "by hand" than
a modern optimizing compiler, certainly not if you take ROI into account.
Data structures and Big-O is enough to tell you if you're moving down the
right path, and then it's just a matter of being smart enough to use
existing libraries where applicable --- and, again, avoiding premature
optimization, at the code level or at the selection-of-a-language level. If
you're hiring someone who's going to have to know the details of cache
misses and how far to unroll loops or whatnot, you know exactly what you're
hiring him/her for and don't need advice about hiring a generic programmer.

For stuff where you need not access to the bare metal but just raw speed,
Java is mature, super-fast, and has lots of optimized libraries available.
It also turns out many of us are using Solr these days, so Java has snuck
into the library infrastructure already. 90% of my argument for doing
green-field projects in Ruby is that I can access low-level Java libraries
to do the heavy lifting and get an optimizing VM for free.

I don't care what scripting language you use, as long as you use it well.
Python, Ruby, Perl, whatever. If you know one, you can learn the others. If
you're a Python shop and want someone who can hit the ground running, that's
fine, but Python's not ubiquitous. I don't speak Python except at the most
superficial level, and yet I consider myself to be "devoted to my craft".
People who have seen my code may disagree :-)

For languages that are, shall we say, "less commercial," I think they're
useful as an analog for formal computer science training. There are plenty
of people who gain great skills and knowledge purely through experience, but
formal training is basically designed to short-circuit experience, and I
think a formal computer science degree (and esp. a master's) does a great
job of training people to think hard (and correctly!) about algorithms and
data structures. I expect someone with a CS degree to have been exposed to
functional programming, s-expressions, and a variety of data structures.
Substantial experience with Erlang or Haskell or Scheme or whatever tells me
(as long as the project truly was *substantial*) that the candidate has at
least thought hard about issues deeper than the ones one often runs across
dashing off a program in PHP or Perl. I would never foist a project in, say,
OCaml or Scheme on my library, because who the hell is going to maintain it
(and its environment)?? But I sure want someone who understands side effects
and their effect on multi-threaded programming, because I've got a lot of
idle cores sitting around waiting for work.

Finally, I always ask someone what their favorite programming environment
is. I've had a few candidates tell me that they just use Notepad, and I
don't mind admitting that that's almost a dealbreaker for me. Using a good
editor or an IDE is a critical part of taking advantage of the language
ecosystem. A good programming editor is a must. Not having at least syntax
highlighting and checking is, to me, a sign that you haven't written enough
code for the lack of such functionality to drive you nuts yet. Java without
an IDE is insanity. And if the candidate proudly tells you that she uses vi,
well, make sure she really knows how to push it around. You don't get
street-cred for using a 30 year old program shittily.

 -Bill-




On Wed, Jul 27, 2011 at 10:32 PM, Bill Janssen <[log in to unmask]> wrote:

> If I'm hiring a programmer, I want them to know C and Python.  C because
> all the low-level stuff is written in that, Python because it's simply
> the most useful all-around programming language at the moment, and if
> you don't know it, well, how devoted are you really to your craft?
>
> Various flavors of C are acceptable:  Objective-C is OK with me, and C++
> is a plus -- it's an order of magnitude more difficult than C to use
> properly, and people who can sling it properly are rare.  Additional
> languages which carry weight with me on a resume are OCaml, Processing,
> and any of Common Lisp, Scheme, or Clojure.
>
> If I was hiring a digital *librarian*, I'd also expect them to know
> Javascript, the language at the heart of the EPUB format.  But
> Javascript is kind of tricky; it's a subtle powerful language with bad
> syntax and weak libraries.  I certainly wouldn't recommend it to start
> with.
>
> Cary Gordon <[log in to unmask]> wrote:
> > There are still plenty of opportunities for Cobol coders, but I
> > wouldn't recommend that either.
>
> Java is the COBOL of the 21st century, so if you know Java well, there
> will be a job in that for the next 20-30 years, I'd expect.  Until the
> Singularity happens, anyway.  I'd think there will always be lots of
> enterprise Java jobs around.
>
> Bill
>



-- 
Bill Dueber
Library Systems Programmer
University of Michigan Library