On Thu, 14 Feb 2013, Jason Griffey wrote:
> On Thu, Feb 14, 2013 at 10:30 AM, Joe Hourcle <[log in to unmask]
>> wrote:
>
>> Two, 'coding' is a relatively minor skill. It's like putting 'typist' as
>> a job title, because you use your keyboard a lot at work. Figuring out
>> what needs to be written/typed/coded is more important than the actual
>> writing aspect of it.
>>
>
> Any skill is minor if you already have it. :-)
>
> As others have pointed out, learning even a tiny, tiny bit of code is a
> huge benefit for librarians. The vast, vast, vast, vast majority of people
> have absolutely no clue how code translates into instructions for the magic
> glowing screen they look at all day. Even a tiny bit of empowerment in that
> arena can make huge differences in productivity and communication
> abilities. Just understanding the logic behind code means that librarians
> have a better understanding of what falls into the "possible" and
> "impossible" categories for "doing stuff with a computer" and anything that
> grounds decision making in the possible is AWESOME.
It's true ... and learning lots of different programming languages makes
you think about the problem in different ways*
But equally important is knowing that's it's just one tool. It's like the
quote, 'when you have a hammer, everything's a nail'.
... and more often than people realize, the correct answer is not to write
code, or to write less of it.
I remember once, I had inherited a project where they were doing this
really complex text parsing, and we'd spend a month or so of man-hours on
it each year. My manager quit, so I got to meet with the 'customer'.**
I told her some of the more problematic bits, and some of them were things
that she hadn't liked, so used it to push back and get things changed
upstream. The next year, I was able to shave a week off the turn-around
time.
For the last few years, I've been dealing with software that someone
wrote when what they *should* have done was survey what was out there, and
figure out which one met their needs, and if necessary, adapt it slightly.
Instead, they wrote massive complex systems that was unnecessary. And now
we've got to support it, as there isn't the funding to convert it all over
to something that has a broad community of support.
(and I guess that's one of my issues against 'coders' ... anyone who
writes code should be required to support it, too ... I've done the
'developer', 'sysadmin' and 'helpdesk' roles individually ... and when
some developer makes a change that causes you to get 2am wakeup calls when
the server crashes every night for two weeks straight,*** but they of
course can't roll back, because 'but it's in production now, as it passed
our testing'.)
-Joe
ps. I like Stuart's 'Library Systems Specialist' title for those who
actually work in libraries.
pps. Yes, I should actually be writing code right now.
* procedural, functional, OO, ... I still haven't wrapped my head around
this whole 'noSQL' movement, and I used to manage LDAP servers and
*love* heirarchical databases. (even tried to push for its use in our
local registry ... I got shot down by the others on the project).
** we were generating an HTML version of the schedule of classes based on
the export generated from QuarkXPress, which was used to typeset the
book. The biggest problem was dealing with a department code that had
an ampersand in it, and the hack that we did to the lexer to deal with
it doubled the time of each run. (and they made enough changes
year-to-year that the previous year's script never worked right out the
bat, so we'd have to run it, verify, tweak the code, re-run, etc.)
*** they never actually fixed the problem. I put in (coded?) a watchdog
script that'd check every 60 sec. if ColdFusion was down, and if so,
start it back up again. So only the times when the config got
corrupted did I have to manually intervene. By the time I was fired
(long story, unrelated), it was crashing 5-10 times a day.
