04-01-2008


Steve Meyer - From SLIS Student to Library Hacker

 

Steve Meyer works for the LTG for the general UW library system

 

Graduated SLIS 2004 --> NCSU Library Fellows program for 18 months, then back here for "library application developer", aka "library hacker."

 

Steve asked his hacker peers for quotes and comments, which are sprinkled below. A link to the PowerPoint will hopefully be posted here shortly too.

 

 

What do you do in library technology?

1. LTG: work with staff at DoIT to manager library catalog and servers, etc.

2. UW Digital Collections: build UW's collections of digital objects

3. Web Services: every website that the library runs - all the people who make websites throughout the campus that are related to Libraries (there are thousands of websites)

 

 

How do you become a library hacker?


 

Rule #1: get your hands dirty. Learn about code, standards, markup languages.

 

Implementation is worth more than ideas; a lot of people in LIS understand how things are structured, but that's not the same as knowing the infrastructure behind it and making it work. You don't have to be certified or degreed, just do it.

 

On Programming Languages:

- Perl

- PHP

- Ruby

- Java

- JavaScript

- HTML

- CSS

- SQL

- SGML

 

Learn to program, don't just learn to program in a single language. You might need to switch languages depending on the project, so don't just focus on one language. If all you have is a hammer, everything looks like a nail. Most projects today will use multiple technologies: data access, HTML, CSS, etc. But you'll learn that a loop is a loop is a loop… once you learn how programming works, the specific language is less important.


Rule #2: Practice your project management skill.

 

Time management + workstyle + communication. People who sent Steve comments mentioned communication over and over. Nobody who's asking for your time will know exactly what you do, or how hard it is, or what frustrates you, so you need to explain it. "I know this looks like an easy thing, but let me explain why it's actually big… or vice versa."

 

Sometimes you need to say "no", pointing out that something isn't the right direction… but explain it well.


 

Rule #3: Balance is everything.

 

"OCD is your friend during implementation and our enemy during planning."

 

Have to be able to shift between looking at big picture and little picture.

 

You are in the business of designing everyday things. Not to be a rock star or to wow people, but to make peoples' lives easier.

 

You really have to seriously understand the problem you're trying to address. Care about the problem.

 

Laws of Innovation (see slideshow for a complete list).

 

Most technical problems are really cultural or cognitive problems. They're actually not technical at all, but we get hung up on the technical side. Example: if you do a black and white mockup to abstract a site, the users will sometimes get terribly hung up on that, asking why we can't have color.

 

Plan to read a lot - technology books, books outside of your comfort level, and sometimes outside of your interest areas because they're useful. Not just programming books, but also design books. Consider economics books: can relate to software design. Even Wittgenstein's Tractatus Logico-Philosophicus, a 100 year old philosophical text, might help. This all gets you closer to being able to read specs and write good code.

 

Hone your 6th sense for technology.


Question: what should LIS students do to learn this stuff, or what should the program do?

 

Database Design class is a great elective to help you confirm whether you like this stuff.

 

Also take Information Architecture class.

 

Also some of the summer electives that are relevant. Jonathan Broad, former student, came in and taught a class on varied technology concepts.

 

Networking course would be good.

 

Their Info Architecture class redesigned a website for the primate center on campus. Try to identify a practicum where you do some projects in this.

 

UW has Safari Tech Books Online


 

Project Example

 

An Archeologist working for Art History contacted Peter Gorman, head of UWDCC, and wanted to turn his personal dataset from an archeological dig into something people could review online. Excavated an entire city (Olynthus).

 

He gave them his database. It wasn't all that consistent. Its structure had evolved over time, and not very consistent: a house might be of type "street" or "alley" or "grave" for example. They needed to start by understanding his data structure, and changing it into a new database that was more consistent in its form. Steve developed a web front end to let people search the collection. Recently they integrated an open source product called "solar" that lets you do a faceted search on your data source.