When I first started learning to program in college, I frequently heard professors in entrepreneurship classes and computer science classes framing concepts or technologies as “so easy, your mom could understand it.” I always bristled at those comments because it made my mom—who is perhaps the most tech-savvy one in our entire family and the only one who has figured out iCloud—seem so technically incompetent that she was the minimum benchmark against which we could measure understanding. The phrase and its permutations (i.e. “will it work for your mom?”) were so pervasive that it showed me that industries like technology, where words and communication are sadly undervalued, still have a language problem.

At this year’s SRCCON, I facilitated a session inspired by Thursday Bram’s article in the feminist hacker zine The Recompiler called “Bad Metaphors.” Metaphors that are convoluted or draw from non-universal experiences add an additional dimension of complexity for learners: not only do learners have to understand the concept the metaphor is trying to teach, but they also have to understand the comparison to which the concept is being made. Let’s say someone tried to explain JavaScript Promises to me with a football metaphor. As an individual who knows very little about football, I would first have to take time to learn the rules of the game before I learned what Promises actually are or how they work. On the other hand, as an avid burger connoisseur, I would find a blog post discussing Promises through “The Promise of a Burger Party” much easier to understand.

Inclusive metaphors that take into account a more diverse range of experiences can facilitate technical understanding of concepts, topics, and processes across interdisciplinary teams that work in news and media. Good metaphors can help people who are learning to code analyze and visualize data. They can be useful in technical documentation or project write-ups, particularly if the intended audience does not have a technical background. They can also be used simply to make day-to-day communication easier so that every team member has a high-level overview of how technical work is progressing.

In her article, Bram acknowledges the importance of metaphors for teaching programming concepts, but points out that metaphors are not just learning tools—they are also reflections of our experiences, backgrounds, and biases. “These sorts of metaphors don’t just make learning new concepts harder,” writes Bram. “They can wind up dictating the culture that we see every day in the software industry.” For example, the “master/slave” terminology used in database configurations carries racial connotations. Drupal and Django have since moved away from this terminology and replaced it with more inclusive terms like “leader/follower” or “primary/replica.” The term “open the kimono,” often meaning disclosing business information or showing what’s really happening behind-the-scenes, is both gendered and racialized. Within journalism tech circles, a better awareness of how our experiences influence the metaphors we use to teach new material will help us understand the ways in which the language we use can influence our industry and culture both positively and negatively. At SRCCON, we aimed to focus on the positive by coming up with a tangible list of useful teaching metaphors.

Topics in Need of a Metaphor

We brainstormed candidates for metaphors by thinking about what terms, concepts, and processes that we think would benefit from explanation on interdisciplinary teams. These were often things we personally struggled to understand or explain, or terms that we often heard but did not have a complete understanding of.

The large buckets of our brainstorming were in the following areas:

• Web development: APIs, HTTP/HTTPS, client/server, front-end vs. back-end vs. full-stack
• Security: PGP, 2FA, OAuth, encryption, secure drop
• Process and workflow: Open source, licensing, code review, version control (and GitHub), accessibility
• Data: Web scraping, map projections, correlation vs. causation
• General programming concepts: Caching, troubleshooting and debugging, concurrency, structured data, regular expressions

What Makes a Good Metaphor

Ultimately, the best way to evaluate a metaphor is by testing it out for real by pairing people who want to learn a concept with people who want to teach it. However, to guide the brainstorming, I designed a rubric to evaluate what makes a “good” metaphor:

• Completeness: Does the metaphor explain the important parts of the concept? How does the metaphor hold up if you extend the concept in even more technical ways?

• Memorable: Is the metaphor easy to remember? Is the metaphor creative?
• Inclusive: Is the metaphor inclusive of people with different identities (gender, race, sexuality, etc.), backgrounds, and experiences?
• Accessible: Would people with different backgrounds and experiences from your own understand the metaphor and its explanation?

New metaphors from our SRCCON session. (Nicole Zhu)

New Metaphors for Your Next Explanation

At the end of her piece, Bram called for “more metaphors sprouting from a much wider variety of experiences. We need comparisons to cooking, rap, Legos, and a million other things.” The wonderful folks at SRCCON did not disappoint. Here are some of the best metaphors that came out of the discussion:

• Open source is a community garden where people can take clippings and change things in their own ways. Some people take fruits from the garden (or even copy the layout of the property), but some dedicated people must stay and maintain it, for example determining what gets planted. It’s less about the mechanics and more about the community.

• GitHub is shopping at a store. Add adds an item to a cart, commit is swiping your credit card at the checkout, push is bringing it to your car. Messaging is the receipt (record of transactions). Merge is when two people have the same item and have to figure out which one is the one you’ll use. Revert is returning something to the store.

• Concurrency is a track meet, where many different events occur at the same time, unlike a relay race where a baton is passed off from person to person.

• Caching is storing food in your pantry. The most-used foods are kept at the front, while the least frequently eaten foods are kept in the back. Different foods, like different kinds of data, have varying expiration dates, past which time they should be thrown out or restocked.

• Web accessibility is like making a building accessible. If you replace stairs with wheelchair ramps, people with wheelchairs can use it, but so can people who can walk. Universal design benefits everyone.

• Maintaining code is like sailing a boat. You have to adjust the sails in response to changing weather conditions, and you sometimes run into unexpected situations.

• Troubleshooting and debugging is testing the boat for seaworthiness, like checking for leaks or making sure you have an active and helpful crew.

Best metaphors from the technical metaphor session: 1/ VPN is like a person on the subway hiding their book with a newspaper. #srccon

— Karen Hao (@_KarenHao) August 3, 2017

A caching metaphor inspired by a talk at #srccon by @nicolelzhu: When you go to a restaurant and order soup the chef has to start a new pot.

— Alex Robertson (@alexlrobertson) August 7, 2017

For a full list of our brainstorming results, see the session notes or the session transcript.

Conclusions and Further Reading

Language is not neutral, nor is it static. Bad metaphors can hinder learning as well as create hostile industry culture, while good metaphors can facilitate understanding, promote teamwork, and foster empathy for the diverse people working in our industry. Erin McKean, creator of Wordnik, posed a crucial question in a discussion on the renaming of the “master/slave” terminology that I think, as creators working in or adjacent to technology, we should always be asking ourselves: “Are you going to prioritize a conventional somewhat clunky, not truly evocative metaphor over real human beings having real problems with the terminology?” McKean thinks, “if there’s a choice between language and people, then choose the people.” I think this aligns perfectly with the values of SRCCON and Source as spaces that allow us to acknowledge our full selves. Our community is first and foremost about the people, the rest—language, culture—is malleable.

Find (good) metaphors in the Sideways Dictionary—or add your own. For more programming metaphors, buy Amy Wibowo’s BubbleSort Zines on computer science, follow Vaidehi Joshi’s basecs series, or read Mariko Kosaka’s blog. Sally Lait also has a great article on “Cooking up effective technical writing.”

• Share on Twitter
• Share on Facebook