Programmer Musings

Programming and Writing

Over the years, I have come to the amusing realization that many people feel like they could program if they just tried. You know the type. He (or she) has used computers for a while. He picked up Computer Programming for Total Morons or Object Oriented Programming in C++ and Java in an Hour and a Half and now expects to be able to write code like a pro. Those of us who have been programming for a while, brace ourselves for the inevitable opinions and declarations about building large systems based on experience with single-page programs.

I have also realized that there is another field that is very familiar with this problem, writing. Similar to the way that many people seem to think that they can program just because they can enter code in an editor, many people also seem to think they can write just because they can put words on a page. Ask anyone who really writes for a living and they can tell you how little the ability to write words on a page has to do with actually writing. Despite this disparity, anecdotal evidence suggests that many people still expect to write a great novel someday. (Although, I suspect that percentage is smaller than it was a few decades ago.)

A couple of years ago, I compared writing and programming in The Recurring Myth of Programmer-less Programming. I made a very superficial connection between these two disciplines in order to make a very different point. Since then, this connection has been simmering in the back of my head and I have come to realize that they have more in common than I originally thought.

One thing these two disciplines have in common is communication. Now, I realize this is not a particularly earth-shattering revelation, but bear with me a bit. It often comes as a surprise to most people that communication is hard. If you are just talking with your friends, family, and co-workers, you probably manage to be understood most of the time. When misunderstandings do arise, most people seem to assume that someone wasn't paying attention or something.

The first time you try to communicate with someone from a different culture, you begin to see how hard communication can be. Even if you can speak a common language, misunderstandings abound. If you are communicating through a low-bandwidth channel like email, communication becomes even harder. Most people seem to assume that these kinds of communication problems are the other guy's fault. Really communicating doesn't allow for that particular cop-out. Cicero is supposed to have said

The aim of writing is not simply to be understood, but to make it impossible to be misunderstood.

This is much harder than most people realize. When you are speaking, you can watch your audience and clear up misunderstandings as they arise (at least in theory). When you are writing, you don't really know who your audience is. There is no feedback, so misunderstandings linger.

In programming, this is equally hard because your writing has two very different audiences: the computer and other programmers. The difficulty comes from the fact that the computer needs everything described in mind-numbing detail. It cannot make the leap from one concept to another. On the other hand, people (even programmers) are not very good at reading information at that level of detail. This difficulty of working at two very different levels at once is one of the things that separates an actual programmer from a coder who dumps code into an IDE or editor.

Thinking and communicating at these two very different levels is extremely difficult. Over the years, we have developed better programming languages to reduce the amount of detail we need to explicitly write for the computer. Unfortunately, this has not made the complexity go away. Instead, the programmer has to be aware of the details of each statement and the context in which it is made. While this is somewhat easier for humans than the alternative, it does not mean that the details have gone away. It just means that you don't have to think about all of them constantly.

A good programmer has to be able to think at multiple levels of detail at the same time. These levels include:

• user-level details of the solution, such as the desire to select items by name
• high-level details of the program, such as the need to find items quickly by name
• medium-level details that the program needs, such as data structures and algorithms appropriate to the job at hand
• low-level details that the machine requires, such as limits on data types, memory, and speed of the processor.

Not all of these details matter all of the time. But a good programmer has to be aware of them and know when particular details can be ignored. The programmer also has to be aware of the constraints and requirements of the problem he (or she) is trying to solve.

A good programmer is aware of multiple solutions to many different problems and is capable of making various trade-offs in choosing between them. Whereas a coder has probably found a solution that has worked in the past and tries to apply it to every problem.

Fortunately, some coders eventually gain enough experience to become actual programmers. Unfortunately, the percentage of coders that become programmers is probably close to the percentage of people that actually do write their great novel. Unfortunately, unlike potential writers, these coders are actually producing code that someone will need to maintain and repair.

Now, sooner or later someone is going to point out that here I am writing, when I have no business claiming to be a writer. Actually, I don't claim to be a writer. I think my best credentials for writing are that I know I'm pretty bad at it. For that reason, I work pretty hard at each article I write, trying very hard to get my point across without leaving too much probability of being misunderstood. As such, this article has been one of the hardest for me to write.