The Index of Digital Humanities Conferences

Check out The Index of Digital Humanities Conferences, the largest extant collection of DH conference metadata.

The Data

The Index focuses on the flagship ADHO conference, but encompasses other events as well. As of this release, it indexes 489 conferences from 39 countries dating back to 1960. We entered individual work metadata for 59 of those conferences, including titles, keywords, authorships, institutional affiliations, and so on. In all, there are 7,082 conference presentations by 8,392 authors, hailing from 1,830 institutions and 86 countries.

The Index of Digital Humanities Conferences homepage.

The where/when conference data was crowdsourced through a google sheet and twitter. Conference presentation metadata comes from a variety of public sources. Recent ADHO conferences generally come from XML files on ADHO’s GitHub page, and earlier ADHO / ACH / ALLC conference metadata was entered by hand from old websites, PDFs, listservs, and printed conference programs contributed by Joe Rudman (ACH Treasurer 1985-1989). Non-ADHO conference data was entered by hand from public programs (usually PDFs).

To ease browsing and analysis, we cleaned and merged as much as we could. That means connecting “Cambridge University” with “University of Cambridge” and the occasional “Camridge University”, as well as “Scott B. Weingart” with “Scott Weingart”.

When possible, we also indexed the full texts of conference abstracts / program entries. Currently those are only being used to power the search engine and generally not visible on a conference work page. We hope to be able to display full text in the coming months, as we get permissions to republish them from the original rights holders.

Attribute assignment model diagram
The attribute assignment model diagram for the Index of Digital Humanities Conferences.

The Good

Julianne Nyhan and Andrew Flinn recently wrote

A crucial obstacle to the writing of histories of the field is that much of DH’s archival evidence has either not been preserved or is held by individuals (and so remains ‘hidden’ unless one can discover its existence and secure approval and the means to access it).

Nyhan & Flynn, 2016

This holds as true for DH conferences as for the sources Nyhan & Flinn were working with. There’s no single public archive for physical conference programs, most old conference websites no longer exist (often even absent from the Internet Archive), and even ADHO’s digital records are spread out across many sources or locked in byzantine and private ConfTool data dumps.

Ours isn’t the first attempt to put a DH conference database together, but it is the most extensive. It represents eight years of work by many collaborators and contributors, and builds off those earlier attempts. And it’s all open for anyone to use: anyone can download the data to browse or analyze.

In making this corner of our community’s history more accessible, we hope this helps fill the archival gap pointed out by Nyhan and Flinn.

The Bad

This was always a passion project: never funded, nor supported by any scholarly organization. We work on it in empty moments, usually months apart. We don’t have resources for additional quality control, nor time to implement all the features we want on the website.

Errors are rampant. We made mistakes entering data, we made mistakes cleaning and merging data, and we inherited mistakes made by conference program editors or even, occasionally, authors themselves. Some common issues include merging two entries that should be separate (John Smith of Florida vs. John Smith of Maryland, not the same person), or not merging two entries who should be connected (J.B. Smith vs. John Smith, the same person).

If you spot an error, please reach out to me, and I’ll do my best to fix it in a timely fashion.

For a dataset that spent its first six years as a hilariously complicated excel spreadsheet shared on Dropbox, the web interface is amazing. It solves so many problems. But there’s still a lot missing, because we simply don’t have time to build it. Faceting works strangely, we’re missing a lot of useful search interfaces, and we just don’t have the infrastructure needed to turn this into a crowdsourcing project.

The Ugly

Errors in data cleaning and merging can be problematic, but generally not show-stopping. Unfortunately data in the Index does have a few show-stopping issues, but rather than keep everything private until we can fix them all, we’re releasing this publicly in the hope the community can help.

When merging people, unless we’re absolutely certain two people with different names are the same, we won’t connect them in the database. That means a Jane Smith who changes her name to Jane Doe after getting married will not be merged. The issue disproportionately affects women (who are more likely to change names during their careers), and as Jessica Otis and I point out, will put those women at a disadvantage in any eventual analysis.

The merging issue also affects people who for whatever reason (often gender/identity transition) decide to change their names. To complicate matters further, many who change their names do not want their birth name / deadname shared on the web, but since we don’t know that, their old names remain visible within our database.

Our data entry and cleaning gets worse the further we (the data collectors) get from our cultural comfort zones. This became a problem in the first and last name fields; figuring out what went where proved particularly difficult for us with respect to Hispanic and Indian authors. We reached out to friends for help, and used the separations entered by authors themselves when XML was available, but errors still abound.

Additionally, our department/institution database ontology (a strict hierarchy) fails for many Italian and French research units, which are often shared across many institutions. Italian and French affiliations are frankly in an abysmal state, and we’d appreciate input to help us untangle that mess.

Sir Not Appearing In This Film

The most apparent absence in the database and website is the full text of presentation abstracts (which are sometimes the entire conference paper).

We have full text for 75% of all works in the database (5,301 of them, to be exact), but because we either don’t know their copyright status or don’t have explicit permission to publish them, they are currently invisible. Searching in the works page will search through the full text of the abstracts, and present works with relevant hits, but visitors will have to find other sources to view the abstracts themselves. We’re working to secure permissions to share what we have, but it may take some time.

When I first started this project back in 2012, it was based on submissions to the DH conference, which I collected by scraping (without permission) the semi-private website for reviewers to select which submissions they were most qualified to review. I continued this for several years, comparing submitted abstracts to what made it to the final program, adding collaborators along the way. For privacy reasons, that data isn’t included here.

My collaborators and I also began collecting author demographic data, using it to point out biases, absences, and related issues of equity and inclusion in the DH conference community. Though reductive, the data served its purpose. Following the work of Miriam Posner and conversations with Shack Hackney, however, we believe the potential for harm in making demographic data part of this public database would outweigh any potential benefits.

Such demographic data would also likely put as at odds with GDPR. It’s worth pointing out that ADHO is keeping its distance from this project because it is worried about potential GDPR ramifications even without demographic data, which is understandable. From several sources (e.g., 1, 2, 3), it seems this is an “archive in the public interest” and thus doesn’t violate GDPR, however I’m not a lawyer and I suppose anything can happen.

In the spirit of GDPR and the general “right to be forgotten”, we will happily take down any personal data for any reason. Just reach out to me if you’d like your materials to be removed.

Roll Credits

As alluded to earlier, this was a group effort over eight years. Nickoal Eichmann-Kalwara has been my partner in crime (sometimes literally, but only small crimes) for most of it. We’ve put in countless hours guiding the project, entering and cleaning data, and strong-arming friends into becoming collaborators. Jeana Jorgensen contributed her inimitable expertise and guidance for many years. Matt Lincoln single-handedly turned our janky spreadsheets into an actual database and website.

There are 55 additional names on our credits page, and every one of them is worth mention.

Appendix: Conferences with Presentation Metadata

Although there are 489 conferences in the index, only 59 of them currently include presentation metadata. They are presented below, organized by conference series when applicable. Some series overlap (e.g., ACH/ALLC overlaps one year with ADHO), so the numbers will add up to higher than 59.

Conferences that aren’t part of a series

  • 1964 Conference on the Use of Computers in Humanistic Research (1)
  • 1964 Literary Data Processing Conference (1)
  • 1968 Computers and their potential applications in museums (1)
  • 1969 IBM Symposium on Introducing the Computer into the Humanities (1)
  • 1979 International Conference on Literary and Linguistic Computing (1)
  • 2019 The Arts, Knowledge, and Critique in the Digital Age in India: Addressing Challenges in the Digital Humanities (1)

Conferences that are part of a series

  • ADHO (the “DH” conference) (15)
  • ACH/ICCH (25)
  • ALLC/EADH (24)
  • Caribbean Digital (1)
  • Digital Humanities Alliance of India (DHAI) (1)
  • Digital Humanities Forum (1)
  • Encuentro de Humanistas Digitales (EHD) (1)
  • EADH (1)
  • ALLC IM/AGM (4)
  • Japanese Association for Digital Humanities Annual Conference (JADH) (1)
  • Joint ACH/ALLC (18)
  • KeystoneDH (1)

a thousand little fires

This global pandemic is asking a lot of us, and the world is contorting itself to oblige. Amidst the growing fears and burdens that accompany this deformation, many of us are turning to small acts of creativity to help keep us afloat. I’m writing a short story (it’s not very good); my partner is knitting more; a friend is finally hanging pictures on his walls; another is painting portraits.

In an effort to inject some more positivity into this chaotic moment, however small, some friends and I created an outlet for your creations. We call it a thousand little fires, and we hope you’ll contribute. Every day, we’ll post one new thing that you’ve made while dealing with temporary isolation.

If you’ve been knitting, making music, baking bread, writing poetry, building an elaborate aquarium, or otherwise creating anything that has brought you some modicum of joy, send it over. Anonymous contributions welcome. Amateur contributions welcome. Unfinished contributions welcome. Everyone is welcome.

Please help us create a community of sharing. We’ll accept pictures, stories, artwork, recipes, and anything else we can fit on the web. Contributing is easy; details available here.


Seeking New Physics

Yesterday, OpenAI announced the results of a new experiment. 1 AIs evolved to use tools to play hide-and-seek. More interestingly, they learned to exploit errors from the in-game physics engine to “cheat”, breaking physics to find their opponents.

Algorithms learning to exploit glitches to succeed at games are not uncommon. OpenAI also recently showed a video of an algorithm using a glitch in Sonic the Hedgehog save Sonic from certain death. Victoria Krakovna has collected 50 or so similar examples, going back to 1998, explained in her blog post.

But what happens when algorithms learn to exploit actual physics? A quarter of a century ago, Adrian Thompson provided evidence of just that.

In An evolved circuit, intrinsic in silicon, entwined with physics (ICES 1996), Thompson used a genetic algorithm, quite similar to the ones used to find glitches in games, to teach a bunch of computer chips to discern the difference between sounds at two different pitches: 1 kHz (low-pitch) and 10 kHz (high-pitch).

Genetic algorithms work by evolution. You give them a task, and they keep trying different approaches that either work or don’t work. The ones that work well replicate themselves with slight variations, and this goes on for many generations until the algorithm learns an efficient solution.

Genetic algorithms are easier to understand in practice than in theory, so to understand a bit better, watch the below video by Johan Eliasson:

Thompson’s genetic algorithm worked the same way, but on a physical substrate. He trained a bunch of circuit boards over 5,000 generations to essentially reconfigure themselves into pitch-discerning machines. He got a bunch that worked really well, and really quickly. But when he tried to figure out how the efficient ones worked, he came back flummoxed.

Evolution inevitably leads to a lot of redundancies, mistakes, and other stupid design choices. It’s why we have vestigial organs like appendices, why flightless birds still have wings, and why we seem to have wide swaths of “junk” DNA. It’s not that these things are useless, per se, but in the randomness of natural selection, some things tend to stray.

vestigial structure

So Thompson tried to excise the vestigial bits of circuitry that were no longer necessary, but happened to stick around after 5,000 algorithmic generations. He found the circuits that were disconnected from the circuitry that was actually solving the problem, and removed them.

After he removed the vestigial, disconnected circuitry, the most efficient algorithm slowed down considerably. Let me repeat that: the algorithms slowed down after Thompson removed vestigial parts of the circuit that had no actual effect on the algorithm. What was going on?

Thompson tried an experiment. He moved the efficient pitch-detecting algorithm to another identical circuit board. Same algorithm, identical circuit board.

The efficiency dropped by 7%.

What was happening, it turns out, is that the genetic algorithms actually learned to exploit the magnetic fields created when electrons flow through circuitry. The vestigial circuitry apparently boosted the performance of the algorithm just by existing next to the functional circuitry and emitting the appropriate physical signals.

When Thompson moved the algorithm to an identical board, the efficiency dropped because the boards weren’t actually identical, even though they were manufactured to be the same. Subtle physical differences in the circuitry actually contributed to the performance of the algorithm. Indeed, the algorithm evolved to exploit those differences.

Some scientists actually considered this a bit of a bummer. Oh no, they said, physics ruins our ability to get consistent results. But a bunch of others got quite excited.

For a while, I imagined the most exciting implications were for cognitive neuroscience.

Screenshot of C. elegans simulation representing its general view. 
From ” Towards a virtual C. Elegans: A framework for simulation and visualization of the neuromuscular system in a 3D physical environment

One theory of how thinking works is that the brain is a vast network of neurons sending signals to each other, a bit like circuits. A branch of science called connectomics is founded on abstract models of these networks.

Thompson’s research is fascinating because, if the physical embodiment of electronic circuits winds up making such a big difference, imagine the importance of the physical embodiment of neurons in a brain. Evolution spent a long time building brains, and there’s a good chance their materiality, and the adjacency of one neuron to the next, is functionally meaningful. Indeed, this has been an active area of research for some time, alongside theories of embodied cognition.

We learn from Thompson’s work not to treat brains like abstract circuits, because we can’t even treat circuits like abstract circuits.

But now, I think there’s potentially an even more interesting implication of Thompson’s results, drawing a line from it to AIs learning to exploit physics for hide-and-seek. These experiments may pave the way for a new era of physics.

A New Physics

In the history of physics, practice occasionally outpaces theory. We build experiments expecting one result, but we see another instead. Physicists spend a while wondering what the hell is going on, and then sometimes invent new kinds of physics to deal with the anomalies. We have a theory of how the world works, and then we see things that don’t align with that theory, so we replace it. 2

For example, in the 1870s, scientists began experimenting with what would become known as a Crookes tube, which emits a mysterious light under certain conditions. Trying to figure out why led to the discovery of X-rays and other phenomena.

Crooks tube, via D-Kuru,

Genetic algorithms and their siblings are becoming terrifyingly powerful. And we’ve already seen they often reach their goals by exploiting peculiarities in physics and simulated physical environments. What happens when these algorithms are given more generous leave to control their physical substrate at very basic levels?

Let’s say we ask a set of embodied algorithms to race, to get from Point A to Point B in their little robot skeletons. Let’s also say we don’t just allow them control over levers and wheels and things, but the ability to reconfigure their own bodies and print new parts of any sort, down to the nano scale. 3

I suspect, after enough generations, these racing machines will start acting quite strangely. Maybe they’ll exploit quantum tunneling, superposition, or other weird subatomic principles. Maybe they’ll latch on to macroscopic complex particle interaction effects that scientists haven’t yet noticed. I have no idea.

Nobody has any idea. We’re poised to enter a brave new world of embodied algorithms ruthlessly, indiscriminately optimizing their way into strange physics.

In short, I wonder if physical AI bots will learn to exploit what we’d perceive to be glitches in physics. If that happens, and we start trying to figure out what the heck they’re doing to get from A to B so quickly, we may have to invent entirely new areas of physics to explain them.

Although this would be an interesting future, I’m not sure it would be a good one. It may, like the gray goo hypothesis people worried about with nano-engineering, have the potential of producing apocalyptic results. What if a thoughtless algorithm, experimenting with propulsion to optimize its speed, winds up accidentally setting off an uncontrollable nuclear reaction?

I don’t suspect that will happen, but I do seriously worry what happens once the current class of learning algorithms everts into the physical world. Confined to the digital realm, we already see them wreaking havoc in unexpected ways. Recall, for example, the Amazon seller algorithms that artificially boost book prices to the point of absurdity, or the high-frequency stock trading algorithms that caused a financial panic. To say nothing of ML models that are currently in use that disadvantage particular races, genders, and other classes.

If allowed to proceed, and given the appropriate technological capacities, embodied algorithms would undoubtedly cause unintentional physical harm in their “value-free” hunt for optimization. They will cause harm in spite of any safety systems we put in place, for the same reason they may stumble on unexplored domains of physics: genetic algorithms are so very good at exploiting glitches or loopholes in systems.

I don’t know what the future holds. It’s entirely possible this is all off-base, and since I’m neither a physicist nor an algorithmic roboticist, I wouldn’t recommend putting any money behind this prediction.

All I know is that, in 1894, Albert Michelson famously said “it seems probable that most of the grand underlying principles have been firmly established and that further advances are to be sought chiefly in the rigorous application of these principles to all the phenomena which come under our notice.” And we all saw how that turned out.

With the recent results of the LHC and LIGO pretty much confirming what physicists already expected, at great expense, I’m betting the new frontier will come out of left field. I wouldn’t be so surprised if AI/ML opened the next set of floodgates.


  1. You remember OpenAI. They’re the ones who recently trained a really good language model called GPT2 and then didn’t release it on account of ethical concerns.
  2. The story is usually much more complicated than this, but that’s the best I can do in a paragraph.
  3. As far as I know this is currently implausible, but I bet it will feel more plausible in the not-too-distant future.

Releasing the Digital Humanities Literacy Guidebook

tl;dr There’s a new website called the Digital Humanities Literacy Guidebook, made for people just beginning their journeys into digital humanities, but hopefully still helpful for folks early in their career. It’s a crowdsourced resource that Carnegie Mellon University and the A.W. Mellon Foundation are offering to the world. We hope you will contribute!

Announcing the DHLG

Releasing a new website into the world is always a bit scary. Will people like it? Will they use it? Will they contribute?

The DHLG Logo

I hope the Digital Humanities Literacy Guidebook (DHLG) will help people. We made it for people who are still in their DH-curious phase, but I suspect it’ll also be helpful for folks in the first several years of their DH career.

The DHLG is an incomplete map of a territory that’s still actively growing. It doesn’t offer a definition of digital humanities; instead, it introduces by example. The site offers dozens of short videos describing DH projects, as well as lists of resources, a topical glossary, job advice, and other helpful entry-points.

We first designed the DHLG to serve our local community in Pittsburgh, for our new graduate students who aren’t yet sure if they’ll pursue DH. But a lot of this is nationally and internationally relevant, so although we built this for local needs, we’re presenting this as a gift to, well, everyone.


In that spirit, we built the DHLG using jekyll, on github, for the community to contribute to as they like, for as long as I’m around to curate contributions. We welcome new videos and topical definitions, and edits to anything and everything, especially the lists of resources like grants and journals and recurring conferences. If you think a new page or navigation structure will help the community, get in touch, and we’ll figure out a way to make it work.

I realize there’s a bit of a barrier to entry. Github is more difficult to edit than a wiki. I’m sorry. This was the best solution we could come up with that would be inexpensive, unlikely to break, widely editable, and easily curatable. If you want to add something and you don’t know github, reach out to me and I’ll try to help.

If you do know github and you want to share editorial duties with me, dealing with pull requests and the like, please do let me know. I can use the help!


The DHLG is already crowdsourced. A lot of the lists come directly from Alex Gil and Dennis Tenen’s DHNotes page at Columbia, which is a very similar effort. We’ve slightly updated some links, and added some new information, but we rely heavily on them and their initial collaborators.

The job resources section includes editorial advice written by Matthew Hannah (Purdue University), slightly modified on import. Lauren Tilton (University of Richmond) offered the initial list of DH organizations. Zoe LeBlanc (Princeton University) collaborated on curating the hiring interviews, which are not yet released but will be soon. Hannah Alpert-Abrams (Program Office in DH) wrote the entry on Black DH in the glossary.

What I’m trying to say is we’re standing on the shoulders of giants. Thank you everyone who has already contributed to the site. We certainly couldn’t have done it without you.

Who’s we? I steered the ship, and filled in all the cracks when necessary. Susan Grunewald (Pitt) wrote most of the original text and did the majority of content-related tasks, including fighting with markdown. Matt Lincoln (CMU) oversaw the technical development, which was implemented by the Agile Humanities Agency. From their team, Dean Irvine, Bill Kennedy, and Matt Milner were particularly helpful.

None of this would have been possible without the A.W. Mellon Foundation, who generously funded most DH that’s gone on at CMU over the last five years.

The DHLG is a gift from all of us to you. I hope it’s useful, and that you help us turn it from a Pittsburgh site that’s useful for others, into an internationally relevant resource for years to come.


Modeling Space Ships from Ocean Liners


I love books, and libraries. In graduate school, most of my friends were studying to be librarians. A university library now partially pays my salary. Still, I don’t know much about them, being first and foremost a historian who uses computers. A lot of smart people have written a lot of smart things about libraries that I wish I’ve read, or even know about, but I’m still working on that one. 

This is all to preface a blog post about a past and future of libraries, from my perspective, that has undoubtedly been articulated better elsewhere. Please read this post as it is intended: as a first public articulation of my thoughts that I hope my friends will read, so they can perhaps guide me to the interesting stuff already written on the subject, or explain to me why this is wrong-minded. This is not an expert opinion, and on that account I urge anyone taking it seriously as such to, erm, stop.


We are closer in time to Jesus Christ than he was to the first documents written on paper-like materials. Our species has, collectively, had a lot of time to figure them out. After four thousand years, papery materials and the apparatuses around them have co-evolved into something akin to a natural ecosystem. Ink, page, index, spine, shelf, catalog, library building all fit together for the health of the collective.

This efficient system is the most consequential prosthesis for memory and discovery that humankind ever created. After paper and its cousins (papyrus, vellum, etc.) became external vessels for knowledge, their influence on religion, law, and science—on control and freedom—cannot be overestimated. 

The system’s success has as much to do with the materials themselves as the socio-technical-architectural apparatuses around them. They allowed the written word to become portable, reproducible, findable, preservable, and accessible. 

Chief among these apparatuses, of course, is the library. Librarie (n.): a collection of books. Liber (n.): the inner bark of a tree.

A library’s shelves are perfectly sized to fit the standard dimensions of books (and vice-versa). Climate control keeps the words shelf-stable. Neatly ordered rows and catalog systems help us find the right words, and a combination of personnel and inventory technologies allow us to borrow them for as long as we need, and then return them for someone else’s use. Libraries physically centralize books, allowing us access to great swaths of memory without needing to leave a single building. This centralization makes everything more efficient, especially when it comes to expert knowledge in the form of librarians. A few of these professionals can keep the whole system running smoothly, and ensure anyone who walks in the door will find exactly what they need.

Image result for bodleian library layout century
Plan of the Bodleian Library, Oxford (from Geoffrey Tyack, Bodleian Library, University of Oxford: A History [Oxford: Oxford University Press, 2000], 28. Bodleian Library, University of Oxford, R. Ref. 357/3).

It’s no accident the beating heart of the university has always been its library. It has, traditionally, been one of the largest draws of an institution: join our faculty, and you’ll have easy access to all the knowledge that’s ever been written down. Through libraries, scholars found their gateway to entire academic world, and could join a conversation that spanned geography and time. It’s not everything a researcher needs, for sure—chemists need glassblowers and fume hoods and reagents—but without it, a university traditionally cannot function.

This is changing, because our reliance on paper is changing. Money, science, and news are going digital. We’re not getting rid of paper—people still read books, use toilet paper, and ship things in boxes—but its direct role in knowledge production and circulation has shrunk dramatically over the last several decades. Everything from lab notes to journals are moving online, a trend as true in the humanities as it is in the sciences. Humanists still use printed books en masse, but increasingly the physical page is the object of study more than the means of conversation, indicating a subtle but important shift in how the library is being used.


Our shifting relationship to paper has led to a crisis in the university library, an institution that evolved over thousands of years around the written word. As researchers increasingly turn to Google for pretty much everything, books are dropping in circulation, and the stacks are emptying out of people. Libraries, once the beating heart of the university, are scrambling to remain so. 

As I see it, the university library has two options: 

  1. Become something else to retain its centrality, or 
  2. Continue doing the papery tasks it evolved to do very well, as that task’s relevance slowly diminishes (but will, I hope and suspect, never disappear).

My lay impression, as an outsider until recently, is that most well-respected libraries are trying to do both, while institutional pressures are pushing to favor option #1. This pressure, in part, is because universities’ successes were tied to the success of libraries, so universities need libraries to evolve if they hope the institutions to maintain the same relationship.

And option #1 is doing pretty well, it seems. The same architectural features that allowed us to centralize books (namely big, climate-controlled buildings) are also good for other things: meeting rooms, cafes, makerspaces, and the like. Libraries that clear out books for this get a lot of new feet through their doors, though the institutions are perhaps straying a bit from why they were so important in the first place.

James B. Hunt Jr. Library,

Libraries are also making changes that hew spiritually closer to the papery tasks of yore, by becoming virtual information hubs. Through online catalogs/search, VPN-enabled digital subscriptions, data repositories, and the like, libraries are offering the same sorts of services they used to, connecting researchers to the larger scholarly world, without the need of a physical building. With the exception of negotiated subscriptions to digital journals, these efforts appear slightly less successful. 1 In large part this is because libraries are often playing catch-up to tech giants with massive budgets. 

To bridge the gap between the physical and the digital, libraries wind up paying large subscription fees to tech vendors which provide them search interfaces, hosting services, and other digital information solutions. Libraries do this largely because they were honed for thousands of years around written media, and are ill-equipped to handle most digital tasks themselves. 2 

Now libraries are paying outside vendors remarkable sums of money every year so they can play the same informational role they’ve always played, as the ground shifts beneath them. And even when this effort succeeds, as it occasionally does, it’s not clear that this informational role is as centrally valued in the university as it used to be. When new faculty choose where to work, I rarely hear them considering a library’s digital services in their decision, as important as they might be. The one exception is journal subscriptions, and with the Open Access movement and sci-hub, even access to articles seem decreasingly on a researcher’s mind.


Don’t get me wrong. I believe we desperately need an apparatus that does for digital information what libraries do for the written word. Whereas we have thousands of years of experience dealing with geographically situated collections of knowledge, with the preservation, organization, and access of written words, we have little such experience with respect to digitally-embedded knowledge. It’s still difficult to find, and nearly impossible to preserve. We don’t have robust systems for allocating or evaluating trust, and the economic and legal apparatuses around digital knowledge are murky, disputed, and often deeply immoral.

Whatever institution evolves to deal with digital knowledge won’t just be the beating heart of the university, it will be an organizing body for the world. Specifically because everything is so interconnected and geographically diffuse, its eventual home will not be a university (unless universities, too, lose their tethers to geography). And because of this reach and the power it implies, such an institution will be incredibly difficult to form, both politically and technologically. It may take another few thousand years to get it right, if we have that long.

But perhaps we can start at home, with universities or university consortia. That’s how we got the internet to begin with, after all, though as it grew it privatized away from universities. Today, the web is mostly hosted by big tech companies like Amazon (originally a bookseller, no surprise there), discovered and reached by other big tech companies like Google, and accessed through infrastructure provided by other other big tech companies, like AT&T. When libraries plug into this world, they do so through external tech vendors, which plug directly into for-profit publishing houses like Elsevier. Those publishing houses, too, squeeze universities out of quite a lot of money.

The economies and politics of this system are grossly exploitative. They often undermine privacy, intellectual property, individual agency, and financial independence at every angle. The infrastructure upon which scholars works and across which they communicate are constant points of friction against the ideals of academia. 

Publishing science, for example, is ostensibly about making science public, in order to coordinate a global conversation. In an era of inexpensive communication, however, many scientific publishers spend considerable resources blocking the availability of scientific publications in order to secure their business’s financial viability. This makes sense for publishers, but doesn’t quite make sense for science. 3

Perhaps universities could band together to construct institutions to short circuit this chain, from Amazon to Google to AT&T to Elsevier to Ex Libris. Perhaps we can construct an infrastructure for research that doesn’t barter on privacy, whose mission is the same as the mission of universities themselves. Universities are one of the few types of institutions that can afford to focus on long-term goals rather than short-term needs. 4 If there were a federated, academic alternative to our quagmire of an information economy, perhaps that would be the university’s “killer app”, the reason scholars decide to spend their time at one university over another, or in academia rather than a corporate research unit. We figured out eduroam and interlibrary loans, maybe we can figure out this too. 

Perhaps the answer to “what institution can be the necessary beating heart of centers of knowledge for the next 2,000 years?” is the same as the answer to “how can we organize information in a digital world?”. Or maybe it isn’t. 5 The second question is important enough that it’s worth a shot regardless, and universities as well as everyone else should be trying to figure it out.

But this post is about libraries, with tree pulp ground into their etymology. Libraries are so very good at solving paper problems, and if they cease to function in that capacity, we’ll have a lot of paper problems on our hands. Paper isn’t disappearing anytime soon, but institutional pressures to keep libraries as the heart of the university are the same pressures pushing them away from paper. So now, libraries are trying to solve problems they’re not terribly well-equipped to solve, which is why they rely so heavily on vendors, while the problems they are good at solving move further away from their core. This worries me.

Image result for paper piles

I’m certainly not implying here librarians aren’t good at computers, or digital information. As of recently, I am a librarian who happens to be a digital information professional, and I think I’m reasonably good at it. If I am good at it, it’s because I’ve learned from the small army of expert information professionals now employed in libraries.

The issues I’m raising aren’t ones of personnel, but of institutional function. I’m not convinced that (1) libraries being the best versions of themselves, (2) libraries being diffuse information hubs, and (3) libraries continuing to function as the infrastructure that makes a university successful are compatible goals. Or, even if they are compatible goals, that a single institution is the best choice for pursuing all three at once. And it certainly seems that our vendor-heavy way of going about things might be a necessary outcome of this tripartite split, which heavily benefits the short-term at the expense of the long-term. 

I’m at somewhat of a personal impasse. I find wordhouses and information hubs and academic infrastructure to be important, and I’d like to contribute to all three. As a librarian in a modern university library, I can do that. I seem to have evolved to fit well inside a university library, just as university libraries evolved to fit well around books. There are a lot of librarians who are perfectly shaped for the institutions in which we find ourselves. But I continue to wonder, are our institutions the right shape for the future we need to build, or are we trying to model space ships from ocean liners?

Caveats #2

One critique to this post came early, in the form of a tweet. I’m sharing it here to ensure readers take the most skeptical possible eye to my post:

Tweet critique, well-placed.

The name is redacted because I don’t want folks who disagree with it to project any negativity on the original poster. Their point is well-taken, and I hope everyone reading this blog post will take it with the grain of salt it deserves.


  1. Slightly less successful doesn’t mean not successful! A lot of these projects do quote well.
  2. This is also due to a serious lack of funding
  3. I’m a historian of science, and I’ll say the story is a good deal more complicated than this, but for the purposes of this post let’s keep it at that.
  4. One astute reply suggests this isn’t how universities actually function. I’d agree with that. I don’t believe universities do function like this, but that they ought to be able to do, of any institution out there. Part of the reason we’re in this mess to begin with is because of rampant academic short-termism.
  5. This possibility is one it seems more people need to seriously reckon with.

The Route of a Text Message

[Note: Find the more polished, professionally illustrated version of this piece at Motherboard|Vice!]

This is the third post in my full-stack dev (f-s d) series on the secret life of data. This installment is about a single text message: how it was typed, stored, sent, received, and displayed. I sprinkle in some history and context to break up the alphabet soup of protocols, but though the piece gets technical, it should all be easily understood.

The first two installments of this series are Cetus, about the propagation of errors in a 17th century spreadsheet, and Down the Rabbit Hole, about the insane lengths one occasionally needs to go through to track down the source of a dataset.

A Love Story

My leg involuntarily twitches with vibration—was it my phone, or just a phantom feeling?—and a quick inspection reveals a blinking blue notification. “I love you”, my wife texted me. I walk downstairs to wish her goodnight, because I know the difference between the message and the message, you know?

It’s a bit like encryption, or maybe steganography: anyone can see the text, but only I can decode the hidden data.

My translation, if we’re being honest, is just one extra link in a remarkably long chain of data events, all to send a message (“come downstairs and say goodnight”) in under five seconds across about 40 feet.

The message presumably began somewhere in my wife’s brain and somehow ended up in her thumbs, but that’s a signal for a different story. Ours begins as her thumb taps a translucent screen, one letter at a time, and ends as light strikes my retinas.

Through the Looking Glass

With each tap, a small electrical current passes from the screen to her hand. Because electricity flows easily through human bodies, sensors on the phone register a change in voltage wherever her thumb presses against the screen. But the world is messy, and the phone senses random fluctuations in voltage across the rest of the screen, too, so an algorithm determines the biggest, thumbiest-looking voltage fluctuations and assumes that’s where she intended to press.

Figure 0. Capacitive touch.

So she starts tap-tap-tapping on the keyboard, one letter at a time.


She’s not a keyboard swiper (I am, but somehow she still types faster than me). The phone reliably records the (x,y) coordinates of each thumbprint and aligns it with the coordinates of each key on the screen. It’s harder than you think; sometimes her thumb slips, yet somehow the phone realizes she’s not trying to swipe, that it was just a messy press.

Deep in the metal guts of the device, an algorithm tests whether each thumb-shaped voltage disruption moves more that a certain number of pixels, called touch slop. If the movement is sufficiently small, the phone registers a keypress rather than a swipe.

Fig 1. Android’s code for detecting ‘touch slop’. Notice the developers had my wife’s gender in mind.

She finishes her message, a measly 10 characters of her allotted 160.

The allotment of 160 characters is a carefully chosen number, if you believe the legend: In 1984, German telephone engineer Friedhelm Hillebrand sat at his typewriter and wrote as many random sentences as came to his mind. His team then looked at postcards and telex messages, and noticed most fell below 160 characters. “Eureka!”, they presumably yelled in German, before setting the character limit of text messages in stone for the next three-plus decades.

Character Limits & Legends

Legends rarely tell the whole story, and the legend of SMS is no exception. Hillebrand and his team hoped to relay messages over a secondary channel that phones were already using to exchange basic information with their local stations.

Signalling System no. 7 (SS7) are a set of protocols used by cell phones to stay in constant contact with their local tower; they need this continuous connection to know when to ring, to get basic location tracking, to check for voicemail, and communicate other non-internet reliant messages. Since the protocol’s creation in 1980, it had a hard limit of 279 bytes of information. If Hillebrand wanted text messages to piggyback on the SS7 protocol, he had to deal with this pretty severe limit.

Normally, 279 bytes equals 279 characters. A byte is eight bits (each bit is a 0 or 1), and in common encodings, a single letter is equivalent to eight 0s and 1s in a row.

‘A’ is

0100 0001

‘B’ is

0100 0010

‘C’ is

0100 0011

and so on.

Unfortunately, getting messages across the SS7 protocol isn’t a simple matter of sending 2,232 (that’s 279 bytes at 8 bits each) 0s or 1s through radio signals from my phone to yours. Part of that 279-byte signal needs to contain your phone number, and part of it needs to contain my phone number. Part of it needs to let the cell tower know “hey, this is a message, not a call, don’t ring the phone!”.

By the time Hillebrand and his team finished cramming all the necessary contextual bits into the 279-byte signal, they were left with only enough space for 140 characters at 1 byte (8 bits) a piece, or 1,120 bits.

But what if they could encode a character in only 7 bits? At 7 bits per character, they could squeeze 160 (1,140 / 7 = 160) characters into each SMS, but those extra twenty characters demanded a sacrifice: fewer possible letters.

An 8-bit encoding allows 256 possible characters: lowercase ‘a’ takes up one possible space, uppercase ‘A’ another space, a period takes up a third space, an ‘@’ symbol takes up a fourth space, a line break takes up a fifth space, and so on up to 256. To squeeze an alphabet down to 7 bits, you need to remove some possible characters: the 1/2 symbol (½), the degree symbol (°), the pi symbol (π), and so on. But assuming people will never use those symbols in text messages (a poor assumption, to be sure), this allowed Hillebrand and his colleagues to stuff 160 characters into a 140-byte space, which in turn fit neatly into a 279-byte SS7 signal: exactly the number of characters they claim to have discovered was the perfect length of a message. (A bit like the miracle of Hanukkah, if you ask me.)

Fig 2. The GSM-7 character set.

So there my wife is, typing “I love you” into a text message, all the while the phone converts those letters into this 7-bit encoding scheme, called GSM-7.

“I” (notice it’s at the intersection of 4x and x9 above) =


Spacebar (notice it’s at the intersection of 2x and x0 above) =


“l” =


“o” =


and so on down the line.

In all, her slim message becomes:

49 20 6C 6F 76 65 20 79 6F 75 

(10 bytes combined). Each two-character code, called a hex code, is one 8-bit chunk, and together it spells “I love you”.

But this is actually not how the message is stored on her phone. It has to convert the 8-bit text to 7-bit hex codes, which it does by essentially borrowing the remaining bit at the end of every byte. The math is a bit more complicated than is worth getting into here, but the resulting message appears as

49 10 FB 6D 2F 83 F2 EF 3A 

(9 bytes in all) in her phone.

When my wife finally finishes her message (it takes only a few seconds), she presses ‘send’ and a host of tiny angels retrieve the encoded message, flutter their invisible wings the 40 feet up to the office, and place it gently into my phone. The process isn’t entirely frictionless, which is why my phone vibrates lightly upon delivery.

The so-called “telecommunication engineers” will tell you a different story, and for the sake of completeness I’ll relay it to you, but I wouldn’t trust them if I were you.


The engineers would say that, when the phone senses voltage fluctuations over the ‘send’ button, it sends the encoded message to the SIM card (that tiny card your cell provider puts in your phone so it knows what your phone number is), and in the process it wraps it in all sorts of useful contextual data. By the time it reaches my wife’s SIM, it goes from a 140-byte message (just the text) to a 176-byte message (text + context).

The extra 36 bytes are used to encode all sorts of information, seen below.

Fig 3. Here, bytes are called octets (8 bits). Counting all possible bytes yields 174 (10+1+1+12+1+1+7+1+140). The other two bytes are reserved for some SIM card bookkeeping.

The first ten bytes are reserved for the telephone number (service center address, or SCA) of the SMS service center (SMSC), tasked with receiving, storing, forwarding, and delivering text messages. It’s essentially a switchboard: my wife’s phone sends out a signal to the local cell tower and gives it the number of the SMSC, which forwards her text message from the tower to the SMSC. The SMSC, which in our case is operated by AT&T, routes the text to the mobile station nearest to my phone. Because I’m sitting three rooms away from my wife, the text just bounces back to the same mobile station, and then to my phone.

Fig 4. SMS cellular network

The next byte (PDU-type) encodes some basic housekeeping on how the phone should interpret the message, including whether it was sent successfully, whether the carrier requests a status report, and (importantly) whether this is a single text or part of a string of connected messages.

The byte after the PDU-Type is the message reference (MR). It’s a number between 1 and 255, and is essentially used as a short-term ID number to let the phone and the carrier know which text message it’s dealing with. In my wife’s case the number is set to 0, because her phone has its own message ID system independent of this particular file.

The next twelve bytes or so are reserved for the recipient’s phone number, called the destination address (DA). With the exception of the 7-bit letter character encoding I mentioned earlier, that helps us stuff 160 letters into a 140-character space, the phone number encoding is the stupidest, most confusing bits you’ll encounter in this SMS. It’s called reverse nibble notation, and it reverses every other digit in a large number. (Get it? Part of a byte is a nibble, hahahahaha, nobody’s laughing, engineers.)

My number, which is usually 1-352-537-8376, is logged in my wife’s phone as:


The 1-3 is represented by


The 52 is represented by


The 53 is represented by


The 7-8 is represented by


The 37 is represented by


And the 6 is represented by…


Where the fuck did the ‘f’ come from? It means it’s the end of the phone number, but for some awful reason (again, reverse nibble notation) it’s one character before the final digit.

It’s like pig latin for numbers.

tIs'l ki eip galit nof runbmre.s

But I’m not bitter.

[Edit: Sean Gies points out that reverse nibble notation is an inevitable artifact of representing 4-bit little-endian numbers in 8-bit chunks. That doesn’t invalidate the above description, but it does add some context for those who know what it means, and makes the decision seem more sensible.]

The Protocol Identifier (PID) byte is honestly, at this point, mostly wasted space. It takes about 40 possible values, and it tells the service provider how to route the message. A value of


means my wife is sending “I love you” to a fax machine; a value of


means she’s sending it to a voice line, somehow. Since she’s sending it as an SMS to my phone, which receives texts, the PID is set to


(Like every other text sent in the modern world.)

Fig 5. Possible PID Values

The next byte is the Data Coding Scheme (DCS, see this doc for details), which tells the carrier and the receiving phone which character encoding scheme was used. My wife used GSM-7, the 7-bit alphabet I mentioned above that allows her to stuff 160 letters into a 140-character space, but you can easily imagine someone wanting to text in Chinese, or someone texting a complex math equation (ok, maybe you can’t easily imagine that, but a guy can dream, right?).

In my wife’s text, the DCS byte was set to


meaning she used a 7-bit alphabet, but she may have changed that value to use an 8- or 16-bit alphabet, which would allow her many more possible letters, but a much smaller space to fit them. Incidentally, this is why when you text emoji to your friend, you have fewer characters to work with.

There’s also a little flag in the DCS byte that tells the phone whether to self-destruct the message after sending it, Mission Impossible style, so that’s neat.

The validity period (VP) space can take up to seven bytes, and sends us into another aspect of how text messages actually work. Take another look at Figure 4, above. It’s okay, I’ll wait.

When my wife finally hits ‘send’, the text gets sent to the SMS Service Center (SMSC), which then routes the message to me. I’m upstairs and my phone is on, so I receive the text in a handful of seconds, but what if my phone were off? Surely my phone can’t accept a message when it’s not receiving any power, so the SMSC has to do something with the text.

If the SMSC can’t find my phone, my wife’s message will just bounce around in its system until the moment my phone reconnects, at which point it sends the text out immediately. I like to think of the SMSC continuously checking every online phone to see if its mine like a puppy waiting for its human by the door: is that smell my human? No. Is that smell my human? No. Is this smell my human? YESYESJUMPNOW.

The validity period (VP) bytes tell the carrier how long the puppy will wait before it gets bored and finds a new home. It’s either a timestamp or a duration, and it basically says “if you don’t see the recipient phone pop online in the next however-many days, just don’t bother sending it.” The default validity period for a text is 10,080 minutes, which means if it takes me more than seven days to turn my phone back on, I’ll never receive her text.

Because there’s often a lot of empty space in an SMS, a few bits here or there are dedicated to letting the phone and carrier know exactly which bytes are unused. If my wife’s SIM card expects a 176-byte SMS, but because she wrote an exceptionally short message it only receives a 45-byte SMS, it may get confused and assume something broke along the way. The user data length (UDL) byte solves this problem: it relays exactly how many bytes the text in the text message actually take up.

In the case of “I love you”, the UDL claims the subsequent message is 9 bytes. You’d expect it to be 10 bytes, one for each of the 10 characters in


but because each character is 7 bits rather than 8 bits (a full byte), we’re able to shave an extra byte off in the translation. That’s because 7 bits * 10 characters = 70 bits, divided by 8 (the number of bits in a byte) = 8.75 bytes, rounded up to 9 bytes.

Which brings us to the end of every SMS: the message itself, or the UD (User Data). The message can take up to 140 bytes, though as I just mentioned, “I love you” will pack into a measly 9. Amazing how much is packed into those 9 bytes—not just the message (my wife’s presumed love for me, which is already difficult enough to compress into 0s and 1s), but also the message (I need to come downstairs and wish her goodnight). Those bytes are:

49 10 FB 6D 2F 83 F2 EF 3A.

In all, then, this is the text message stored on my wife’s SIM card:

SCA[1-10]-PDU[1]-MR[1]-DA[1-12]-DCS[1]-VP[0, 1, or 7]-UDL[1]-UD[0-140]

00 - 11 - 00 - 07 31 25 35 87 73 F6 - ?? 00 ?? - ?? - 09 - 49 10 FB 6D 2F 83 F2 EF 3A

(Note: to get the full message, I need to do some more digging. Alas, you only see most of the message here, hence the ??s.)

Waves in the Æther

Somehow [he says in David Attenborough’s voice], the SMS must now begin its arduous journey from the SIM card to the nearest base station.  To do that, my wife’s phone must convert a string of 176 bytes to the 279 bytes readable by the SS7 protocol, convert those digital bytes to an analog radio signal, and then send those signals out into the æther at a frequency of somewhere between 800 and 2000 megahertz. That means each wave is between 6 and 14 inches from one peak to the next.

Fig 6. Wavelength

In order to efficiently send and receive signals, antennas should be no smaller than half the size of the radio waves they’re dealing with. If cell waves are 6 to 14 inches, their antennas need to be 3-7 inches. Now stop and think about the average height of a mobile phone, and why they never seem to get much smaller.

Through some digital gymnastics that would take entirely too long to explain, suddenly my wife’s phone shoots a 279-byte information packet containing “I love you” at the speed of light in every direction, eventually fizzling into nothing after about 30 miles.

Well before getting that far, her signal strikes the AT&T HSPA Base Station ID199694204 LAC21767. This base transceiver station (BTS) is about 5 blocks from my favorite bakery in Hazelwood, La Gourmandine, and though I was able to find its general location using an android app called OpenSignal, the antenna is camouflaged beyond my ability to find it.

The really fascinating bit here is that it reaches the base transceiver station at all, given everything else going on. Not only is my wife texting me “I love you” in the 1000ish mhz band of the electromagnetic spectrum; tens of thousands of other people are likely talking on the phone or texting within the 30 mile radius around my house, beyond which cell signals disintegrate. On top of that, a slew of radio and TV signals are jostling for attention in our immediate airspace, alongside visible light bouncing this way and that, to name a few of the many electromagnetic waves that seem like they ought to be getting in the way.

As Richard Feynman eloquently put it in 1983, it’s a bit like the cell tower is a little blind bug resting gently atop the water on one end of a pool, and based only on the frequency and direction of waves that cause it to bounce up and down, it’s able to reconstruct who’s swimming and where.

Feynman discussing waves.

In part due to the complexity of competing signals, each base transceiver station generally can’t handle more than 200 active users (using voice or data) at a time. So “I love you” pings my local base transceiver station, about a half a mile away, and then shouts itself into the void in every direction until it fades into the noise of everyone else.


I’m pretty lucky, all things considered. Were my wife and I on different cell providers, or were we in different cities, the route of her message to me would be a good deal more circuitous.

My wife’s message is massaged into the 279-byte SS7 channel, and sent along to the local base transceiver station (BTS) near the bakery. From there, it gets routed to the base station controller (BSC), which is the brain of not just our antenna, but several other local antennas besides. The BSC flings the text to AT&T Pittsburgh’s mobile switching center (MSC), which relies on the text message’s SCA (remember the service center address embedded within every SMS? That’s where this comes in) to get it to the appropriate short message service center (SMSC).

This alphabet soup is easier to understand with the diagram from figure 7; I just described steps 1 and 3. If my wife were on a different carrier, we’d continue through steps 4-7, because that’s where the mobile carriers all talk to each other. The SMS has to go from the SMSC to a global switchboard and then potentially bounce around the world before finding its way to my phone.

Fig 7. SMS routed through a GSM network.

But she’s on AT&T and I’m on AT&T, and our phones are connected to the same tower, so after step 3 the 279-byte packet of love just does an about-face and returns through the same mobile service center, through the same base station, and now to my phone instead of hers. A trip of a few dozen miles in the blink of an eye.


Buzzzzz. My pocket vibrates. A notification lets me know an SMS has arrived through my nano-SIM card, a circuit board about the size of my pinky nail. Like Bilbo Baggins or any good adventurer, it changed a bit in its trip there and back again.

Fig 8. Received message, as opposed to sent message (figure 3).

Figure 8 shows the structure of the message “I love you” now stored on my phone. Comparing figures 3 and 8, we see a few differences. The SCA (phone number of the short message service center), the PDU (some mechanical housekeeping), the PID (phone-to-phone rather than, say, phone-to-fax), the DCS (character encoding scheme), the UDL (length of message), and the UD (the message itself) are all mostly the same, but the VP (the text’s expiration date), the MR (the text’s ID number), and the DA (my phone number) are missing.

Instead, on my phone, there are two new pieces of information: the OA (originating address, or my wife’s phone number), and the SCTS (service center time stamp, or when my wife sent the message).

My wife’s phone number is stored in the same annoying reverse nibble notation (like dyslexia but for computers) that my phone number was stored in on her phone, and the timestamp is stored in the same format as the expiration date was stored in on on her phone.

These two information inversions make perfect contextual sense. Her phone needed to reach me by a certain time at a certain address, and I now need to know who sent the message and when. Without the home address, so to speak, I wouldn’t know whether the “I love you” came from my wife or my mother, and the difference would change my interpretation of the message fairly significantly.

Through a Glass Brightly

In much the same way that any computer translates a stream of bytes into a series of (x,y) coordinates with specific color assignments, my phone’s screen gets the signal to render

49 10 FB 6D 2F 83 F2 EF 3A

on the screen in front of me as “I love you” in backlit black-and-white. It’s an interesting process, but as it’s not particularly unique to smartphones, you’ll have to look it up elsewhere. Let’s instead focus on how those instructions become points of light.

The friendly marketers at Samsung call my screen a Super AMOLED (Active Matrix Organic Light-Emitting Diode) display, which is somehow both redundant and not particularly informative, so we’ll ignore unpacking the acronym as yet another distraction, and dive right into the technology.

There are about 330,000 tiny sources of light, or pixels, crammed inside each of my phone screen’s 13 square inches. For that many pixels, each needs to be about 45µm (micrometers) wide: thinner than a human hair. There’s 4 million of ‘em in all packed into the palm of my hand.

But you already know how screens work. You know that every point of light, like the Christian God or Musketeers (minus d’Artagnan), is always a three-for-one sort of deal. Red, green, and blue combine to form white light in a single pixel. Fiddle with the luminosity of each channel, and you get every color in the rainbow. And since 4 x 3 = 12, that’s 12 million tiny sources of light sitting innocently dormant behind my black mirror, waiting for me to press the power button to read my wife’s text.

Fig 9. The subpixel array of a Samsung OLED display.

Each pixel, as the acronym suggests, is an organic light-emitting diode. That’s fancy talk for an electricity sandwich:

Fig 10. An electricity sandwich.

The layers aren’t too important, beyond the fact that it’s a cathode plate (negatively charged), below a layer of organic molecules (remember back to highschool: it’s just some atoms strung together with carbon), below an anode plate (positively charged).

When the phone wants the screen on, it sends electrons from the cathode plate to the anode plate. The sandwiched molecules intercept the energy, and in response they start emitting visible light, photons, up through the transparent anode, up through the screen, and into my waiting eyes.

Since each pixel is three points of light (red, green, and blue), there’s actually three of these sandwiches per pixel. They’re all essentially the same, except the organic molecule is switched out: poly(p-phenylene) for blue light, polythiophene for red light, and poly(p-phenylene vinylene) for green light. Because each is slightly different, they shine different colors when electrified.

(Fun side fact: blue subpixels burn out much faster, due to a process called “exciton-polaron annihilation”, which sounds really exciting, doesn’t it?)

All 4 million pixels are laid out on an indexed matrix. An index works in a computer much the same way it works in a book: when my phone wants a specific pixel to light a certain color, it looks that pixel up in the index, and then sends a signal to the address it finds. Let there be light, and there was light.

(Fun side fact: now you know what “Active Matrix Light-Emitting Diode” means, and you didn’t even try.)

My phone’s operating system interprets my wife’s text message, figures out the shape of each letter, and maps those shapes to the indexed matrix. It sends just the right electric pulses through the Super AMOLED screen to render those three little words that have launched ships and vanquished curses.

The great strangeness here is that my eyes never see “I love you” in bright OLED lights; it appear on the screen black-on-white. The phone creates the illusion of text through negative space, washing the screen white by setting every red, green, & blue to maximum brightness, then turning off the bits where letters should be. Its complexity is offensively mundane.

Fig 11. Negative space.

In displaying everything but my wife’s text message, and letting me read it in the gaps, my phone succinctly betrays the lie at the heart of the information age: that communication is simple. Speed and ease hide a mountain of mediation.

And that mediation isn’t just technical. My wife’s text wouldn’t have reached me had I not paid the phone bill on time, had there not been a small army of workers handling financial systems behind the scenes. Technicians keep the phone towers in working order, which they reach via a network of roads partially subsidized by federal taxes collected from hundreds of millions of Americans across 50 states. Because so many transactions still occur via mail, if the U.S. postal system collapsed tomorrow, my phone service would falter. Exploited factory workers in South America and Asia assembled parts in both our phones, and exhausted programmers renting expensive Silicon Valley closets are as-you-read-this pushing out code ensuring our phones communicate without interruption.

All of this underneath a 10-character text. A text which, let’s be honest, means much more than it says. My brain subconsciously peels back years of interactions with my wife to decode the message appearing on my phone, but between her and me there’s still a thicket of sociotechnical mediation, a stew of people and history and parts, that can never be untangled.

The Aftermath

So here I am, in the office late one Sunday night. “I love you,” my wife texted from the bedroom downstairs, before the message traversed 40 or so feet to my phone in a handful of seconds. I realize what it means: it’s time to wish her goodnight, and perhaps wrap up this essay. I tap away the last few words, now slightly more cognizant of the complex layering of miles, signals, years of history, and human sweat it took to keep my wife from having to shout upstairs that it’s about damn time I get some rest.

Thanks to Christopher Warren, Vika Zafrin, and Nechama Weingart for comments on earlier drafts.


The Center for Midnight

How many people do you need? Is an artistic movement only a movement as a collective? Can one person alone carry the melody?

Over the course of 12 hours between October 29th and October 31st, a pop-up writing collective of artists, scholars, and algorithms uncovered a fragmentary history of the Center for Midnight, an imagined artistic movement of the late twentieth century.

We named ourselves the Midnight Society, though our membership was as difficult to enumerate as our goals. About thirty participants wandered in and out of the STUDIO for Creative Inquiry at Carnegie Mellon University over those three evenings, contributing words or technical expertise or editorial opinions or halloween candy, some for moments and others for hours. Members arrived from as far as the Atlantic and the Pacific, though the heart of our collective rested in Pittsburgh, the mind in Robin Sloan, and the words in a neural network taught to read by biographers and comedians.

RNN example

The Center for Midnight began, as so many things do, with a blank page and a blinking cursor.

When we first invited bestselling author and technologist Robin Sloan to Pittsburgh, we knew we wanted him for an extended artist’s residency, but we didn’t have an end goal in sight. His first book, Mr. Penumbra’s 24-Hour Bookstore, has been called a love letter to digital humanities (by me, among others), so you can see why a digital humanities center like ours would be interested in bringing him to town.

Inspiration came from his most recent experiments on human/computer collaborative writing. Sloan is developing a sort of cyborg text editor, an algorithmic cure for writer’s block, a machine that reads what you’ve written so far and offers a few words that might come next. It does so by reaching into its model of language, a recurrent neural network trained on whatever collection of text seems appropriate, and trying to find sensible endings to the sentence you began.

Together with the Frank-Ratchye STUDIO for Creative Inquiry and the Department of English, Carnegie Mellon University’s dSHARP Center for Innovative Digital Initiatives decided to invite Sloan to lead a three-day experiment of generative fiction. We would assemble a multi-talented team of artists and scholars from around Pittsburgh and elsewhere, connect them with Robin Sloan’s generative text editor, and attempt to assemble a readable short story in the space of 12 hours. The results exceeded our high expectations.

Center for Midnight

Before the workshop, we established a few ground rules. Participants would be capped at a dozen (we failed at keeping to that rule, to our benefit), would need to commit to being available every day (also failed, and also worked out fine), and would need to come with diverse skills and backgrounds (thankfully, finally, a success). More than four hours of writing a day would be a slog, and most people had daytime commitments, so we settled on 4-8pm, Monday through Wednesday, with copious food provided.

Inspired by David Markson’s The Last Novel, Robin decided to assemble the short story in 1-3 sentence snippets, which would allow people to contribute as much or as little as they were able. The story would be about a yet-unnamed artistic movement, so Robin pre-trained his recurrent neural network on the biographies of artists.

Day 1

When everyone arrived on the afternoon of October 29th, the house was surprisingly packed; well over the dozen people I’d hand-selected, with more trickling in as the night went on. I guess word had gotten out. Our temporary base, the STUDIO for Creative Inquiry, acts as a home to rotating students, artists, and other ne’er-do-wells; its residents filled out our rogues’ gallery.

We spent a good while introducing ourselves, which proved important. By the end of the workshop, though our numbers had thinned, we wound up leaning on each person’s interests and skills for the tasks required to finish the story.

Robin introduced the premise, that each of us would use the algorithmic collaboration tool to assemble snippets of text about some fictional artist or artistic theme, and dump our results into a collective google doc. We produced about 80 snippets in all, ranging from a handful of words to over 300, each appended with a brief process note from the author:

  • “I have no idea if Maabundas is a real word or if it was generated nonsense. Either way, it sounds cool.”
  • “I cackled.”
  • “Following up on my magical steer from a previous text chunk. This required a bit of guidance. I liked that it made me think of how I wanted certain bits to sound by generating text that I could respond to.”

Over the course of the night, we brainstormed other documents on which to train the neural network, and we settled on a bunch of biographies from the Harlem Renaissance, a corpus of stand-up comedy scripts, and the collected biographies of art collectors.

At the end of the evening, each of us picked a favorite line or phrase to share with the group, including:

  • “The institutionalized monks of Yann Hirsch”
  • “The Center for Midnight”
  • “The golden age of lithography”
  • “He wandered down to the beach, watching as the anti-capitalist, plant-themed novelist and short story writer wrestled with filmmaker Benjamin John O’Toole in a drunken bout of delirium.”

Stuffed with Mediterranean food and halloween candy, we went our separate ways, while Robin continued to work.

Day 2

A 6×6 wall of seemingly blank post-its awaited us in the STUDIO. Each had on its sticky side a unique short instruction from Robin, defining a period, a subject, and a method: inception / artistic work / generate text; conflict / artist / mine text; development / relationship / generate text.


We also arrived to a one-page description, assembled by Robin from yesterday’s favorite lines:

Methods: (primarily but not exclusively) lithography and embroidery
Obsessed with: the sea, aging, and time

Inception → Development → Conflict → Dissolution

Dramatis personae
Strongly consider mentioning one or more of these:
-Okyanica-La Trail
-Minerva Black
-The filmmaker Benjamin John O'Toole
-Territoria Migraine ← yep that's a name
-The institutionalized monks of Yann Hirsch

Today’s assignment was to uncover the Center for Midnight’s story, which began in 1967 (the average year from yesterday’s google doc) and ended in 1978 (the median year). We each took a sticky note in turn, read our instructions, and got to work writing about the artists, artworks, and relationships that circled the Center at every stage of its short life. When finished, we deposited the text in a new google doc, exchanged stickies, and started all over again.

The Midnight Society, as I started thinking of our team, wrote 4,300 words that day. We riffed off each other, taking narrative threads we saw being dropped in the google doc and weaving them through our own snippets of semi-generated prose.

While we wrote, we listened to a ghostly soundtrack of music generated by Robin, assembled from a neural network trained on an artist he wished had produced more music.

Today’s algorithmic collaboration felt a bit different, now that we’d expanded the corpus on which the model was trained to include art collectors, artists from the Harlem Renaissance, and stand-up comedians. It was a bizarre time.

The night wrapped up, again, with the eating of food and picking of favorites:

  • “She embroidered the ideas of Laura de Gioste on a seaside tree.”
  • “Many works found considerable readers in the airport, specifically the painting called Neue Big Chrome.”
  • “Minerva Black’s irreverent embroidery depicted classical Greek figures alongside high-tech imagery: Athena and her computer.”
  • “When he died, she is reported to have said, ‘He became a response to himself.’”

Day 3

The evening of Halloween, and only the most dedicated remained. About ten of us arrived to a soundtrack Robin had generated just that morning. The music was not unlike the calls of a dying caribou, and about as distressing, which if nothing else fit the holiday.

The Midnight Society

A new google doc awaited us, assembled from the words we’d contributed yesterday, though significantly reduced. Robin put order to our words, replaced a few proper nouns to solidify the narrative thread, and gave us some time to read what we’d written (or be impressed by this master author’s ability to give meaning to madness).

To polish the draft off, we marked the passages that confused or displeased us, and then each spent a while fixing the problem sections: making the narrative flow, removing tangents, and tightening the prose. On the final readthrough, we vetoed changes that needed vetoing, revived a few beloved but cut lines, and generally marveled at the readability of the final piece.

Somehow, amidst the chaos of machine prose and a barely coordinated, rotating group of amateurs, we assembled a story with a narrative arc, delicious prose, and a coherent (if strange) plot.


We can answer the question that drove our experimental workshop: can a dozen artists, technologists, and scholars collaborate with each other and with machines to produce a readable, interesting story in under 12 hours?

Yes, if guided by a professional cyborg author like Robin Sloan.

While I can’t speak for the others, I found this to be the most refreshing writing crucible I’ve yet experienced.

I rarely get the opportunity to write fiction, but when I do, it’s a one-way street. I can send words to an empty screen, but the screen never sends words back. Over these three nights, a combination of algorithms and compatriots sat behind my blank page, and we lobbed words back and forth as though the blinking cursor were a tennis net.

Robin Sloan’s algorithmic writing companion works an awful lot like gmail’s new predictive sentence completion, just turned upside-down. It expands rather constrains a text’s possible futures. Whether this bodes a new era of writing, I cannot say. The experience rhymes with Oulipo, but reads more accessibly. If ease and mass distribution are the tailwind of 21st century change, perhaps the next decade will see the rise of a new sort of writing.

In the meantime, I’m scheming my next experiment.


Encouraging Misfits

tl;dr Academics’ individual policing of disciplinary boundaries at the expense of intellectual merit does a disservice to our global research community, which is already structured to reinforce disciplinarity at every stage. We should work harder to encourage research misfits to offset this structural pull.

The academic game is stacked to reinforce old community practices. PhDs aren’t only about specialization, but about teaching you to think, act, write, and cite like the discipline you’ll soon join. Tenure is about proving to your peers you are like them. Publishing and winning grants are as much about goodness of fit as about quality of work.

This isn’t bad. One of science’s most important features is that it’s often cumulative or at least agglomerative, that scientists don’t start from scratch with every new project, but build on each other’s work to construct an edifice that often resembles progress. The scientific pipeline uses PhDs, tenure, journals, and grants as built-in funnels, ensuring everyone is squeezed snugly inside the pipes at every stage of their career. It’s a clever institutional trick to keep science cumulative.

But the funnels work too well. Or at least, there’s no equally entrenched clever institutional mechanism for building new pipes, for allowing the development of new academic communities that break the mold. Publishing in established journals that enforce their community boundaries is necessary for your career; most of the world’s scholarly grant programs are earmarked for and evaluated by specific academic communities. It’s easy to be disciplinary, and hard to be a misfit.

To be sure, this is a known problem. Patches abound. Universities set aside funds for “interdisciplinary research” or “underfunded areas”; postdoc positions, centers, and antidsciplinary journals exist to encourage exactly the sort of weird research I’m claiming has no little place in today’s university. These solutions are insufficient.

University or even external grant programs fostering “interdisciplinarity” for its own sake become mostly useless because of the laws of Goodhart & Campbell. They’re usually designed to bring disciplines together rather than to sidestep disciplinarity altogether, which while admirable, is a system that’s pretty easy to game, and often leads to awkward alliances of convenience.

Dramatic rendition of types of -disciplinarity from Lotrecchiano in 2010, shown here never actually getting outside disciplines.

Universities do a bit better in encouraging certain types of centers that, rather than being “interdisciplinary”, are focused on a specific goal, method, or topic that doesn’t align easily with the local department structure. A new pipe, to extend my earlier bad metaphor. The problems arise here because centers often lack the institutional benefits available to departments: they rely on soft money, don’t get kickback from grant overheads, don’t get money from cross-listed courses, and don’t get tenure lines. Antidisciplinary postdoc positions suffer a similar fate, allowing misfits to thrive for a year or so before having to go back on the job market to rinse & repeat.

In short, the overwhelming inertial force of academic institutions pulls towards disciplinarity despite frequent but half-assed or poorly-supported attempts to remedy the situation. Even when new disciplinary configurations break free of institutional inertia, presenting themselves as means to knowledge every bit as legitimate as traditional departments (chemistry, history, sociology, etc.), it can take decades for them to even be given the chance to fail.

It is perhaps unsurprising that the community which taught us about autopoiesis proved incapable of sustaining itself, though half a century on its influences are glaringly apparent and far-reaching across today’s research universities. I wonder if we reconfigured the organization of colleges and departments from scratch today, whether there would be more departments of environmental studies and fewer departments of [redacted] 1.

I bring this all up to raise awareness of the difficulty facing good work with no discernible home, and to advocate for some individual action which, though it won’t change the system overnight, will hopefully make the world a bit easier for those who deserve it.

It is this: relax the reflexive disciplinary boundary drawing, and foster programs or communities which celebrate misfits. I wrote a bit about this last year in the context of history and culturomics; historians clamored to show that culturomics was bad history, but culturomics never attempted to be good history—it attempted to be good culturomics. Though I’d argue it often failed at that as well, it should have been evaluated by its own criteria, not the criteria of some related but different discipline.

Some potential ways to move forward:

  • If you are reviewing for a journal or grant and the piece is great, but doesn’t quite fit, and you can’t think of a better home for it, push against the editor to let it in anyway.
  • If you’re a journal editor or grant program officer, be more flexible with submissions which don’t fit your mold but don’t have easy homes elsewhere.
  • If you control funds for research grants, earmark half your money for good work that lacks a home. Not “good work that lacks a home but still looks like the humanities”, or “good work that looks like economics but happens to involve a computer scientist and a biologist”, but truly homeless work. I realize this won’t happen, but if I’m advocating, I might as well advocate big!
  • If you are training graduate students, hiring faculty, or evaluating tenure cases, relax the boundary-drawing urge to say “her work is fascinating, but it’s not exactly our department.”
  • If you have administrative and financial power at a university, commit to supporting nondisciplinary centers and agendas with the creation of tenure lines, the allocation of course & indirect funds, and some of the security offered to departments.

Ultimately, we need clever systems to foster nondisciplinary thinking which are as robust as those systems that foster cumulative research. This problem is above my paygrade. In the meantime, though, we can at least avoid the urge to equate disciplinary fitness with intellectual quality.


  1. You didn’t seriously expect me to name names, did you?

Argument Clinic

Zoe LeBlanc asked how basic statistics lead to a meaningful historical argument. A good discussion followed, worth reading, but since I couldn’t fit my response into tweets, I hoped to add a bit to the thread here on the irregular. I’m addressing only one tiny corner of her question, in a way that is peculiar to my own still-forming approach to computational history; I hope it will be of some use to those starting out.

In brief, I argue that one good approach to computational history cycles between data summaries and focused hypothesis exploration, driven by historiographic knowledge, in service to finding and supporting historically interesting agendas. There’s a lot of good computational history that doesn’t do this, and a lot of bad computational history that does, but this may be a helpful rubric to follow.

In the spirit of Monty Python, the below video has absolutely nothing to do with the discussion at hand.

Zoe’s question gets at the heart of one of the two most prominent failures of computational history in 2017 1: the inability to go beyond descriptive statistics into historical argument. 2 I’ve written before on one of the many reasons for this inability, but that’s not the subject of this post. This post covers some good practices in getting from statistics to arguments.

Describing the Past

Historians, for the most part, aren’t experimentalists. 3 Our goals vary, but they often include telling stories about the past that haven’t been told, by employing newly-discovered evidence, connecting events that seemed unrelated, or revisiting an old narrative with a fresh perspective.

Facts alone usually don’t cut it. We don’t care what Jane ate for breakfast without a so what. Maybe her breakfast choices say something interesting about her socioeconomic status, or about food culture, or about how her eating habits informed the way she lived. Alongside a fact, we want why or how it came to be, what it means, or its role in some larger or future trend. A sufficiently big and surprising fact may be worthy of note on its own (“Jane ate orphans for breakfast” or “The government did indeed collude with a foreign power”), but such surprising revelations are rare, not the only purpose for historians, and still beg for context.

Computational history has gotten away with a lot of context-free presentations of fact. 4 That’s great! It’s a sign there’s a lot we didn’t know that contemporary methods & data make easily visible. 5 Here’s an example of one of mine, showing that, despite evidence to the contrary, there is a thriving community at the intersection of history and philosophy of science:

My citation analysis showing a bridge between history & philosophy of science.

But, though we’re not running out of low-hanging fruit, the novelty of mere description is wearing thin. Knowing that a community exists between history & philosophy of science is not particularly interesting; knowing why it exists, what it changes, or whether it is less tenuous than any other disciplinary borderland are more interesting and historiographically recognizable questions.

Context is Key

So how to get from description to historical argument? Though there’s no right path, and the route depends on the type of claim, this post may offer some guidance. Before we get too far, though, a note:

Description has little meaning without context and comparison. The data may show that more people are eating apples for breakfast, but there’s a lot to unpack there before it can be meaningful, let alone relevant.

Line chart of # of people who eat apples over time.

It may be, for example, that the general population is growing just as quickly as the number of people who eat apples. If that’s the case, does it matter that apple-eaters themselves don’t seem to be making up any larger percent of the population?

Line chart of # of people who eat apples over time (left axis) compared to general population (right axis).

The answer for a historian is: of course it matters. If we were talking about casualties of war, or amount of cities in a country, rather than apples, a twofold increase in absolute value (rather than percentage of population) makes a huge difference. It’s more lives affected; it’s more infrastructure and resources for a growing nation.

But the nature of that difference changes when we know our subject of study matches population dynamics. If we’re looking at voting patterns across cities, and we notice population density correlates with party affiliation, we can use that as a launching point for so what. Perhaps sparser cities rely on fewer social services to run smoothly, leading the population to vote more conservative; perhaps past events pushed conservative families towards the outskirts; perhaps.

Without having a ground against which to contextualize our results, a base map like general population, the fact of which cities voted in which direction gives us little historical meat to chew on.

On the other hand, some surprising facts, when contextualized, leave us less surprised. A two-fold increase in apple eating across a decade is pretty surprising, until you realize it happened alongside a similar increase in population. The fact is suddenly less worthy of report by itself, though it may have implications for, say, the growth of the apple industry.

But Zoe asked about statistics, not counting, in finding meaning. I don’t want to divert this post into teaching stats, and nor do I want to assume statistical knowledge, so I’ll opt for an incredibly simple metric: ratio.

The illustration above shows an increase in both population and apple-eating, and eyeball estimates show them growing apace. If we divide the total population by the number of people eating apples, however, our story is complicated.

Line chart of # of people who eat apples over time (left axis) compared to general population (right axis). A thick blue line in the middle (left axis) shows the ratio between the two.

Though both population and apple-eating increase, in 1806 the population begins rising much more rapidly than the number of apple-eaters. 6 It is in this statistically-derived difference that the historian may find something worth exploring and explaining further.

There are a many ways to compare and contextualize data, of which this is one. They aren’t worth enumerating, but the importance of contextualization is relevant to what comes next.

Question- and Data-Driven History

Computational historians like to talk about question-driven analysis. Computational history is best, we say, when it is led by a specific question or angle. The alternative is dumping a bunch of data into a statistics engine, describing it, and finding something weird, and saying “oh, this looks interesting.”

When push comes to shove, most would agree the above dichotomy is false. Historical questions don’t pop out of thin air, but from a continuously shifting relationship with the past. We read primary and secondary sources, do some data entry, do some analysis, do some more reading, and through it all build up a knowledge-base and a set of expectations about the past. We also by this point have a set of claims we don’t quite agree with, or some secondary sources with stories that feel wrong or incomplete.

This is where the computational history practice begins: with a firm grasp of the history and historiography of a period, and a set of assumptions, questions, and mild disagreements.

From here, if you’re reading this blog post, you’re likely in one of two camps:

  1. You have a big dataset and don’t know what to do with it, or
  2. You have a historiographic agenda (a point to prove, a question to answer, etc.) that you don’t know how to make computationally tractable.

We’ll begin with #1.

1. I have data. Now what?

Congratulations, you have data!


This is probably the thornier of the two positions, and the one more prone to results of mere description. You want to know how to turn your data into interesting history, but you may end up doing little more than enumerating the blades of grass on a field. To avoid that, you must begin down a process sometimes called scalable reading, or a special case of the hermeneutic circle.

You start, of course, with mere description. How many records are there? What are the values in each? Are there changes over time or place? Who is most central? Before you start quantifying the data, write down the answers you expect to these questions, with a bit of a causal explanation for each.

Now, barrage your dataset with visualizations and statistical tests to find out exactly what makes it up. See how the results align with the hypotheses you noted down. If you created the data yourself, one archival visit at a time, you won’t find a lot that surprises you. That’s alright. Be sure to take time to consider what’s missing from the dataset, due to archival lacunae, bias, etc.

If any results surprise you, dig into the data to try to understand why. If none do, think about claims from secondary sources–do any contradict the data? Align with it?

This is also a good point to bring in contextualization. If you’re looking at the number of people doing something over time, try to compare your dataset to population dynamics. If you’re looking at word usage, find a way to compare your data to base frequencies of that word in similar collections. If you’re looking at social networks, compare them to random networks to see if their average path length or degree distribution are surprising compared to networks of similar size. Every unexpected result is an opportunity for exploration.

Internal comparisons may also yield interesting points to pursue further, especially if you think your data are biased. Given a limited dataset of actors, their genders, their roles, and play titles, for example, you may not be able to make broad claims about which plays are more popular, but you could see how different roles are distributed across genders within the group.

Internal comparisons could also be temporal. Given a dataset of occupations over time with a particular city, if you compare those numbers to population changes over time, you could find the moments where population and occupation dynamics part ways, and focus on those instances. Why, suddenly, are there more grocers?

The above boils down into two possible points of further research: deviations from expectation, or deviations from internal consistency.

Deviations from expectation–your own or that of some notable secondary source–can be particularly question-provoking. “Why didn’t this meet expectations” quickly becomes “what is wrong or incomplete about this common historical narrative?” From here, it’s useful to dig down into the points of data that exemplify such deviations, and see if you can figure out why and how they break from expectations.

Deviations from internal consistency–that is, when comparisons within the data wind up showing different trends–lead to positive rather than negative questions. Instead of “why is this theory wrong?”, you may ask, “why are these groups different?” or “why does this trend cease to keep pace with population during these decades?” Here you are asking specific questions that require new or shifted theories, whereas with deviations from expectations, you begin by seeing where existing narratives fail.

It’s worth reiterating that, in both scenarios, questions are drawn from deviations from some underlying theory.

In deviations from expectation, the underlying theory is what you bring to your data; you assume the data ought to look one way, but it doesn’t. You are coming with an internal, if not explicit, quantitative model of how the data ought to look.

In deviations from internal consistency, that data’s descriptive statistics provide the underlying theory against which there may be deviations. Apple-eaters deviating in number from population growth is only interesting if, at most points, apple-eaters grow  evenly alongside population. That is, you assume general statistics should be the same between groups or over time, and if they are not, it is worthy of explanation.

This an oversimplification, but a useful one. Undoubtedly, combinations of the two will arise: maybe you expect the differences between men and women in roles they play will be large, but it turns out they are small. This provides a deviation of both kinds, but no less legitimate for it. In this case, your recourse may be looking for other theatrical datasets to see if the gender dynamics play out the same across them, or if your data are somehow special and worthy of explanation outside the context of larger gender dynamics.

Which brings us, inexorably, to the cyclic process of computational history. Scalable reading. The hermeneutic circle. Whatever.

Point is, you’re at the point where some deviation or alignment seems worth explanation or exploration. You could stop here. You could present this trend, give a convincing causal just-so story of why it exists, and leave it at that. You will probably get published, since you’ve already gone farther than mere description, the trap of so much computational history.

But you shouldn’t stop here. You should take this opportunity to strengthen your story. Perhaps this is the point where you put your “traditional” historian’s cap back on, and go dust-diving for archival evidence to support your claims. I wouldn’t think less of you for it, but if you stop there, you’d only be reaping half the advantages of computational history.

In the example above, looking for other theatrical datasets to contextualize gender results in your own, hinted at the second half of the computational history research cycle: creating computationally tractable questions. Recall this section described the first half: making sense of data. Although I presented the two as separate, they productively feed on one another.

Once you’ve gone through your data to find how it aligns with your or others’ preconceived notions of the past, or how by its own internal deviations it presents interesting dilemmas, you have found yourself in the second half of the cycle. You have questions or theories you want to ask of data, but you do not yet have the data or the statistics to explore them.

This seems counter-intuitive. Why not just use the data or statistics already gathered, sometimes painstakingly over several years? Because if you use the same data & stats to both generate and answer questions, your evidence is circular. Specifically, you risk making a scientistic claim of what could easily be a spurious trend. It may simply be that, by random chance, the breakfast record-keeper lost a bunch of records from 1806-1810, thus causing the decline seen in the population ratio.

To convincingly make arguments from a historical data description, you must back it up using triangulation–approaching the problem from many angles. That triangulation may be computational, archival, archaeological, or however else you’re used to historying, but we’ll focus here on computational.

2. Computationally Tractable Questions

So you’ve got a historiographic agenda, and now you want to make it computationally tractable. Good luck! This is the hard part.

Good luck!

“Sparse areas relied less on social services.” “The infrastructure of science became less dependent on specific individuals over the course of the 17th century.” “T-Rex was a remarkable climber.” “Who benefited most from the power vacuum left by the assassination?” These hypotheses and questions do not, on their own, lend themselves to quantitative analysis.

Chief among the common difficulties of turning a historiographic agenda into a computationally tractable hypothesis is a lack of familiarity of computational methods. If you don’t know what a computer is good at, you can’t form an experiment to use one.

I said that history isn’t experimental, but I lied. Archival research can be an experiment if you go in with a hypothesis and a pre-conceived approach or set of criteria that would confirm it. Computational history, at this stage, is also experimental. It often works a little like this (but it may not): 7

  1. Set your agenda. Start with a hypothesis, historiographic framework, or question. For example, “The infrastructure of science became less dependent on specific individuals over the course of the 17th century.” (that question’s mine, don’t steal it.)
  2. Find testable hypotheses. Break it into many smaller statements that can be confirmed, denied, or quantitatively assessed. “If science depends less on specific individuals over the 17th century, the distribution of names mentioned in scholarly correspondence will flatten out. That is, in 1600 a few people will be mentioned frequently, whereas most will be mentioned infrequently; in 1700, the frequency of name mentions will be more evenly distributed across correspondence.” Or “If science depends less on specific individuals over the 17th century, when an important person died, it affected the scholarly network less in 1700 than in 1600.” (Notice in these two examples how finding evidence for the littler statements will corroborate the bigger hypothesis, and vice-versa.)
  3. Match hypotheses to approaches. Come up with methodological proxies, datasets, and/or statistical tests that could corroborate the littler statements. Be careful, thorough, and specific. For example, “In a network of 17th-century letter writers, if the removal of a central figure in 1600 decreases the average path length of the network less than the the removal of a central figure in 1700, central figures likely played less important structural roles. This will be most convincing if the effects of node removal smoothly decreases across the century.” (This is the step in which you need to come to the table with knowledge of different computational methods and what they do.)
  4. Specify proxies. List specific analytic approaches needed for the promising tests, and the data required to do them. For example, you need a list of senders and recipients of scholarly letters, roughly evenly distributed across time between 1600 and 1700, and densely-packed enough to perform network analysis. There could be a few different analytic approaches, including removing highly-central nodes and re-calculating average path length; employing measurements of attack tolerance; etc. Probably worth testing them all and seeing if each result conforms to the pre-existing theory.
  5. Find data. Find pre-existing datasets that will fit your proxies, or estimate how long it will take to gather enough data yourself to reasonably approach your hypotheses. Opt for data that will work for as many approaches as possible. You may find some data that will suggest new hypotheses, and you’ll iterate back and forth between steps #3-#5 a few times.
  6. Collect data. Run experiments. Uh, yeah, just do those things. Easy as baking apple pie from scratch.
  7. Match experimental results to hypotheses. Here’s the fun part, you get to see how many of your predictions matched your results. Hopefully a bunch, but even if they didn’t, it’s an excuse to figure out why, and start the process anew. You can also start exploring the additional datasets to help you develop new questions. The astute may have noticed, this step brings us back to the first half of computational historiography: exploring data and seeing what you can find. 8

From here, it may be worthwhile to cycle back to the data exploration stage, then back here to computationally tractable hypothesis exploration, and so on ad infinitum.

By now, making meaning out of data probably feels impossible. I’m sorry. The process is much more fluid and intertwined than is easily unpacked in a blog post. The back-and-forth can take hours, days, months, or years.

But the important thing is, after you’ve gone back-and-forth a few times, you should have a combination of quantitative, archival, theoretical, and secondary support for a solidly historical argument.

Contexts of Discovery and Justification

Early 20th-century philosophy of science cared a lot about the distinction between the contexts of discovery and justification. Violently shortened, the context of discovery is how you reached your conclusion, and the context of justification is how you argue your point, regardless of the process that got you there.

I bring this up as a reminder that the two can be distinct. By the 1990s, quantitative historians who wanted to remain legible to their non-quantitative colleagues often saved the data analysis for an appendix, and even there the focus was on the actual experiments, not the long process of coming up with tests, re-testing, collecting more data, and so on.

The result of this cyclical computational historiography need not be (and rarely is, and perhaps can never be) a description of the process that led you to the evidence supporting your argument. While it’s a good idea to be clear about where your methods led you astray, the most legible result to historians will necessarily involve a narrative reconfiguration.

Causality and Truth

Small final notes on two big topics.

First, Causality. This approach won’t get you there. It’s hard to disentangle causality from correlation, but more importantly in this context, it’s hard to choose between competing causal explanations. The above process can lead you to plausible and corroborated hypotheses, but it cannot prove anything.

Consider this: “My hypothesis about apples predicts these 10 testable claims.” You test each claim, and each test agrees with your predictions. It’s a success, but a soft one; you’ve shown your hypothesis to be plausible given the evidence, but not inevitable. A dozen other equally sensible hypotheses could have produced the same 10 testable claims. You did not prove those hypotheses wrong, you just chose one model that happened to work. 9

Even if no alternate hypothesis presents itself, and all of your tests agree with your hypothesis, you still do not have causal proof. It may be that the proxies you chose to test your claims are bad ones, or incomplete, or your method has unseen holes. Causality is tricky, and in the humanities, proof especially so.

Which leads us to the next point: Truth. Even if somehow you devise the perfect process to find proof of a causal hypothesis, the causal description does not constitute capital-T Truth. There are many truths, coming from many perspectives, about the past, and they don’t need to agree with each other. Historians care not just about what happened, but how and why, and those hows and whys are driven by people. Messy, inconsistent people who believe many conflicting things within the span of a moment. When it comes to questions of society, even the most scientistic of scholars must come to terms with uncertainty and conflict, which after all are more causally central to the story of history than most clever narratives we might tell.


  1. Also called digital history, and related to quantitative history and cliometrics in ways we don’t often like to admit.
  2. The other most prominent failure in computational history is our tendency to group things into finite discrete categories; in this case, a two-part list of failures.
  3. With some notable exceptions. Some historians simulate the past, others perform experiments on rates of material decay, or on the chemical composition of inks. It’s a big world out there.
  4. When I say fact, assume I add all the relevant post-modernist caveats of the contingency of objectivity etc. etc. Really I mean “matters of history that the volume of available evidence make difficult to dispute.”
  5. Ted Underwood and I have both talked about the exciting promise of incredibly low-hanging fruit in new approaches.
  6. OK in retrospect I should have used a more historically relevant example – I wasn’t expecting to push this example so far.
  7. If this seems overly scientistic, worry not! Experimental science is often defined by its recourse to rote procedure, which means pretty much any procedural explanation of research will resemble experimental science. There are many ways one can go about scalable reading / triangulation of computational historiography, not just the procedural steps #1-#7 above, but this is one of the easier approaches to explain. Soft falsification and hypothesis testing are plausible angles into computational history, but not necessary ones.
  8. A brief addendum to steps #6-#7: although I’d argue Null-Hypothesis Significance Testing or population-based statistical inferences may not be relevant to historiography, especially when its based in triangulation, they may be useful in certain cases. Without delving too deeply into the weeds, they can help you figure out the extent to which the effect you see may just be noise, not indicative of any particular trend. Statistical effect sizes also may be of use, helping you see whether the magnitude of your finding is big enough to have any appreciable role in the historical narrative.
  9. Shawn Graham and I wrote about this in relation to archaeology and simulation here, on the subject of underdetermination and abduction

Teaching Yourself to Code in DH

tl;dr Book-length introductions to programming or analytic methods (math / statistics / etc.) aimed at or useful for humanists with limited coding experience.

I’m collecting programming & methodological textbooks for humanists as part of a reflective study on DH, but figured it’d also be useful for those interested in teaching themselves to code, or teachers who need a textbook for their class. Though I haven’t read them all yet, I’ve organized them into very imperfect categories and provided (hopefully) some useful comments. Short coding exercises, books that assume some pre-existing knowledge of coding, and theoretical introductions are not listed here.

Thanks to @Literature_Geek, @ProgHist, @heatherfro, @electricarchaeo, @digitaldante, @kintopp, @dmimno, & @collinj for their contributions to the growing list. In the interest of maintaining scope, not all of their suggestions appear below.

Historical Analysis

  • The Programming Historian, 1st edition (2007). William J. Turkel and Alan MacEachern.
    • An open access introduction to programming in Python. Mostly web scraping and basic text analysis. Probably best to look to newer resources, due to the date. Although it’s aimed at historians, the methods are broadly useful to all text-based DH.
  • The Programming Historian, 2nd edition (ongoing). Afanador-Llach, Maria José, Antonio Rojas Castro, Adam Crymble, Víctor Gayol, Fred Gibbs, Caleb McDaniel, Ian Milligan, Amanda Visconti, and Jeri Wieringa, eds.
    • Constantly updating lessons, ostensibly aimed at historians, but useful to all of DH. Includes introductions to web development, text analysis, GIS, network analysis, etc. in multiple programming languages. Not a monograph, and no real order.
  • Computational Historical Thinking with Applications in R (ongoing). Lincoln Mullen.
    • A series of lessons in in R, still under development with quite a few chapters missing. Probably the only programming book aimed at historians that actually focuses on historical questions and approaches.
  • The Rubyist Historian (2004). Jason Heppler.
    • A short introduction to programming in Ruby. Again, ostensibly aimed at historians, but really just focused on the fundamentals of coding, and useful in that context.
  • Natural Language Processing for Historical Texts (2012). Michael Piotrowski.
    • About natural language processing, but not an introduction to coding. Instead, an introduction to the methodological approaches of natural language processing specific to historical texts (OCR, spelling normalization, choosing a corpus, part of speech tagging, etc.). Teaches a variety of tools and techniques.
  • The Historian’s Macroscope (2015). Graham, Milligan, & Weingart.
    • Okay I’m cheating a bit here! This isn’t teaching you to program, but Shawn, Ian, and I spent a while writing this intro to digital methods for historians, so I figured I’d sneak a link in.

Literary & Linguistic Analysis

  • Text Analysis with R for Students of Literature (2014). Matthew Jockers.
    • Step-by-step introduction to learning R, specifically focused on literary text analysis, both for close and distant reading, with primers on the statistical approaches being used. Includes approaches to, e.g., word frequency distribution, lexical variety, classification, and topic modeling.
  • The Art of Literary Text Analysis (ongoing). Stéfan Sinclair & Geoffrey Rockwell.
    • A growing, interactive textbook similar in scope to Jockers’ book (close & distant reading in literary analysis), but in Python rather than R. Heavily focused on the code itself, and includes such methods as topic modeling and sentiment analysis.
  • Statistics for Corpus Linguistics (1998). Michael Oakes.
    • Don’t know anything about this one, sorry!

General Digital Humanities

Many of the above books are focused on literary or historical analysis only in name, but are really useful for everyone in DH. The below are similar in scope, but don’t aim themselves at one particular group.

  • Humanities Data in R (2015). Lauren Tilton & Taylor Arnold.
    • General introduction to programming through R, and broadly focused on many approaches, including basic statistics, networks, maps, texts, and images. Teaches concepts and programmatic implementations.
  • Digital Research Methods with Mathematica (2015). William J. Turkel.
    • A Mathematica notebook (thus, not accessible unless you have an appropriate reader) teaching text, image, and geo-based analysis. Mathematica itself is an expensive piece of software without an institutional license, so this resource may be inaccessible to many learners. [NOTE: Arno Bosse wrote positive feedback on this textbook in a comment below.]
  • Exploratory Programming for the Arts and Humanities (2016). Nick Montfort.
    • An introduction to the fundamentals of programming specifically for arts and humanities, languages Python and Processing, that goes through statistics, text, sound, animation, images, and so forth. Much more expansive than many other options listed here, but not as focused on needs of text analysis (which is probably a good thing).
  • An Introduction to Text Analysis: A Coursebook (2016). Brandon Walsh & Sarah Horowitz.
    • A brief textbook with exercises and explanatory notes specific to text analysis for the study of literature and history. Not an introduction to programming, but covers some of the mathematical and methodological concepts used in these sorts of studies.
  • Python Programming for Humanists (ongoing). Folgert Karsdorp and Maarten van Gompel.
    • Interactive (Jupyter) notebooks teaching Python for statistical text analysis. Quite thorough, teaching methodological reasoning and examples, including quizzes and other lesson helpers, going from basic tokenization up through unsupervised learning, object-oriented programming, etc.
  • Technical Foundations of Informatics (2017). Michael Freeman and Joel Ross.
    • Teaches the start-to-finish skills needed to write code to work with data, from command line to markdown to github to R and ggplot2. Not aimed at humanists, but aimed at those with no prior technical experience.
  • Hacking the Humanities (2018). Paul Vierthaler.
    • A series of videos and github code snippets/examples for Vierthaler’s DH class at Leiden University (see the syllabus). General introduction to coding principles, followed by specific needs of digital humanists, like text analysis and web scraping.

Statistical Methods & Machine Learning

  • Statistics for the Humanities (2014). John Canning.
    • Not an introduction to coding of any sort, but a solid intro to statistics geared at the sort of stats needed by humanists (archaeologists, literary theorists, philosophers, historians, etc.). Reading this should give you a solid foundation of statistical methods (sampling, confidence intervals, bias, etc.)
  • Data Mining: Practical Machine Learning Tools and Techniques, 4th edition (2016). Witten, Frank, Hall, & Pal.
    • A practical intro to machine learning in Weka, Java-based software for data mining and modeling. Not aimed at humanists, but legible to the dedicated amateur. It really gets into the weeds of how machine learning works.
  • Text Mining with R (2017). Julia Silge and David Robinson.
    • Introduction to text mining aimed at data scientists in the statistical programming language R. Some knowledge of R is expected; the authors suggest using R for Data Science (2016) by Grolemund & Wickham to get up to speed. This is for those interested in current data science coding best-practices, though it does not get as in-depth as some other texts focused on literary text analysis. Good as a solid base to learn from.
  • The Curious Journalist’s Guide to Data (2016). Jonathan Stray.
    • Not an intro to programming or math, but rather a good guide to quantitatively thinking through evidence and argument. Aimed at journalists, but of potential use to more empirically-minded humanists.
  • Six Septembers: Mathematics for the Humanist (2017). Patrick Juola & Stephen Ramsay.
    • Fantastic introduction to simple and advanced mathematics written by and for humanists. Approachable, prose-heavy, and grounded in humanities examples. Covers topics like algebra, calculus, statistics, differential equations. Definitely a foundations text, not an applications one.

Data Visualization, Web Development, & Related

  • The JavaScripting English Major (2017). Moacir P. de Sá Pereira.
    • “A 15-session course that teaches humanities undergraduates how to write their own web-based project using JavaScript.” Short textbook-style course with exercises that focuses particularly on web-mapping with Leaflet.
  • Data Visualization for Social Science: A practical introduction with R and ggplot2 (2017). Kieran Healy
    • A “hands-on introduction to the principles and practice of looking at and presenting data using R and ggplot” that introduce readers “to both the ideas and the methods of data visualization in a comprehensible and reproducible way”. Incredibly thorough, painstakingly annotated, and though not aimed directly at humanists, is close enough in scope to be more valuable than a general introduction to data science.
  • Interactive Information Visualization (2017). Michael Freeman.
    • Introduction to the skills, tools, and setup required to create interactive web visualizations, briefly covering everything from HTML to D3.js. Not aimed at the humanities, but aimed at those with no prior experience with code.
  • D3.js in Action, 2nd edition (2017). Elijah Meeks.
    • Introduction to programmatic, online data visualization in javascript and the library D3.js. Not aimed at the humanities, but written by a digital humanist; easy to read and follow. The great thing about D3 is it’s a library for visualizing something in whatever fashion you might imagine, so this is a good book for those who want to design their own visualizations rather than using off-the-shelf tools.
  • Drupal for Humanists (2016). Quinn Dombrowski.
    • Full-length introduction to Drupal, a web platform that allows you to build “environments for gathering, annotating, arranging, and presenting their research and supporting materials” on the web. Useful for those interested in getting started with the creation of web-based projects but who don’t want to dive head-first into from-scratch web development.
  • (Xe)LaTeX appliqué aux sciences humaines (2012). Maïeul Rouquette, Brendan Chabannes et Enimie Rouquette.
    • French introduction to LaTeX for humanists. LaTeX is the primary means scientists use to prepare documents (instead of MS Word or similar software), which allows for more sustainable, robust, and easily typeset scholarly publications. If humanists wish to publish in natural (or some social) science journals, this is an important skill.