Since trading computer programming for a human audience, I’ve started to notice there is a similarity in recognizing that there are broad types of mistakes in either case. In programming the worst ones are the type of mistakes that the more senior programmers know to spend the most time carefully driving out. Whether you write for humans or computers, you’re going to have typos. In programming we call these “syntax errors”, but it’s the same thing. These are not where the true difficulty lies in either vocation. The difficult work comes from problems that are subtle.
Java has caused more developers to go bald with the “ignore the error” mistake than any other caste of bugs. This is the Brahman error. The story goes like this: whenever you write any code in Java, you MUST write code to handle any hypothetical errors. You’re writing a program, trying to get it to do something. You didn’t set out to write a bunch of error handling; that’s not your goal. So it’s a distraction that Java wants you to deal with this, and you just want to cop out. The cop-out for this issue is to handle the error in a way that accomplishes nothing – like saying “there was an error”, and congratulations, your program works!
Even senior programmers often don’t realize they can punt on this. This is the right thing to do in most cases; throw the error so that it gets seen by a higher level of the program, instead of writing a whole bunch of disused error code that gets in the way of what you’re trying to accomplish.
In writing for humans, I think this error has a cousin. I file these under the “reader isn’t in your brain” class of errors. You’re not sure if your reader knows something. Your readers may not all have the same vocabulary, or may not realize that you’re referring to a certain character. In some cases, you may have characters who are referred to with a first and last name, their job or rank, a set of pronouns, a nickname, or a phrase like “that guy”.
In the worst case, many of the people reading wouldn’t have a problem, but in your head you might imagine a reader saying “I had a problem understanding that!” before you even wrote it. Now you’re handling an error, but should you? Usually you don’t want to add a complicated explanation, instead you should reframe things so they are easier to get through, or you could make a difficult concept a central piece of a more interesting plot.
As a result of this error, many times I find myself writing too much, resulting in a dense and wordy prose getting in the way of what I’m trying to write. People don’t read the whole thing, and your humans won’t tell you why. They probably can’t even articulate that, especially if there are no “syntax errors” that stand out to them. They are as mute as a Java program swallowing an error.
Figuring out how much “error handling” writing to leave in is very tricky. “Try to understand, my character’s name is James T Kirk, if you don’t know who that is, Catch up by learning that he’s the captain of a 5 year mission undertaken by the Starship Enterprise. Now we’ll get to what a Starship is…” There’s a word for this in writing, it’s called “exposition” and if you can get it just right...
Science fiction often has clever ways of performing exposition without you realizing it, with novice characters asking questions, or Captain’s Log entries in star-trek. Particularly stoic characters are often there to robotically state the obvious, like Spock or Data. The “Doc” in Back to the Future performs important exposition under the guise of producing a videotape to record his scientific breakthrough.
Exposition is like giving a little kid a shot. They don’t want it. Sometimes they need it, and it’s best if they don’t even notice they got it. To torture this metaphor a bit, you don’t need to constantly stick needles in kids. We don’t go around inoculating for smallpox or rabies or yellow fever if we can possibly help it. Similarly if you go around sticking expository information everywhere, you’ll start to read like a engineering tome instead of an enjoyable novel.
The problem is that too many wordy facts just feels like studying instead of reading. This is probably one of my biggest challenges, I’ve got to repeat my mantra “not like a textbook”.
Additional classes of errors are listed below for your enjoyment, and I am aware of the irony that this post is fairly dense and textbookish – it’s about writing, it’s not a piece of fiction, the audience is people interested in this topic. In some ways the choice of this entanglement is a personal puzzle for me, it’s meta.
- “I want to change a word or phrase”. Distracted by my own writing higher up, I change the word, and later see that this has screwed up something downstream, possibly nowhere near this word. This happens constantly in writing and in programming.
- “Something is left unfinished because of interruptions” Sometimes the phone will ring, you’ll need to research something, or you will lose focus. When you return, if it looks ok, you might not realize that you were intending to add something.
- “Suspension of disbelief” these could be related to “off-by-one” errors in programming, but I’ve had more trouble finding them when soliciting feedback of my writing. Getting early readers to hone in on what it is that makes something unbelievable – like a revolver that has one too many bullets, you can lose readers without realizing why. If there was one shot too many before Dirty Harry is out of bullets, it can cause someone to throw up their hands.
- “I changed my mind without realizing it” errors, involve “attributes”, or details that are usually about a character. Sometimes you just want a building to be tall so there’s an elevator to ride on, and you don’t remember you described it as “squat” previously. This is really common in programming too, the attributes attached to data are the key to whether any given piece of computer program is “compatible” with any other. Maybe this is many times worse in programming, because more than one person is often dealing with these details. You wouldn’t believe how much money the government spends on this kind of thing.
A particularly insidious “class” of programming errors is the subject of one of my favorite books, “The Bug” by Ellen Ullman. She writes of how a programmer is slowly driven mad by a particular type of error that is difficult to pin down. The same thing could happen in writing, and the trick is you’ve got to find ways of opening yourself up to the kind of feedback that will let you find these kinds of errors, just as programmers are looking for ways to see the bugs in their code.
I’ve been thinking of strategies that might help to minimize some of these errors in my writing, because that’s sort of how programmers think – “how can I drive out an entire class of errors?”. Has anyone found anything that works well, like using a typewriter? At least with a typewriter I would be forced to retype everything into a computer, couldn’t go back and muck things up without maintaining flow, but there are lots of drawbacks to a typewriter, clearly. Which one would I even get?