Every Error is Evidence

When I first started working with library systems, I treated unexpected behavior the way most people do.

If something produced an error, I fixed the error. If a popup appeared, I clicked through it. If a report returned the wrong results, I adjusted the query until it looked right.

Lately, I'm realizing I've been asking the wrong question.

Instead of asking, How do I get past this? I find myself asking, Why did the system behave this way in the first place?

This small shift in thinking is influencing almost everything about how I work.

Recently I've been documenting our workflows for Lost, Lost Paid, and Missing items in Alma. On the surface, it looks like a documentation project. The finished product is a manual with policies, definitions, and procedures.

But the interesting work happens long before I write the first procedure.

Every edge case becomes a clue.

Why does this item generate one popup while another generates a different one? Why is this status tied to a patron loan while another isn't? Why does this process stop here but continue there?

Every question is another piece of evidence that the system is making a distinction I don't yet understand.

The same thing is happening while I'm building tools around Primo search. A search result isn't just a search result. It's evidence of how the ranking algorithm interprets a query. Search an author's last name and get a subject heading back instead, and that's not noise. It's the system telling me something about how it weighs that term. Every surprising result suggests another experiment.

I think I am learning the most when a system surprises me.

If everything works exactly as anticipated, I learn how to operate the system.

When something behaves unexpectedly, I have an opportunity to understand it.

Not fixing the error. Not clicking through the popup. Not adjusting the query until it looks right.

Figuring out what the system is trying to teach me.