Recently I had some time on my hands I could dedicate to reading something new, and encouraged by many enthusiastic tweets, I chose Colleen Morgans “Avatars, Monsters, and Machines: A Cyborg Archaeology”. I loved it! One thing especially stuck with me:
For digital archaeological practitioners, failure is a default position: to experiment with new technology and to use it in an unorthodox fashion is to fail spectacularly and repeatedly […] and teaching these technologies leaves an astonishing wreckage of half-realized models, broken databases, and drone videos of grass and boots. (p. 330)
Sh*t, don’t I know it. And the wreckage wasn’t created by my students. It was created by myself, mostly.
Monstrous data management
I struggle hard with loads and loads of data I still have somewhere, usually in some folder labelled “old” or in x slightly differently named folders, because at some point I thought “oh, before I destroy something, I better create a copy with which I’ll continue working”, and, because simply version-numbering the folder name would be boring, I am *so* creatively calling things “percolatransect”, “percopackage”, “perco-perk” or something similarly stupid, and half a week later I don’t remember which was which and have to reconstruct the latest version via “date last changed”. And I don’t delete. I’ve got an aversion against deleting. You can imagine where this leads to.
Yeah. Morgan calls this “a vast digital graveyard of failed projects”.
I feel so seen.
But the worst?
Actually, I am using git.
I use a system for version control, which should enable me to navigate the graveyard easily, which will create branches for me and track the development of my projects and these horrors of x different folders per project just shouldn’t be.
Shame. On. Me.
Why do I do this unnecessary copy-and-pasting?
Just git it done
I guess, a significant part of me doesn’t trust git completely yet. That might be due to my lack of experience so far. I’ve not yet needed to jump back along the branches and restore an old commit to continue working from there. Especially when I want to delete things to tidy up a bit, I tend to create a new folder, which kinda destroys the whole purpose of trying to tidy up, if you get my meaning (btw: don’t ask what my desk usually looks like…).
But is this safeguard behaviour of mine really necessary?
There’s a small but helpful collection by Katie Sylor-Miller on “Oh shit” – moments in git and how to resolve the problem, aptly named: “Ohshitgit.com“. The things I am afraid about can be reversed in git. This is it’s purpose.
I need to keep this in mind.
The important lesson is to document the paradata (Denard, 2012), to reveal the monstrous underbellies of our virtual realities, failed and fully realized.
Denard makes her point in regards to the London Charter and the paradata he’s talking about are to document the process of creating 3D visualisations so that the creators’ decisions are traceable. 3D and virtual reality implementations in archaeology are also Morgan’s focus in her paper. That’s more Sebastian’s field of work, I’m rather muddling around with GIS and R for quantitative analysis. But nonetheless my analyses have “monstrous underbellies” (I read this as digital grave yards and loads of hidden decision making) as well.
Now my first thought upon reading that we should “reveal the monstrous underbelly” and not only keep track of changes and fails in digital archaeology but also to publish them brought me back to git and github. It’s the perfect tool for this task. Especially for code, git and github are already the tools of choice of loads of researchers to keep track of changes, archaeologists as well (see e. g. Iza Romanowska, Ben Marwick, María Coto-Sarmiento, Clemens Schmid).
It’s just… Putting failures out there for everyone to see is scary and it may feel a bit like opening the underwear drawer to everyone. It’s even one step further than sharing code and data. Many researchers will not feel safe in doing so and I guess there’s a number of reasons. One would be the capitalistic thought system discouraging anything that is not streamlined to productivity. We are conditioned to project a perfect self online and would like some privacy while learning something new. Open researchers might fear to be “ripped off” mid-process, because some people are a*holes or might not now about citation standards. For further reading on problems with digital scholarship in general I recommend Hugget 2019. Also, who wants to read this all?
Well, obviously archaeologists of the future…
But what else may be a benefit?
Showing how code or a paper was developed may help others to evaluate it better or to get a better understanding of such a process altogether. By showing the fails and mishaps of my coding I may be able to show non-coders that it takes time. It’s not always easy to create a fitting solution and I believe people underestimate the time it may take to code a solid analysis. As has been argued elsewhere Research Software Engineers need to get credit for their hard work. And as non-coders only see the wizardry outcome, they might underestimate the thought going in there. Also, those struggling with writing a paper might be encouraged to see a non-straightforward workflow of someone else. A friend editing a volume once told me that this huuuuugely important professor writes horrible first drafts. This was *so* encouraging to hear! It helped me understand that writing is rarely a matter of strokes of genius but rather continuous re-drafting, that it’s fine to produce something not-great for a start. And the other way around works as well: If someone is struggling it might be easier for him/her to get help, when the work is already accessible online.
Improving workflows with git
On top of that, I’ve recently found out that it is quite common to write a letter to the editor after finishing corrections to your paper, in which you describe the changes you made in response to the peer reviewers comments. How easy that’d be with github! Commit message “Rev. A valuable input on line 425 implemented” and the letter would be unnecessary.
Deciding what to show and what not
So, yeah, everyone working digitally on projects knows that there’s a huge digital grave yard and a monstrous underbelly to all our projects. I’m not sure I would want *everyone* to see *all* my failed attempts and learning progresses. And I believe that is fine. I’ve got a right to privately figure things out, just as I would never ask a student to sign something online with his/her true name. A number of my work in progress repositories on github are private for that reason. But at some point it is sensible to let go of perfectionism and just put the stuff out there. If someone makes fun of a mistake s/he is an a*hole and I will not work with that person in the future. Other people will notice his/her behaviour and react similarly (I hope). All in all if a mistake is pointed out to me, I will be consternated but glad, ’cause knowledge is always work in progress and I will have learned something new. Nobody is perfect after all. The “monstrous underbelly”, if shown, would make this clear for everyone about everyone. And this, in itself, would be a huge step towards a more friendly and egalitarian community of researchers. In my experience the researchers who are most generous in sharing and helping others are also the most open scholars, happy and able to take constructive criticism. I try to follow their lead.