I’m writing a book (a snippet of which I posted earlier ) and I’m using Scrivener to do it. Scrivener allows me to write in chunks, and to rearrange the chunks as the thing develops. This morning I wrote a chunk that I’m not entirely sure goes where I currently have it. Eventually it’ll find its home; right now, it’s in an afterword. Possibly it should be an appendix. Maybe it needs to go in the beginning. For now, I thought I’d share it because it might be useful for someone out there. And if it’s not useful, better to find out now than when it’s in print, eh?

~o0o~

Digital archaeology, as I have conceived it here, is not about computation in the service of finding the answer. It is about deforming, and thinking through, the various networks and distributed agencies that tie us to the past and simultaneously make it strange, that enchant and confound us. There are any number of courses on the books at universities around the world, any number of tutorials on any number of websites, that will walk you through how to do x using software package y, and when you know exactly what it is you need to do, these can be enormously helpful.

The best strategy for deformance however is to play. Play around – you’re allowed! Try things out. See what happens when you do this. But we – as the academy, as the guardians of systemized knowledge – have managed to beat playfulness out of our students. What’s more, when you’re just starting out, and you’re not sure of the terminology, not sure of even what it is you’re after, what question you’re really asking, it is easy to succumb to information paralysis – too much information means you’re not able to act at all. The strategy I take with my own students is to make it safe to fail, safe to play around, what Stephen Ramsay famously called the screwmeneutical imperative. To do this, you need to have someone model productive failure, to have someone to point to who is trying things out and reporting back on what has worked and what has not. Beyond this, there is therefore no magic recipe, no silver bullet:

“Should I learn python or R or javascript or….?”

“No. You should identify the problem at hand, and then use whatever it is that works for you” is the unwelcome answer.

The truth is, you exist at this point now with access to these particular resources and this particular digital environment. You use what you have now to see more of the landscape of possibilities. Getting started then just means to fold what you already know how to do into a cycle of experimentation. If you want to get started in digital archaeology, develop the habit of note taking and reflective practice every time you sit down with the machine. Do not remove yourself from the reporting. As Mark Sample once wrote, citing the Oblique Strategies of musician Brian Eno, ‘your mistake was a vital connection’ (2015). You will find in your mistakes your own sources of enchantment, of vibrant materiality.

Guidelines for developing your own digital archaeology
Digital work is craft work, and like all craft, there is any amount of tacit and embodied knowledge that you will have to learn. These guidelines are meant to help you work these out.

• First of all, recognize that digital work is slow. Computation itself might happen quickly, but getting to the point where you’re doing what needs to be done in order to do x, y, or z is a slow process. Understanding what the results might mean is similarly slow. Opening black boxes of algorithms (recipes, step by step instructions) and understanding what someone else has coded is slow, painstaking work. To encode something necessarily means that something else has to be forgotten. Ask yourself: what has to be forgotten in order for this to work?
• Play. Modern computers and devices are by default largely locked down by Apple, by Microsoft. You are not supposed to do anything outside of the ecosystem of apps and software that are provided to you. Push against this. Learn to open the hood. Find the terminal, find the command line. You will be pushing here against modern techno-capitalism (you anarchist!) This will be the hardest part.
• Keep track of everything. Write down what you did, and why you did it and what aids, tutorials, blog posts, and walkthroughs you were reading.
• Search the exact error messages you receive – copy the error message and search – with perhaps a bit of context. Chances are someone else has already had this error before and has posted the solution.
• Share this information, within the boundaries of what is safe for you, given your particular situation, to do. As a white middle aged tenured man, I can be far more open about my failures online than other people because I am privileged, and so I keep an open research blog at electricarchaeology.ca (and if you are a white middle aged tenured man, why aren’t you making it safe for others to share what works and what hasn’t?)
• The framework that Brian Croxall and Quinn Warnick developed for discussing ‘failure’ in the context of digital pedagogy can be usefully employed to provide structure to your notes and reflections. Understanding why and how something failed, the type of failure, is a necessary precursor to developing your digital craft.
• Carefully detail when things do work, in the context of what hasn’t in the past. Not only will you have a handy reminder of what to do the next time this particular task presents itself, but you will have a record of your own progression, your own development over time that will help keep you motivated.
• Attend to enchantment. These moments when you are confronted by the uncanny and the delightful are signals of deeper assemblages of distributed agency in your materials. Where you find enchantment, there you will find that you are learning something deeper about the world. Digital archaeology is amazing. Why shouldn’t you find enchantment, joy, in your work?

A vital resource for learning the tools of digital work for those of us in the humanities is The Programming Historian, a set of peer-reviewed tutorials that continues to grow (and is also available in French and Spanish). Survey the lessons there to see various hands-on walkthroughs of tools or approaches that you might wish to use on your own materials. Begin with the lessons by Ted Dawson (for PCs) and Ian Milligan and James Baker (Mac) on the command line and the terminal. Lemercier and Zalc’s Quantitative Methods in the Humanities might also be a good spot to start, as well as the various agent based modeling and network tutorials collected by Tom Brughmans on his blog, https://archaeologicalnetworks.wordpress.com/resources/ . For agent based modeling in particular, download Netlogo from the Centre for Connected Learning at and Northeastern University https://ccl.northwestern.edu/netlogo/ and work through its tutorials. The Open Digital Archaeology Textbook Environment covers many different computational tasks from an archaeological perspective, and also comes with prebuilt computational environments that can be launched with a single click (hence taking care of the problems of installing software packages and allowing the reader to jump into learning rather than spending time toiling with configuring their own machine); it may be found at http://o-date.github.io.

How do you get started? These guidelines will help, but remember, there is no rule-book for digital archaeology.