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.