in Conferences |

Four big ideas from Code4Lib 2013

I was happy to make it back to the Code4Lib conference this year. For those unfamiliar, Code4Lib is a group of self-organized library tech-types that’s not affiliated with a professional organization. Each year a different set of Code4Lib members from a different city volunteers to host the conference. This year’s conference was in Chicago, hosted by an intrepid group of library coders from UIC and Loyola.

As usual, the conference was a blast (not unlike edUi): great people, informative/inspiring sessions, cool city. I really enjoyed meeting new people and catching up with familiar folks. And the conference itself ranged from the theoretical to the super-detailed, and I ended up taking copious notes on helpful items from code snippets to inspirational quotes. The big takeaways, though, are still revealing themselves me two weeks later.

Community = relationships, not product

Code4Lib opened and closed with talks from big thinkers Leslie Johnson and Bess Sadler, respectively. Both speakers focused their talks on the idea of community, including the Code4Lib community and other open-source and/or technology communities.

The connecting idea: the core of a tech community isn’t code; it’s relationships. Healthy relationships build healthy communities, and healthy communities are open, communicative, and inclusive. We’re all solving some of the same problems, here; we need to talk to each other, self-reflect often, be open to criticism, and be open to change and growth.

And–no surprise here–those relationships are the reason that conferences are special for more than just the awesome presentations. Catching up in the hallways, meeting new people, and making those interpersonal connections is what makes conferences so special.

Keep growing: foster a hacker epistemology in yourself and others

Bess Sadler’s talk at the end of the conference got at the core of our community, a trait that unites us all: learning by questioning and tinkering.

What is a hacker epistemology? From the text of Bess’s talk:

Epistemology, if you’re not familiar with the term, refers to the question of how we decide what’s true, how we construct knowledge. … Here in code4lib, many of us have more of what I think of as a hacker epistemology, this magic combination of collaborative knowledge building, combined with a disregard for the mental traps of conventional thinking. We like to take things apart and see how they work. Sometimes we listen to what authority figures tell us, but we easily discard received knowledge if we gather evidence that contradicts it. … The truth is what works.

Finding ways to support our own and others’ curiosity, exploration and experimentation is crucial to growing our communities and making better stuff. And being open to acknowledging bugs, not just in our code but in our lives, to actively try to fix things, makes the world better for everybody.

The biggest failure is not talking about failure

Lately there’s been a lot of talk about failure, inside and outside of the tech community. I was happy to participate in a pre-conference breakout session called Fail4Lib, wherein a small group of us discussed projects that had failed at our institutions. Everybody’s candor was so refreshing, and  it was also a relief to hear of other organizations grappling with similar problems.

From this preconference, here are my unofficial top-three reasons why projects fail:

  1. There’s a breakdown in communication somewhere, from senior management to project team to external stakeholders to internal stakeholders…there’s no such thing as overcommunicating about your project. 
  2. We don’t know it when we see it. Failure isn’t always something that blows up in your face.  Sometimes we don’t assess projects after they launch (or a year down the road, or 5 years down the road) and they fail slowly, a little bit, over a long period of time. And sometimes we just don’t know when to quit a failing project. The list goes on.
  3. We’re building projects without a clear audience or purpose.  Are you building something just because you can or just because you’d like it yourself? That’s not enough of a reason. Know your audience. If you don’t know the why’s or the who’s about your project, kill it.

Don’t forget why you’re here

Mark Matienzo’s lightning talk on emotion in archives was a highlight of Code4Lib for me. In a few short minutes he brought us all back to the reason library and archives folks do what we do: we’re preserving emotions and making them available to the world for remembrance, education, creativity, inspiration.

For people in the nonprofit sector–whether we’re archivists preserving the cultural record, or web-folk working on making it easier for high school students to apply for college–it’s good to be reminded that our mission is grounded in helping people and connecting them with information.

Other read-worthy wrapups of Code4Lib 2013

Published