Reminder

In the midst of the ongoing disaster that has befallen the country, I had a reminder recently that healthcare in the USA is still a wreck. When I had my episode of food poisoning (or whatever it was) in Michigan recently, my concerned wife took me to an urgent care. We of course had to pay out-of-pocket for service (about $100), as we were way outside our network (the group of providers who have agreements with our insurance company). I submitted the paperwork to our insurance company when we got home (Duke uses Aetna), to see if they would reimburse some of that amount. Nope. Rejected, because we didn't call them first to get approval—not something you think of at a time like that. Thank God I waved off the 911 responders when my daughter called them after I first got sick and almost passed out. We might have been out thousands of dollars. And this is with really first-class insurance, mind you. I have great insurance through Duke. You can't get much better in this country.

People from countries with real healthcare systems find this kind of thing shocking, but it's par for the course here. And our government is actively trying to make it worse. It's just one more bit of dreadful in a sea's worth, but it's worth remembering that the disastrous state of healthcare in the US affects all of us, even the lucky ones with insurance through our jobs. And again, our government is trying its best to make it worse. You can be quite sure it will be worse for everyone.

Experiencing Technical Difficulties

I've been struggling with a case of burnout for a while now. It's a common problem in programming, where we have to maintain a fairly high level of creative energy all the time, and unlike my colleagues in academia or the library, I'm not eligible for research leave or sabbaticals. Vacation is the only opportunity for recharging my creative batteries, but that's hard too when there are a lot of tasks that can't wait. I have taken the day off to work before, but that just seems stupid. So I grind away, hoping the fog will lift.

A few weeks ago, the kids and I joined my wife on a work trip to Michigan. It was supposed to be a mini-vacation for us, but I got violently ill after lunch one day—during a UMich campus tour. It sucked about as much as it possibly could. My marvelous elder daughter dealt with the situation handily, but of course we ended up missing most of the tour, and I ended up in bed the rest of the day, barring the occasional run to the bathroom. My world narrowed down to a point. I was quite happy to lie there, not thinking. I could have read or watched television, but I didn't want to. Trying the occasional sip of gatorade was as much as I felt like. For someone who normally craves input all the time, it was very peaceful. It revealed to me again on how much of a knife-edge my consciousness really is. It would take very little to knock it off the shelf to shatter on the ground.

My father has Alzheimer's Disease, and this has already happened to him. Where once there was an acutely perceptive and inquiring mind, there remains only his personality, which seems in his case to be the last thing to go. I try to spend time with him at least once or twice a week, both to take a little pressure off my mother and to check on their general well-being. We take walks. Physically, he's in great shape for a man in his 80s. And there are still flashes of the person he was. He can't really hold a conversation, and will ask the same questions over and over again, my answers slipping away as soon as they're heard, but as we walked the other day, accompanied by loud birdsong, he piped up "We hear you!" to the birds, his sense of humor suddenly back on the surface. We are lucky that my parents have fantastic insurance and a good retirement plan, courtesy of an employer, the Episcopal Church, that cares about its people beyond the period of their usefulness.

Burnout is a species of depression, really. It is the same sort of thing as writer's block. Your motivation simply falls out from under you. You know what needs to be done, but it's hard to summon the energy to do it. The current political climate doesn't help, as we careen towards the cliff's edge like the last ride of Thelma and Louise, having (I hope metaphorically, but probably not for many of us) chosen death over a constrained future, for the sake of poking authority in the eye. My children will suffer because the Baby Boomers have decided to try to take it all with them, because as a society we've fallen in love with Death. All we can do really is try to arm the kids against the hard times to come, their country having chosen war, terror, and oppression in preference to the idea that someone undeserving might receive any benefit from society. We Gen-Xers at least had some opportunity to get a foot on the ladder. Their generation will face a much more tightly constrained set of choices, with a much bigger downside if they make the wrong ones. I don't write much about my children online, because we want to keep them as much as possible out of the view of the social media Panopticon until they're mature enough to make their own decisions about confronting it. At least they may have a chance to start their lives without the neoliberal machine knowing everything about them. They won't have anything like the support I had, and when we've dismantled our brief gesture towards health care as a human right and insurance decisions are made by AIs that know everything about you going back to your childhood, things are going to be quite difficult.

A symptom, I think, of my burnout is my addiction to science fiction and urban fantasy novels. They give me a chance to check out from the real world for a while, but I think it's become a real addiction rather than an escape valve. Our society rolls ever forward toward what promises to be an actual dystopia with all the trappings: oppressed, perhaps enslaved underclasses, policed by unaccountable quasi-military forces, hyper-wealthy elites living in walled gardens with the latest technology, violent and unpredictable weather, massive unemployment and social unrest, food and water shortages, and ubiquitous surveillance. Escapism increasingly seems unwise. Some of that future can be averted if we choose not to be selfish and paranoid, to stop oppressing our fellow citizens and to stop demonizing immigrants, to put technology at the service of bettering society and surviving the now-inevitable changes to our climate. But we are not making good choices. Massive unemployment is a few technological innovations away. It doesn't have to be a disaster, indeed it could lead to a renaissance, but I think we're too set in our thinking to avoid the disaster scenario. The unemployed are lazy after all, our culture tells us, they must deserve the bad things that have happened to them. Our institutions are set up to push them back towards work by curtailing their benefits. But It could never happen to me, could it?

And that comes back around to why I try to grind my way through burnout rather than taking time to recover from it. I live in an "at will" state. I could, in theory, be fired because my boss saw an ugly dog on the way in to work. That wouldn't happen, I hasten to say—I work with wonderful, supportive people. But there are no guarantees to be had. People can be relied on, but institutions that have not been explicitly set up to support us cannot, and institutional structures and rules tend to win in the end. Best to keep at it and hope the spark comes back. It usually does.

Thank You

Back in the day, Joel Spolsky had a very influential tech blog, and one of the pieces he wrote described the kind of software developer he liked to hire, one who was "Smart, and gets things done." He later turned it into a book (http://www.amazon.com/Smart-Gets-Things-Done-Technical/dp/1590598385). Steve Yegge, who was also a very influential blogger in the oughties, wrote a followup, in which he tackled the problem of how you find and hire developers who are smarter than you. Given the handicaps of human psychology, how do you even recognize what you're looking at? His rubric for identifying these people (flipping Spolsky's) was "Done, and gets things smart". That is, this legendary "10X" developer was the sort who wouldn't just get done the stuff that needed to be done, but would actually anticipate what needed to be done. When you asked them to add a new feature, they'd respond that it was already done, or that they'd just need a few minutes, because they'd built things in such a way that adding your feature that you just thought of would be trivial. They wouldn't just finish projects, they'd make everything better—they'd create code that other developers could easily build upon. Essentially, they'd make everyone around them more effective as well.

I've been thinking a lot about this over the last few months, as I've worked on finishing a project started by Sebastian Rahtz: integrating support for the new "Pure ODD" syntax into the TEI Stylesheets. The idea is to have a TEI syntax for describing the content an element can have, rather than falling back on embedded RelaxNG. Lou Burnard has written about it here: https://jtei.revues.org/842. Sebastian wrote the XSLT Stylesheets and the supporting infrastructure which are both the reference implementation for publishing TEI and the primary mechanism by which the TEI Guidelines themselves are published. And they are the basis of TEI schema generation as well. So if you use TEI at all, you have Sebastian to thank.

Picking up after Sebastian's retirement last year has been a tough job. It was immediately obvious to me just how much he had done, and had been doing for the TEI all along. When Gabriel Bodard described to me how the TEI Council worked, after I was elected for the first time, he said something like: "There'll be a bunch of people arguing about how to implement a feature, or even whether it can be done, and then Sebastian will pipe up from the corner and say 'Oh, I just did it while you were talking.'" You only have to look at the contributors pages for both the TEI and the Stylesheets to see that Sebastian was indeed operating at a 10X level. Quietly, without making any fuss about it, he's been making the TEI work for many years.

The contributions of software developers are often easily overlooked. We only notice when things don't work, not when everything goes smoothly, because that's what's supposed to happen, isn't it? Even in Digital Humanities, which you'd expect to be self-aware about this sort of thing, the intellectual contributions of software developers can often be swept under the rug. So I want to go on record, shouting a loud THANK YOU to Sebastian for doing so much and for making the TEI infrastructure smart.

*****
UPDATE 2016-3-16

I heard the sad news last night that Sebastian passed away yesterday on the Ides of March. We are much diminished by his loss.

DH Data Talk

Last night I was on a panel organized by Duke Libraries' Digital Scholarship group. The panelists each gave some brief remarks and then we had what I thought was a really productive and interesting discussion. The following are my own remarks, with links to my slides (opens a new tab). In my notes, //slide// means click forward (not always to a new slide, maybe just a fragment).

This is me, and I work //slide// for this outfit. I'm going to talk just a little about a an old project and a new one, and not really give any details about either, but surface a couple of problems that I hope will be fodder for discussion. //slide// The old project is Papyri.info and publishes all kinds of data about ancient documents mostly written in ink on papyrus. The new one, Integrating Digital Epigraphies (IDEs), is about doing much the same thing for ancient documents mostly incised on stone.

If I had to characterize (most of) the work I'm doing right now, I'd say I'm working on detecting and making machine-actionable the scholarly links and networks embedded in a variety of related projects, with data sources including plain text, XML, Relational Databases, web services, and images. These encompass critical editions of texts (often in large corpora), bibliography, citations in books and articles, images posted on Flickr, and databases of texts. You could think of what I'm doing as recognizing patterns and then converting those into actual links; building a scaffold for the digital representation of networks of scholarship. This is hard work. //slide// It's hard because while superficial patterns are easy to detect, //slide// without access to the system of thought underlying those patterns (and computers can't do that yet—maybe never), those patterns are really just proxies kicked up by the underlying system. They don't themselves have meaning, but they're all you have to hold on to. //slide// Our brains (with some prior training) are very good at navigating this kind of mess, but digital systems require explicit instructions //slide// —though granted, you can sometimes use machine learning techniques to generate those.

When I say I'm working on making scholarly networks machine actionable, I'm talking about encoding as digital relations the graph of references embedded in these books, articles and corpora, and in the metadata of digital images. There are various ways one might do this, and the one we're most deeply into right now is called //slide// RDF. RDF models knowledge as a set of simple statements in the form Subject, Predicate, Object. //slide// So A cites B, for example. RDF is a web technology, so all three of these elements may be URIs that you could open in a web browser, //slide// and if you use URIs in RDF, then the object of one statement can be the subject of another, and so on. //slide// So you can use it to model logical chains of knowledge. Now notice that these statements are axioms. You can't qualify them, at least not in a fine-grained way. So this works great in a closed system (papyri.info), where we get to decide what the facts are; it's going to be much more problematic in IDEs, where we'll be coordinating data from at least half a dozen partners. Partners who may not agree on everything. //slide// What I've got is the same problem from a different angle—I need to model a big pile of opinion but all I have to do it with are facts.

Part of the solution to these problems has to be about learning how to make the insertion of machine-actionable links and facts (or at least assertions), part of—that is, a side-effect of—the normal processes of resource creation and curation. But it also has to be about building systems that can cope with ambiguity and opinion.

Outside the tent

Yesterday was a bad day. I’m chasing a messed-up software problem whose main symptom is the application consuming all available memory and then falling over without leaving a useful stacktrace. Steve Ramsay quit Twitter. A colleague I have huge respect for is leaving a project that’s foundational and is going to be parked because of it (that and the lack of funding). This all sucks. As I said on Twitter, it feels like we’ve hit a tipping point. I think DH has moved on and left a bunch of us behind. I have to start this off by saying that I really have nothing to complain about, even if some of this sounds like whining. I love my job, my colleagues, and I’m doing my best to get over being a member of a Carolina family working at Duke :-). I’m also thinking about these things a lot in the run up to Speaking in Code.

For some time now I’ve been feeling uneasy about how I should present myself and my work. A few years ago, I’d have confidently said I work on Digital Humanities projects. Before that, I was into Humanities Computing. But now? I’m not sure what I do is really DH any more. I suspect the DH community is no longer interested in the same things as people like me, who write software to enable humanistic inquiry and also like to think (and when possible write and teach) about how that software instantiates ideas about the data involved in humanistic inquiry. On one level, this is fine. Time, and academic fashion, marches on. It is a little embarrassing though given that I’m a “Senior Digital Humanities Programmer”.

Moreover, the field of “programming” daily spews forth fresh examples of unbelievable, poisonous, misogyny and seems largely incapable of recognizing what a shitty situation its in because of it.

The tech industry is in moral crisis. We live in a dystopian, panoptic geek revenge fantasy infested by absurd beliefs in meritocracy, full of entrenched inequalities, focused on white upper-class problems, inherently hostile to minorities, rife with blatant sexism and generally incapable of reaching anyone beyond early adopter audiences of people just like us. (from https://medium.com/about-work/f6ccd5a6c197)

I think communities who fight against this kind of oppression, like #DHPoco, for example, are where DH is going. But while I completely support them and think they’re doing good, important work, I feel a great lack of confidence that I can participate in any meaningful way in those conversations, both because of the professional baggage I bring with me and because they’re doing a different kind of DH. I don’t really see a category for the kinds of things I write about on DHThis or DHNow, for example.

If you want to be part of a community that HELPS DEFINE #digitalhumanities please join and promote #DHThis today! http://t.co/VTWjtGQbgr

— Adeline Koh (@adelinekoh) September 10, 2013

This is great stuff, but it’s also not going to be a venue for me wittering on about Digital Classics or text encoding. It could be my impostor syndrome kicking in, but I really doubt they’re interested.

It does seem like a side-effect of the shift toward a more theoretical DH is an environment less welcoming to participation by “staff”. It’s paradoxical that the opening up of DH also comes with a reversion to the old academic hierarchies. I’m constantly amazed at how resilient human insitutions are.

If Digital Humanities isn’t really what I do, and if Programmer comes with a load of toxic slime attached to it, perhaps “Senior” is all I have left. Of course, in programmer terms, “senior” doesn’t really mean “has many years of experience”, it’s code for “actually knows how to program”. You see ads for senior programmers with 2-3 years of experience all the time. By that standard, I’m not Senior, I’m Ancient. Job titles are something that come attached to staff, and they are terrible, constricting things.

I don’t think that what I and many of my colleagues do has become useless, even if we no longer fit the DH label. It still seems important to do that work. Maybe we’re back to doing Humanities Computing. I do think we’re mostly better off because Digital Humanities happened, but maybe we have to say goodbye to it as it heads off to new horizons and get back to doing the hard work that needs to be done in a Humanities that’s at least more open to digital approaches than it used to be. What I’m left wondering is where the place of the developer (and, for that matter other DH collaborators) is in DH if DH is now the establishment and looks structurally pretty much like the old establishment did.

Is digital humanities development a commodity? Are DH developers interchangeable? Should we be? Programming in industry is typically regarded as a commodity. Programmers are in a weird position, both providers of indispensable value, and held at arm’s length. The problem businesses have is how to harness a resource that is essentially creative and therefore very subject to human inconsistency. It’s hard to find good programmers, and hard to filter for programming talent. Programmers get burned out, bored, pissed off, distracted. Best to keep a big pool of them and rotate them out when they become unreliable or too expensive or replace them when they leave. Comparisons to graduate students and adjunct faculty may not escape the reader, though at least programmers are usually better-compensated. Academia has a slightly different programmer problem: it’s really hard to find good DH programmers and staffing up just for a project may be completely impossible. The only solution I see is to treat it as analogous to hiring faculty: you have to identify good people and recruit them and train people you’d want to hire. You also have to give them a fair amount of autonomy—to deal with them as people rather than commodities. What you can’t count on doing is retaining them as contingent labor on soft money. But here we’re back around to the faculty/staff problem: the institutions mostly only deal with tenure-track faculty in this way. Libraries seem to be the only academic institutions capable of addressing the problem at all. But they’re also the insitutions most likely to come under financial pressure and they have other things to worry about. It’s not fair to expect them to come riding over the hill.

The ideal would situation would be if there existed positions to which experts could be recruited who had sufficient autonomy to deal with faculty on their own level (this essentially means being able to say ‘no’), who might or might not have advanced degrees, who might teach and/or publish, but wouldn’t have either as their primary focus. They might be librarians, or research faculty, or something else we haven’t named yet. All of this would cost money though. What’s the alternative? Outsourcing? Be prepared to spend all your grant money paying industry rates. Grad Students? Many are very talented and have the right skills, but will they be willing to risk sacrificing the chance of a faculty career by dedicating themselves to your project? Will your project be maintainable when they move on? Mia Ridge, in her twitter feed, reminds me that in England there exist people called “Research Software Engineers”.

Notes from #rse2013 breakout discussions appearing at https://t.co/PD0ItLBb8t - lots of resonances with #musetech #codespeak

— Mia (@mia_out) September 11, 2013

There are worse labels, but it sounds like they have exactly the same set of problems I’m talking about here.

Missing DH

I'm watching the tweets from #dh2013 starting to roll in and feeling kind of sad (and, let's be honest, left out) not to be there. Conference attendance has been hard the last few years because I didn't have any travel funding in my old job. So I've tended only to go to conferences close to home or where I could get grant funding to pay for them.

It's also quite hard sometimes to decide what conferences to go to. On a self-funded basis, I can manage about one a year. So deciding which one can be hard. I'm a technologist working in a library, on digital humanities projects, with a focus on markup technologies and on ancient studies. So my list is something like:

• DH
• JCDL
• One of many language-focused conferences
• The TEI annual meeting
• Balisage

I could also make a case for conferences in my home discipline, Classics, but I haven't been to the APA annual meeting in over a decade. Now that the Digital Classics Association exists, that might change.

I tend to cycle through the list above. Last year I went to the TEI meeting, the year before, I went to Clojure/conj and DH (because a grant paid). The year before that, I went to Balisage, which is an absolutely fabulous conference if you're a markup geek like me (seriously, go if you get the chance).

DH is a nice compromise though, because you get a bit of everything. It's also attended by a whole bunch of my friends, and people I'd very much like to become friends with. I didn't bother submitting a proposal for this year, because my job situation was very much up in the air at the time, and indeed, I started working at DC3 just a couple of weeks ago. DH 2013 would have been unfeasible for all kinds of reasons, but I'm still bummed out not to be there. Have a great time y'all. I'll be following from a distance.

First Contact

It seems like I've had many versions of this conversation in the last few months, as new projects begin to ramp up:

Client: I want to do something cool to publish my work.

Developer: OK. Tell me what you'd like to do.

Client: Um. I need you to to tell me what's possible, so I can tell you what I want.

Developer: We can do pretty much anything. I need you to tell me what you want so I can figure out how to make it.

Almost every introductory meeting with a client/customer starts out this way. There's a kind of negotiation period where we figure out how to speak each other's language, often by drawing crude pictures. We look at things and decide how to describe them in a way we both understand. We wave our hands in the air and sometimes get annoyed that the other person is being so dense.

It's crucially important not to short-circuit this process though. You and your client likely have vastly different understandings of what can be done, how hard it is to do what needs to be done, and even whether it's worth doing. The initial negotiation sets the tone for the rest of the relationship. If you hurry through it, and let things progress while there are still major misunderstandings in the air, Bad Things will certainly happen. Like:

Client: This isn't what I wanted at all!

Developer: But I built exactly what you asked for!