Do I have to learn to code to do digital humanities? | The parts “teach yourself” resources skip

Nope. Coding is absolutely not required in digital humanities. There are a million things you can do in the world of DH without “knowing how to code.”

For a long time, I was a gung-ho “every digital humanist should learn to code” person. I now have a better understanding of the inequalities, inequities, discrimination, and harassment in programming culture that make that advice icky. Miriam Posner has a good blog post on this subject.

I’d be lying if I said I didn’t think there are some great reasons to learn to code, though. And if you’re here reading this, there’s a good chance you’ve encountered a reason or two in your own work. Something that an off-the-shelf solution can’t quite solve.

Back in November, Katherine Bowers, Quinn Dombrowski, and Roopika Risam discussed their “coding stories” in the 12th installment of The Data-Sitters Club (this is super amazing and you should read it). Their stories, especially Risam’s, spurred me to finally write on this topic. In one part of her story, Risam says:

I was a woman of color and not socialized to code and therefore I couldn’t do it, didn’t need to do it, and everything was fine…. In my head, in order to code you had to have done a degree in computer science or a coding bootcamp, where all the code was downloaded into your head and just waiting for you to execute it.

Roopika Risam

As someone who was socialized to code, I think it’s important for me to try to make things easier for folks who weren’t but want to learn. To share the things I was taught that I don’t see others sharing. To (maybe?) help dispel the illusion that all the CS students had code downloaded into their brains, and if you didn’t you’re out of luck.

This post is about those things: the parts of programming that the “coding for digital humanities” resources leave out.

My coding story

My brother is 9 years older than me and has always loved computers. He’s a software developer now. When I was a kid I looked up to him so freaking much— I wanted to do everything he did. When I was in high school, he taught me how to set up a WordPress site and I got a “job” being the “webmaster” for a local spa owned by my mom’s friend. I had no idea what I was doing,

When I got to college, I didn’t know exactly what I wanted to do with my life, but I definitely wanted to learn to program “for real.” Plus, something like 85-90% of undergrads at Stanford took the intro to programming class when I was there, so it was kind of weirder not to.

This was, obviously, a huge privilege. CS 106A, the intro class, is extremely well-taught. (Bit of a chicken and egg situation: is it so well-taught because it’s so popular and therefore needs to cater to a wide audience, or is it so popular because it’s so well-taught? Definitely a little of both.)

After that, I worked my way (sometimes quite painfully) through more computer science classes and got involved in digital humanities projects that used my coding skills. Those DH projects turned me into an English major, and here I am.

The parts the “teach yourself” resources tend to skip…

I was incredibly privileged to learn to program in a top computer science department that pours a ton of resources and enthusiasm into teaching their intro classes. I am a firm believer that you do not need the kind of formal training I have to learn to code in a way that supports your work. Which I know is rich coming from me.

What I can offer is this: There are some important things about the way programming is taught in classrooms these days that the “learn coding for digital humanities” resources tend to skip. It feels like there are “secrets” people with the privilege of formal training are keeping (intentionally or not) about the way we were taught that might make it easier for others to learn! So I want to share some of those.

I didn’t start with, like, actual code

Programming is problem-solving. And programming languages are more like human languages than you might think. If you have a problem, and you need to explain a solution to someone who speaks German, your first step doesn’t have to be “learn German.” Your first step can be “solve the problem.” It might help to know what kinds of ideas can be expressed through language so you have some direction to go in, but you don’t need to become conversational in German right away. In fact, you might get so buried in verb conjugations that you lose sight of the problem entirely!

What I’m saying is, you don’t have to go “learn Python” right away. In fact, I don’t even really recommend it. First, it’s helpful to learn

1. How to give detailed instructions, which you probably already know how to do. [NB: A fun exercise to practice this (especially in groups!) is to trying giving someone exact instructions for how to make a PB&J.]
2. The kinds of instructions computers can understand, which you can use to build more complicated instructions. Kind of like how a subject, verb, and object are the building blocks of sentences, regardless of language.
3. What we call each of those instructions/building blocks. The lingo. How do you say “noun” in German?

That’s why…

I started by telling a pretend robot to turn left

In CS 106A, we didn’t start by learning about Python (or, in my day, Java) rules. We started by giving instructions to a little robot named Karel. (As of writing this anyway, you can see a few basic Karel lessons online if you want to try it out).

Karel lives in a grid world. She knows how to do four things: move forward, rotate her body left (counterclockwise), pick up a diamond, and put down a diamond. You’re given a starting position and using only those four instructions you have to make the world look like the goal.

That’s not so bad, right? Move forward, put down a diamond, turn left, move forward.

But what if you want to turn right? Karel only knows how to turn left… Well, you can turn left three times! But maybe you don’t want to say “turn left, turn left, turn left” every time you want her to turn right. So you say hey, here’s a new rule Karel: “turn right” means “turn left, turn left, turn left”. But what if we don’t want to type “turn left”a bunch of times, even that once? Luckily, we can tell Karel to do something a certain number of times! We could say “turn left 3 times.”

This is how Stanford CS introduces basic programming concepts, those building blocks I talked about. Teaching Karel a new rule is like writing a function, and asking her to do something 8 times, that’s a loop.

Knowing how to write the code is important. But more important is knowing what kinds of things computers can do.

Knowing how to write functions and loops in Python requires knowing what those are! Learning the kinds of things our computers can be asked to do is more than half the battle. Like remember a value (stored in a variable), repeat a task a certain number of times (in a loop), or act different ways under different conditions (using if/else statements).

There is a real dearth of free resources out there (aimed at adults!) that take a concept-before-code approach. The Codecademy “Basics of Programming” series is the best one I know about. [If you have recommendations, please leave a comment or message me!]

Learning those basic things can suck sometimes. It feels like you’re a long way off from being able to do the kind of project you want. But you’ll save yourself a lot of frustration later if you take a little while to start with the basics!

My Top Tips for Learning to Code

These are the things that I think make learning to code way easier.

1. Have a fun project in mind

When learning in a classroom, you have homework assignments that, hopefully, are fun projects to code. When learning on your own, you have to find that for yourself. Whatever digital humanities dreams started this coding journey, turn a piece of them into a project. You’ll probably bite off more than you can chew, but that’s great!

2. Pseudocode, aka no code just vibes

Pseudocode is something I haven’t seen taught in any of the free resources I’ve read. And, wow, is that a disservice. Writing in pseudocode is writing, in your spoken language, what you want to program to do. This makes an outline that you can later fill in with actual code. It’s a way to keep yourself sane when programming something complicated or new to you.

We practiced pseudocode a lot when I was in school, and it makes coding a lot less scary (for me).

You get to work out the details of the task you want to accomplish, and how you want to accomplish it, before worrying about where parentheses and dots go.

Here’s an example. Recently, I needed to export a bunch of data from a tool that doesn’t have export built-in. I also needed to use information from our task-tracking tool to know which batches of data were ready for export. Here is how I broke the problem down in pseudocode.

Log in to both tools
Find the batches of data that are ready to be exported
For every batch that's ready:
 * find the URL we have saved and get the ID from it 
 * Use the ID to get the CSV export URL
 * Download the CSV and save it as "batchX.csv"
Merge all the saved CSVs into one, called "allBatches.csv"

When you know conceptually what you want to do, you can look up how to write it. Which brings me to another important point…

3. Google stuff A LOT.

I code in both Python and Javascript a lot, and yet here is a look at my recent search history:

I forget how to do even the most basic things in these languages that I use every week. But that doesn’t matter, because I’ve learned how to search for what I need. That’s why understanding the kinds of things you can ask a computer to do is so much more important than knowing the exact syntax to use.

Even professional, full-time, been-coding-for-20-years folks have to Google stuff all the time.

Knowing what to search to get the answers you need is a skill that takes time to develop, like anything. But here are the tips I can offer.

1. Include the name of the language you’re working in. You’ll notice in my screenshots all those searches start “python…” or “javascript…” Since different languages do things differently, you want to make sure you’re not wasting time on a solution that won’t actually apply.
2. Copy/paste error messages into Google. Odds are good someone has had that error before, or one close to it, and will have posted on Stack Overflow “How do I fix this?”
3. Check the Stack Overflow results first. Stack Overflow is a Q&A board for programming, and it’s the most helpful resource out there. It’s almost a guarantee that someone has asked your question before & recieved several answers, and that the community has discussed & voted on which answer is the best in the comments. And if there isn’t an answer to a question you have, you can post the question yourself & consider it a contribution to the wider community, saving the next person who encounters your problem.
4. Try searching the same thing in a couple different ways. If you’re a humanities scholar, you know this. Sometimes you have to ask a question a few different ways before you find what you’re looking for. We tell students this all the time when teaching library resources, right? Those digital research skills we teach in humanities classrooms apply to coding questions, too! Generate some keywords related to your query and try different combinations.
5. Ask a friend. Even if they can’t solve your problem, they might know an additional keyword that will help, or reframe the question in a slightly different way that lets you search the answers you’re looking for.

4. Keep a stuffed animal near by

There’s this thing in software engineering called rubber ducking, or rubber duck debugging. It’s where you explain your code to a little rubber duck sitting on your desk, and magically the duck shows you how to fix the problem you’re facing.

This works because often, taking a minute to say things out loud is enough to spot issues. If you’ve ever taught writing, you’ve probably recommended students read their paper drafts out loud as part of the revision process. When we read things we’ve written in our heads, whether they’re essays or programs, our brains skip over and fill in things based on our expectations. Reading or explaining something out loud forces us to go slowly and see what we’re really doing, rather than what we think we’re doing.

I don’t own any rubber ducks, but I do have many stuffed animals and a few living pets. Keep one of them on hand when you’re working, and explain your problems to them out loud. It helps.

5. Find a community

Your rubber duck will only get you so far. It’s more fun to learn with other people! Despite the image of a dude in a hoodie sitting alone at his computer screen for hours on end, programming is better with community. Classroom students have the benefit of each other, a built-in coding community. If you’re learning outside that context, you have to find or build your own community to support and encourage you. There are online groups like R-Ladies that can be good resources [I’ll add to this as I find more!]

You can also seek out (or start) a mailing list or study group on your campus or in your town. When I was trying to learn R, I sent around an email and found a small group of folks who wanted to learn, too. We met every two weeks and slowly made our way through Humanities Data in R. There was a huge variety of prior experience in our group– some folks who hadn’t coded at all before, some who were new to R but not coding in general. We were able to help fill in the gaps for each other in a low-stakes environment.

6. Remember that you don’t have to code well.

A frankly frightening number of critical systems in the world of technology are held together by weird bandaid solutions and terrible, terrible code. Professional developers are always talking about the bad code their colleagues wrote and how awful it is to have to reuse or rework it.

If they can write bad code, so can you.

You don’t have to have pretty, efficient, perfect, optimized code. You can do things the “wrong” way. If it gets you the result you need, it gets you the result you need.

Remember that, like with anything, the more you learn, the more you’ll realize you don’t know. Don’t let that stop you! If you can’t figure out the “right” way to do something but you have a good-enough solution, use it! Don’t listen to the tech bros who complain about humanists writing bad code. Everyone writes bad code.

You absolutely don’t need to code. If you want to, there are ways to make it less scary.

I hope that at least something in here is helpful to someone out there. If you know of any great resources or communities that digital humanities people on a coding journey should know about, please share! And if there’s anything in this post you’d like to know more about, please let me know. You can reach me here or on Twitter. If there are other ways I can help spread the proverbial wealth I would be happy to <3