Tim Spalding said:
"If libraries paid their tech people better, they'd get better ones to start with, and retain the good ones longer."
I'd modify that by substituting "staff in general" for "tech people" - but I agree with the general sentiment. That said, it is indeed not about the money frequently. I agree with Mr. Graham's notion that "good hackers care about their freedom on the job (and the amount of bs they have to deal with), the problems they're given and the tools they get to use." But again, this sentiment is true of many more "traditional" library staff - from cataloguers to children's staff. In fact, I'm hard pressed to think of any worker who wouldn't like this type of job freedom.
I've been lucky. I've worked with almost 30 libraries of various types in my fairly short career (the joy of working for consortia) and I have only dealt with one that was resistant to new ideas for seemingly no good reason. At the other libraries, new ideas sometimes couldn't go ahead for various reasons: lack of money, lack of time/staff, lack of expertise, feeling that it simply wasn't appropriate for their users - but some new ideas were always tried. I know that other systems folks (or library staff) have not been so fortunate.
Alexander Johannesen said:
"Why? What has LIS got that the rest of the world could benefit from?"
Ooookay. I see that James Weinheimer has already responded to the general tone of this snark. My response is more specific. CS is fairly infamous in the general business world and in the library world for not listening to customers - whether on the help desk or at the design stage. It's bad enough that there are streams of articles written on how to "talk" to your technical staff or how to "rein in" your technical staff. Having the attitude that your "client" has nothing to teach you (be they library, insurance company, Fortune 500 company or a fellow employee) does nothing to dispel this belief.
I certainly don't expect a programmer to understand the intricacies of MARC or authorities or circulation or outreach service or anything else (I certainly don't). I do expect them to consult someone who does and to ask their customer if what they have designed meets their needs - many OPACs illustrate the danger of failing to do this. Many libraries (and individual library staff members) feel ignored and derided by programmers and technology companies so it's hardly surprising that they can't just "trust" you. I'm a programmer and I don't "trust" people or technology - I haven't drunk that Kool-Aid.
Lynn
---
Lynn Reynish
ILS Librarian
Regina Public Library
lreynish_at_reginalibrary.ca
Received on Sat Sep 01 2007 - 02:50:34 EDT