Yesterday, I was part of a panel with two brilliant colleagues (and a really great moderator) about computational thinking and problem solving in a library context. The room was packed, and I found the discussion rejuvenating — I’ll do my best to capture some lightening in a bottle.
What am I talking about?
“Computational thinking” is a term to describe a mode of problem solving that we all engage in.
What is computational thinking? It’s not necessarily about learning how to program, but rather how to think strategically so you can solve a problem, reduce or eliminate tediously repetitive tasks, improve accuracy and increase efficiency. Drawing on computer science strategies such as finding the logical structure of a task, modeling data in a more accessible form, and figuring out how to apply iteration and algorithms to break a task into pieces that might be automated, computational thinking is a mindset that anyone can learn and apply.
Everything that you do a find and replace operation, you’re using computational thinking. If you’ve ever wanted to make find and replace more powerful or more exact, and you think you might know the rules for doing so, you’re well on your way to using computational methods.
How did I get here?
All three of us talked about not having formal backgrounds in computer science — Arcadia explicitly considers herself a “humanities person,” but fell in love with methods and tools she had developed to help do work better and more efficiently. Mark mentioned that he has an educational background in astronomy, but that for most of the computational work we do, we really only need pretty basic arithmetic. My master’s degree is in information science, but I did my undergraduate work in history (with particular interest in intellectual history) and I’ve never taken a computer science course in my life. I even weaseled out of the required information theory class in grad school so that I could take a doctoral seminar in the history department.
I didn’t talk about this during the panel, but I definitely have spent a lot of my life with a healthy distrust of “automation” and “efficiency” for their own sake. I poured beaucoup haterade during grad school. I felt sensitized to the obvious gender politics between the “computer” people who would go on to work at Amazon and Microsoft and the “people” people who would go on to work in non-profit libraries and archives. We were paying the same tuition, but we were very obviously not getting equitable access to resources. And I didn’t feel like the economists and computer scientists on the faculty had the same vocabulary I did about critical theory or social justice. I was there to be an archivist because I believed (and believe) that taking a cold, hard look at the past as it really was does a lot to dismantle fantasies of teleology and the inherent naturalness of patriarchy and white supremacy and nationalism and disdain for the poor and the inevitability of late-industrial capitalist society. Societies have been radically different than what they are now, which means that nothing is inevitable. I want to be an archivist because I believe that access to records can result in accountability to actors in the present and can provide leverage for the future.
I’m here to tell you that no one in my workflow analysis class was interested in talking about that. In fact, I sometimes think that technologists’ Utopian scientism — their dogged devotion to technical improvement — makes them susceptible to a Whiggish view of history and less observant of the lived constraints and injustices of others. When you spend your days “developing,” it’s not always easy to see that the world hasn’t gotten better on the whole for everyone. Now imagine a school founded on this worldview. I found this repellent, almost at a visceral level, entirely at odds with my education until then. Looking back, I wish that I had fled less into the embrace of archives, history and anthropology courses, and tried to get enough leverage to take a guerrilla approach to my education. There are gaps in my technical education that I wish I had taken the opportunity to fill.
Then I started working. And, as I mentioned on my panel, I really hate doing boring work. I hate feeling like a robot. I hate putting bad data into a filemaker database that’s not accessible on the web and not based on schemata. I hate the waste that comes from data that can’t be re-used. I hate the waste of doing something by hand that isn’t creative or analytic or synthetic.
In archives, we work in bulk, we work with records formed by computers, and discovery happens in a networked environment. It became clear very quickly that if I wanted to be good at my job, if I wanted to deal with information explosion, and I didn’t want to do boring crap anymore, that I should get nimble around a computer.
So for me, at least, finding my way around a computer was necessary so that I could make room for the intellectual work of being an archivist. And I found, to my delight, that applying computational solutions is a creative, intellectual exercise in its own right.
To wrap up, here is the rest of my fortune cookie wisdom about computational thinking and library / archives work:
- Be uncomfortable with boring work. Let that discomfort point you toward better solutions.
- Know why you’re doing a task in the first place. This will help you design a better method, and may even help you ditch the task altogether.
- At first, it may take a lot more time to do something with a script than to do it by hand. But once you’ve done it with a script, you’ve actually learned something. If you do it by hand, you’re stuck in the same learning mode that you were before.
- Agitate for learning time.
- If you’re a manager, encourage not just that work gets done, but that it gets done the best way using the best tools for the job.
- It’s going to be hard to learn this stuff. It’s especially going to be hard if you’re the member of a group that people don’t see as a typical technologist.
- Haters gonna hate, especially on the internet. Find your supportive group. (It’s why we have this blog!)
- Learn how to make good back-ups. You may kill your database/computer/whatever a few times. If you have a back-up, it’s no big deal.
- You’re here for your users. Spend your time on stuff that benefits them, and let the robots do the boring stuff.