Empathy-Driven Error Messages

When we think about empathy, we often think about synchronous interactions between two individuals, such as a face-to-face conversation. But these aren’t the only opportunities for empathy, particularly while we’re writing software.

As an example, let’s look at how empathy influences the humble compiler error message. But before we look at the error messages, let’s first look at why and how the compiler (a tool for translating human-friendly code into code a machine needs) was created and how empathy drove its development.

Coding In Human Language

Humans think in concepts. We use words, numbers, and symbols to manipulate information and communicate with each other.

Instructions for Humans (Decimal)

100 + 100        

For a computer to execute instructions that humans write, it needs to have these concepts converted into a series of ones and zeros. This numbering system is known as Base-2 or binary.

Instructions for Computers (Binary)

1100100 00101011 1100100        

In the early days of computing, this conversion was a manual process. As a kind of shortcut, programmers used numbering systems that were different from the Base-10 system that today's kindergarteners learn. Early programmers used Base-8 (Octal). Eventually, Base-16 (Hexadecimal) became more common and is still the most common numbering system for computers today. But this can be a bit confusing. Here's a look at the same value expressed in these different numbering systems.

• Decimal (Human Use): 100
• Binary (Computer Use): 1100100
• Octal (Early Shortcut): 144
• Hexadecimal (Later Shortcut): 64

Doing this conversion by hand was tedious, time-consuming, and error-prone. Programmers relied on stacks of formula tables and needed to keep track of which numbering system they were using. Maintaining these mental models led to real-world problems. Grace Hopper, who would go on to invent tools and programming languages that enabled the computer to do these cumbersome conversions, recalled the challenges she faced.

“…I taught myself to add, subtract, and multiply, and even divide in octal. I was really good, until the end of the month, and then my checkbook didn't balance! It stayed out of balance for three months until I got hold of my brother who's a banker. After several evenings of work he informed me that at intervals I had subtracted in octal. And I faced the major problem of living in two different worlds. That may have been one of the things that sent me to get rid of octal as far as possible.” -Grace Hopper

Source: History of Computing Languages Conference keynote (1978)

Hopper, inspired by the work of her peers John Mauchly and Betty Holberton, become focused on ways that “you could make a computer write a program.” One of her most impactful contributions was the compiler, a tool that acts as a translator and shifts the burdensome mathematical conversions from humans to the computer.

“…programming has been reduced to a matter of hours rather than weeks…Stated bluntly, the compiling routine is the programmer and performs all those services necessary to the production of a finished program.” - Grace Hopper

Source: "The Education of the Computer" (1952)

Empathy drove Hopper’s quest to make programming easier, not just for mathematicians, but for “plain, ordinary people who had problems to solve.” She imagined a world where a human could enter a command using a verb they were familiar with, such as PRINT, and the computer would execute the command based on plain-English instruction.

By 1954, Hopper had made this vision a reality with the first human-language program, FLOW-MATIC. Instead of humans having to learn the language of the machine, machines could execute programs that were written in human language. In 1968, the COBOL standard was adopted, and the original verbs used to program FLOW-MATIC lived on in COBOL compilers. By the early 1970s, compiled languages had become widely adopted, particularly for developing business programs, and they remain the dominant form of programming languages to this day.

Making the Compiler Happy

Compilers are indeed useful tools. However, computers still need instructions to be incredibly precise. The smallest typo, such as a missing semicolon or a misspelled word, can cause huge headaches because your program won’t work. When it’s difficult to diagnose and fix problems, it’s easy to get frustrated.

To illustrate how this frustration emerges, let’s imagine you’re attending a school where all of the professors are incredibly finicky. The grading system is structured as pass/fail, and no errors are tolerated. The slightest misspelling or misplaced comma means you’ll get a failing grade. No exceptions. However, you do have the opportunity to correct errors and resubmit as often as you’d like until you get a passing grade.

As you write your papers, you work hard to double and triple-check for any errors. You turn your paper in, feeling confident that you’ll get a passing grade. Instead, you get a big fat zero with a note from the professor.

Error: Unexpected Element        

You look at that vague feedback and try to interpret your professor’s comments as best you can. You make a change, try again, and fail again. And again. And again. And again. And again. Soon, you are so frustrated that you just want to throw your computer against the wall.

This immense frustration is similar to how it can feel when code fails to compile properly. You just want the darn thing to work, so you begin to develop a mental model centered around “making the compiler happy.” You start to imagine the interaction between your code and the compiler, which is useful because it helps you think through potential problems.

Now, let’s now imagine that the school focuses on making its feedback easier to understand. This time, when you submit your paper, it still fails, but you get a different note from your professor.

Error: Extra Comma
"The software developer was kind, and often thought of other people." 

Commas come before conjunctions when they connect independent clauses. 
Try removing the comma or adding a noun in the second clause.        

Because the feedback from the professor contains more context, it’s easier for you to diagnose the problem. You make the change, resubmit the paper, and feel fantastic when your paper passes. Getting your code to compile can be a serious cause for celebration, especially when you've been banging your head against the problem for a while.?

This “make the compiler happy” mindset has its trappings and downfalls. First, it can become easy to forget that the compiler isn’t what you’re coding for. You’re coding for people. When the mental load of diagnosing errors is too high, it can be easy to forget the people who will interact with and who be impacted by what you create.

Another problem is that when you eventually do figure it out, there’s a huge rush of satisfaction. You feel as if you’ve conquered something insurmountable. It can be tempting to chase this feeling by rationalizing that coding must be a difficult activity. When error messages become helpful, and you don’t get that rush, it can somehow feel disappointing. We may even rationalize that when code is easy to understand and modify, it’s somehow cheating.

Enhanced Error Messages

Today, there is an emerging interest in making compiler error messages more useful. According to a 2017 eye-tracking study led by Travis Barik, developers who participated in the study spent on average between 13%-25% of their time fixated on error messages. “Participants read error messages;” Barik writes, “unfortunately, the difficulty of reading error messages is comparable to reading source code —?a cognitively demanding task.”

When an error message is difficult to understand, developers tend to refer to it over and over again, running the code multiple times until they resolve the error. This has a significant impact on developer experience, morale, and productivity. Given the importance of compiler error messages, there has been a growing interest in recent years in how error messages can be enhanced.

In 2019, a team of researchers led by Brett Becker collected and reviewed an error message corpus consisting of nearly two hundred pieces of literature spanning over fifty years. The advice regarding what makes an error message useful was categorized into ten categories:

1. Increase Readability
2. Reduce Cognitive Load
3. Provide Context
4. Use a Positive Tone
5. Show Examples
6. Show Solutions or Hints
7. Allow Dynamic Interactions
8. Provide Scaffolding
9. Use Logical Argumentation
10. Report Errors at the Right Time

Enhanced error messages are particularly useful to novices. In 2020, a study led by Paul Denny found students learning C were able to solve problems faster with less frustration when error messages were re-written for clarity.

Standard Compiler Error

13:5: error: 
expected declaration specifiers before ‘scanf’        

Participant comment: "I was borderline about to throw my laptop through the window! But then I saw the ‘{’ missing which was nowhere near where the error message had me looking."

Enhanced Compiler Error

An opening brace appears to be missing. 
Functions should have a matching opening and closing brace.        

Participant comment: "Not gonna lie, it’s a bit confusing since it’s our first day doing C programming. However it was simple and easy to learn after the error messages popped up."

Some programming languages, such as Elm, have made enhanced error messages core to their design. Error messages in Elm are written in the first person and contain an extraordinary amount of context compared to error messages in other languages.

It should be noted that not everyone values enhanced error messages. As developers become more experienced in spotting patterns, enhanced error messages can begin to lose their luster. One participant who received enhanced messages in Denny’s study made the comment “idk if the errors messages were what you would expect to find in c or just there for learning, but if they are there for learning perhaps make them more vague as it was a bit too easy.”

Other developers have written about a personal attitudinal shift towards Elm’s error messages, such as a developer from Ontario who observed, “Where once I smiled in joy as the compiler helpfully explained exactly what I had done wrong, now I found myself rolling my eyes at it.” Their idea? Provide the option for developers to choose between short and long error messages. Developing useful error messages will always be a work in progress.

Code for People through a Computer

Empathy enables us to think beyond making the compiler happy. It allows us to connect with the people who will read the code that we write, interact with the interfaces we design for, and feel the impact our software makes on their lives. While it may be tempting to treat compiler error messages as toss-away artifacts that no one will read, a deeper look helps us see the human side of these often-overlooked pieces of code.

The next time you find yourself dismissing your work as trivial or perhaps find yourself muttering a sarcastic statement like “Who’s going to read this, anyway?” take a pause. Reframe the question. Ask yourself in a more contemplative tone, “Who is going to read this?” Take a moment to connect with an individual, perhaps even your future self, and consider how you might reduce their frustration.

Empathy opportunities are all around us as we code. Empathy doesn’t only happen when we’re face-to-face with someone. When we use empathy as a way to drive our development choices, we unlock a whole world of human connection and begin to make decisions that honor the impact our work has on others.