This article is for the English majors, the bookworms, the lovers of literature, and the people with humanities backgrounds who sometimes struggle with the question, “So do you ever use your English degree?” It’s also for the people who’ve asked that question of their colleagues with non-STEM backgrounds, who’ve been confused about how someone could start in psychology and end up in Python.

The truth is that technology and humanities aren’t so far apart; in fact, a lot of concepts we English majors perfected over our thesis papers get used in our daily lives as developers. This article isn’t about what coders can learn from humanities majors or vice versa. It’s a demonstration of the overlap between the two disciplines; a study in their compatibility and how they complement one another.

Before I became a developer for the University of Texas at Austin, I wanted to become an English professor. I got my bachelor’s in English from Auburn University in 2007, and while I was there I did a lot of tech things. I was the webmaster for a professor’s professional website, which was maintained in Dreamweaver and stored on a Zip drive. I also worked in the Technology Center, where I screencasted videos to teach professors how to use Blackboard, and helped them integrate tech into their classrooms in ways I thought were cool.

When I started working on my Master’s in English from Texas A&M University, I still wanted to become Professor Lacey and write scholarly articles about literature. But again, I steered myself into tech roles. I worked in the English Technology Center instead of being a teaching assistant, and I helped faculty screencast, make videos, use Moodle (an open-source version of Blackboard), and find ways to integrate Google Docs into their classrooms. I also worked for the World Shakespeare Bibliography, where I researched scholarly articles on Shakespeare and then wrote summaries on them. I had to use some markup so that the admin could copy and paste my summaries into the site, but what I didn’t know was that I was sort of coding.

In 2009, I took a workshop on TEI: The Text Encoding Initiative. TEI is an XML markup language that’s specific to manuscripts. It has lots of awesome, specific tags for publishers and other information about books, but it also provides ways to talk about handwritten manuscripts that are being transcribed for the web; for example, you can represent in markup that some text was scratched through and replaced with different phrasing. I wanted to make a site, using TEI, to talk about Jane Austen fan fiction.

But I felt like I didn’t know how. I was really tech-inclined and tech-interested, but not very tech-savvy. I didn’t know how to register a URL, I didn’t understand what CSS was, and if there were tutorials available to me, I didn’t know how to find them. I also thought it was too hard. I had impostor syndrome before I even started. So I wrote a paper on Jane Austen fan fiction instead.

Guess the source

So let’s play a game called Guess the Source. I’ll put up a quote from a style guide, and you can guess where it comes from:

You should use two spaces after a sentence-ending period.

Is this from PEP8, or Strunk & White?

I hate this particular line from PEP8, because in your regular writing, you should never ever, ever put two spaces after a period. Don’t do it. This is from the days of monospace fonts and typesetting, and we don’t use monospace fonts on the Internet or in printed materials anymore.

Except in code. So follow this rule for writing code, but break it everywhere else. The first clue that writing code has anything to do with writing a research paper or an essay is right there in PEP8, the style guide for Python code: “When writing English, follow Strunk & White.” PEP8 doesn’t even cite Strunk & White. It assumes you know what that means. (For those who don’t, Strunk & White refers to the The Elements of Style, an American English style guide first published in 1959.)

The broader point about Strunk & White is that this is a guide written to help people write clearer, more concise, more consistent, more readable English. PEP8 is also a guide for helping people write clearer, more concise, more consistent, and more readable code.

Plot-driven development

Let’s talk about testing, because testing is a perfect example of where some concepts from your literature class might come in handy. Perhaps you remember the basics of story arc:

• The exposition is where you learn who the characters are, where they are, and the basics of what is happening.
• The rising action is where the problem gets introduced and we start experiencing the events that will lead us to the climax.
• The climax is the most exciting part of the plot. This is where the thing that changes the main character’s fate happens. In Pride and Prejudice, this is would be the scene where Mr. Darcy finally proposes to Elizabeth, and then she tells him she wouldn’t marry him if he were the last man on earth, and then she starts questioning herself.
• The falling action is where things begin to unravel and fall into place.
• The denouement ties up everything in a neat little bow. The end.

We can make use of this arc, which is called Freytag’s pyramid, in testing as well. In fact, that was what first gave me the idea for a talk I gave at DjangoCon Austin, on which this article is based. I was in Harry Percival’s testing workshop at PyCon, and realized that the example of a functional test he gave was a perfect example of Freytag’s pyramid applied to testing. The functional test had:

• Exposition: Harry introduces us to Edith, who’s heard about a to-do app.
• Rising action: Edith goes to the app, finds her way around, and decides to enter an item on her to-do list.
• Climax: Edith’s fate is forever changed. She performs the crucial, pivotal action of adding an item to her to-do list.
• Falling action: She’s entered her item, she sees that it’s been entered and saved for her.
• Denouement: Edith is happy and is going back to sleep.

Before Harry ever writes a single functional test, he writes out this user story that follows Freytag’s pyramid exactly. This way, he knows what path the user needs to take through his site, what they will encounter, what they will do, and how it will all resolve. He can write tests to test that these steps all happen, and then he can write the code to pass those tests.

The path that Edith takes through the app is her user story; Edith herself is a persona. In another world, Edith might be the protagonist in a novel, and this particular journey might be a chapter in what I hope is an otherwise more thrilling story. The ability to write a complete and convincing user story is helped by having studied character development and plot development before. A programmer needs to be confident in what their code is supposed to do, and in what order that’s supposed to happen, in order to effectively test it.

And user stories and functional tests aren’t the end of it. How do we want Edith to react when the app breaks? Do we want her to tear her hair and rend her garments like she’s in a Greek tragedy? I hope not. We probably want to provide her with the tools she needs to correct the error, if possible, or reassure her that we know something went wrong and we’re already on it. Which of these is the more reassuring error message?

Creative thinking is required to determine where our code might break, to build in checks, and to return useful data. Any programmer can return the error message, but to compose an error message that is helpful—rather than intimidating—requires a programmer who is also a creative thinker and possesses excellent written and verbal communication skills.

When you’re writing good tests, you’re doing world building: Accessibility requires empathy, and empathy requires imagination. You can leverage that awesome feeling you get when you get lost in a book and identify with the main character by putting yourself in the shoes of the people using your code. Imagine their struggles and frustrations. Create a persona for them. Fix the things that hinder or annoy them about your app.

But back to the functional test. You know what else this looks like? An outline.

You know what else looks like an outline? Basically, all Python code. Python loves whitespace and indenting and pretty formatting, even more than an English major does.

Python code actually uses a lot of the same formatting as many other written works, such as news stories, blog posts, novels, research papers, and even Emily Dickinson’s handwritten coconut cake recipe. Your function definition is like the title. And your docstring is like the abstract to a research paper, or the forward to a new edition of a favorite novel. The docstring tells you a little bit about what’s coming, and it gives you a peek into the author’s or programmer’s mind. Then there’s everything in the middle: the meat of the function, the paragraphs of the article or story. And finally, you conclude. You return something, and your journey through this particular function is over.

Readability counts

A well-written piece of code will be readable, but what do we even mean by that? Machines don’t need code to be readable, but in PEP20: The Zen of Python, Tim Peters is pretty clear that readability counts. The computer or compiler (or whatever) doesn’t care at all if your code is a mess, as long as it works. But your colleagues care. The people who come after you care. The people who share in your work need your code to be readable.

Writing readable code requires empathy and means that you care about your fellow coder. Readable and conscientiously commented code also helps future programmers understand what you struggled with, or why you made decisions the way you did. Comments can even help you re-orient yourself in your own code. A friend of mine once said, “Comments are like love notes to yourself.” A coworker likes to say that comments are what keep you sane at 3:00 AM when you get the phone call that something has gone catastrophically wrong.

There’s a great example of this from The Outlander Series, which is basically a perfect book series. The Outlander Series is about a World War II nurse who accidentally time travels back to 18th-century Scotland. The story includes war and romance and wonderfulness (and it’s now a pretty great TV series, too, but that’s not the point). At the end of the fifth book, The Fiery Cross—and I promise this is not a spoiler—our heroine Claire is in the 18th century and is the most knowledgeable medical professional for miles. She treats someone who winds up dying, and she’s pretty sure it’s because she gave this patient a medicine they were allergic to. She struggles with whether to write in her journal about what happened. In a previous book in the series, Claire is tried as a witch when townspeople mistake her medical badassery with magic, so she becomes hesitant to write down anything that might later get used against her.

Claire says, “Some future physician here would face the same dilemma; to undertake a possibly dangerous treatment, or to allow a patient to die who might have been saved. Who might that be? I wiped the pen, thinking ….” And then she thinks for a while about how isolated she is, how few doctors there are, how there aren’t many medical schools, and she concludes, “I sat up straight and opened my book. I dipped my pen, and began to write the lines that must be there, for the sake of the unknown physician who would follow me.”

This is why we write readable code: For the sake of the unknown coder who will follow us.

Denouement

When I was in college, I had a roommate who was a journalism major. Niki and I editted each other’s papers, and I would try to get her to use more adjectives to make her writing more exciting. She would tell me to cut my flowery descriptions and get to the point. Most composition style guides and PEPs 8 and 20 agreed with Niki.

“Omit needless words.”
“Simple is better than complex.”
“Vigorous writing is concise.”
“Sparse is better than dense.”

These are edicts from PEP20 and Strunk & White. I won’t specify which line is from which work, because it doesn’t matter (and The Zen of Python devotees will be able to pick them out, anyway). But the point is that they are so similar. Good writing is concise and clear and simple and gets to its point, whether you’re writing a piece of code or an article. I could take the lines from The Zen of Python that aren’t code-specific and email them to my friends who are composition instructors, and they’d print them and hand them out to their classes immediately. In fact, I should do that.

We’re called coders, programmers, or developers. What do we do all day? We write code. We read pull requests. We write tests. We read other people’s code. We write comments. We’re readers and writers. The lessons learned in classes about reading and writing literature are exceedingly relevant to us as readers and writers of code.

“Do you ever get to use your English degree?” I’m often asked. Yes, I use my English degree every day.

Most Open
Month

A collection of articles highlighting first-time Opensource.com contributors.