Eight Questions For Bryan Behrenshausen
Welcome to another edition of Eight Questions For …, where I pick the brains of plain text enthusiasts from around the world and around the web.
This time around, I chat with writer, editor, and teacher Dr. Bryan Behrenshausen. Bryan works for GitLab and is an adjunct professor in the Innovation and Entrepreneurship program at Duke University, where he developed and taught a course at Duke.
I’ve known the good doctor for a number of years. We bonded over the our mutual love of both plain text and open source. As an academic and a writer, Bryan’s always learning new ways to use and manipulate plain text. And, in the open source way, he shares what he learns.
Let’s hear from Bryan:
When did you start using plain text?
I really began using plain text in earnest when I decided to use open source software exclusively. That transition began some time in 2007 and completed in 2010.
Looking back further, however, I think I can say my initial experiments with plain text occurred when I was falling in love with my first computer, a Commodore 64 my grandparents gave me when I was in elementary school. I’d meticulously copy programs reprinted in publications like BYTE Magazine and save them on floppy disks. Most never worked (or I’d impatiently abandon them).
The C64 operated with the PETSCII character set (an ASCII derivative), so perhaps I wasn’t technically using what we today consider true plain text. But more important here is what I learned by working that way: the value and appeal of lowering barriers to composition (in the case of the C64, for instance, you simply switched it on and started typing). That stuck with me.
Why did you start using plain text?
Since my turn to plain text coincided with my adoption of open source tools, it tracks with a period of broadening awareness of open values and principles. Because I like to write, I’ve collected many documents over the years (I save everything because you never know), and roughly a decade ago I began to see that archiving those documents in proprietary formats posed the risk of making them inaccessible some day. I’d rather not entrust my work to the caprices of the file format wars. Using plain text is a future-proofing tactic.
But the more I grew accustomed to working in plain text, the more I realized the amount of joy it added to the work of writing. Like most people my age, I learned to compose electronic documents with an application called a word processor and grew up under the misguided assumption that it was the best tool for that job. It can be, for sure, but it’s a cumbersome and ill-fitting one at best, since facilitating writing isn’t its primary function. After all, “writing” is not “processing words”. Only after (re)discovering plain text did I understand the deleterious effects of that unfortunate confusion. I’m much better off now.
What do you use plain text for?
Plain text is my preferred vehicle for accomplishing anything that requires working with words: organizing a syllabus, making a to-do list, making tests and quizzes, drafting a long email, keeping a journal, outlining a lecture or presentation, jotting notes—essentially anything that requires me to input characters with a keyboard.
But I use plain text primarily for writing. And by “writing,” I don’t just mean “composing prose sentences”; I mean all those activities associated with the process of writing. That includes sketching notes, creating outlines, composing drafts, editing works-in-progress, and (whenever possible) sharing it with others for feedback. Very few (if any) of my projects begin life as something other than a text file (and those that do are most likely to begin as handwritten notes).
I think my crowning achievement, though, is writing my entire doctoral dissertation in plain text. I wrote individual chapters as text files, formatted them with Markdown, ran them through Pandoc to concatenate them into the final document, then spruced up all the formatting to meet the graduate school’s stringent publication requirements. It was so unremarkable, simple, and mundane—something I can’t even believe I took the time to elaborate for you here. But it made me feel so badass.
What keeps you using plain text?
When I want to work, I want to minimize distractions to the greatest possible degree. That’s just the environment I need (for writing especially). Any application that offers to do more than accept my plain text input is a source of potential distractions for me. Fiddling with margins, changing fonts, snapping toolbars so they are perfectly aligned — it’s all stuff that exacerbates writer’s block on a particularly bad day, and unfortunately I succumb to all of it. Plain text saves me from myself.
Words have always been my preferred medium for creative work, so I tend toward tools that keep me laser focused on words. I recognize and truly do believe that any creative activity is the product of incalculable intersecting and overlapping materials and forces.
But I will admit that I still do like to romanticize The Word — to entertain the myth of unencumbered expression emerging from deep within some amorphous, creative wellspring and pouring forth into a vessel. It’s a model of creativity that simply isn’t adequate or helpful (it’s actually rather counterproductive!). Writing in plain text fuels the delusion. It lets me pretend I’ve encountered words in their Platonic form.
Much more practically speaking, however, I appreciate how uncomplicated plain text makes my life. Anything I save in plain text will open and render just about anywhere and at any time. It will shuttle between any system or environment with ease. It’ll back up quickly and require so little storage space. Working with plain text just produces this sense of incredible lightness; it allows users to live what someone very astute (though I now forget precisely who) once described to me as “a floating life.”
Do you use any markup or formatting languages? If so, which ones and why?
I’m a Markdown guy, through and through. John Gruber created that language specifically for prose-style writers working in plain text, and he did the world such a favor when he did.
Once I have something in Markdown, I can turn it into anything else my heart may desire (more on that later).
What are your favourite plain text tools or applications?
My go-to tool for working with plain text is whatever comes installed by default on the Linux distribution I happen to be using at the moment (right now that’s Xed, because I’m on the Fedora Cinnamon spin). I try not to get too attached to any single tool so I can retain flexibility if (read: when) I move across environments. When in unfamiliar territory, I open a terminal and launch nano.
To sync plain text across computers, I’ve found nothing better for me than Standard Notes. It’s lightweight, reliable, inexpensive, and (most importantly) secure. I really admire what the team behind it set out to do by launching it, and I’m proud to support it.
I used to maintain my public notebook using Dropplets. It’s a databaseless blogging tool specifically designed to facilitate writing and publishing in plain text via Markdown. With Dropplets, I wrote a notebook entries in plain text, marked it up with Markdown, and uploaded it. Templating is simple enough that even I can handle it, so those plain text files look slick as soon as they hit the web. And because the software works without a database, all my writing is easily version controlled and portable. A dream.
Dropplets is open source, and I suppose I’m also partial to it because it’s the first project to which I made an upstream code contribution (such as it was!).
(Note: In case you’re wondering, Bryan maintains his public notebook using Blot.im, which I’m hoping to look at in some depth in the near future.)
Is there one tool that you can’t do without?
My favorite plain text tool is Pandoc — a text conversion application that takes text in one format and converts it into another. In fact, I’ve already gone on record saying it’s my most beloved application in general. I stand by that.
By using Pandoc, I’m able to avoid the kind of tinkering and overthinking that often stands in the way of actually accomplishing something. I can sit down, open a text editor, and make what I need to make; formatting is an afterthought. I know that later on Pandoc can spit out whatever I might need it to. It helps mitigate an obsession with foresight and lets me focus on the task at hand, knowing that I’ll be able to generate additional formats as unforeseen needs arise.
Is there anything you can’t do with plain text?
At the risk of having you refuse to publish this interview, I’m going to say “footnotes.” Scott has for years been patiently helping me find a way to integrate plain text footnotes into my writing projects and is by now quite sick of my asking for recommendations. (Editor’s note: not quite yet …)
On the whole, I wish academic writing was easier to do in plain text. And I work in the liberal arts, so my writing requires few equations, tables, and diagrams — those things that plain text devotees often have difficulty handling. Just as coding is possible in a text editor but easier with an IDE, so too is academic writing simple enough with an editor but much more pleasant with specialized software.
Tools that treat clusters of documents as a project are ideal. I just haven’t found anything like this that traffics principally in plain text (a Plain Text Project, if you will) and, since that’s a prerequisite for me, every possibility has been a non-starter. The closest I’ve gotten is WordGrinder, which I will say is pretty great (albeit most appealing to people undaunted by command line applications, and I tend to perform most of my work with a GUI). Similar applications are nice but tailored for creative writing—brilliantly useful in that context, for sure, but not really drop-in solutions for academic writing tasks.
But thanks to the interview with Michael Healy, I learned about BibTeX and am eager to experiment with it. I also just discovered Zettlr, which at first blush seems perfect for me — but first I’ll want to speak with my buddy Fedora program manager Ben Cotton about getting it accepted into the Fedora software repositories.
You can learn more about Bryan and what he does at his home page.