The writer’s life and Donald Knuth’s Selected Papers on Computer Science

Doing almost anything right is hard. Few of us appreciate how hard, and how much we have to specialize if we’re to accomplish anything significant.

Still, it’s useful to fertilize ourselves by looking at distant fields. I’m fascinated by other people’s professions and what non-specialists can take from them; I’ve never wanted to be a politician, but Chris Matthews’ Hardball offers surprisingly deep life insights. Non-soldiers love The Art of War, and Anthony Bourdain demonstrates how much we want to know about what goes on in the kitchen—and not just sexually. Being who I am, I tend to look for lessons about writing (and material to write about) in other people’s work, and Donald Knuth’s Selected Papers on Computer Science is the latest to catch my eye, especially when he discusses just how hard writing programs really is:

Software creation not only takes time, it’s also much more difficult than I thought it would be. Why is this so? I think the main reason is that a longer attention span is needed when working on a large computer program than when doing other intellectual tasks. A great deal of technical information must be kept in one’s head, all at once, in high-speed random-access memory somewhere in the brain. I found to my dismay that I could not be writing large programs while teaching my regular classes; I simply couldn’t do justice to both activities simultaneously, nor could I be happy if the programs were left unwritten. So I reluctantly took occasional leaves of absence from university teaching. In this sense I believe that program-writing is substantially more demanding than book-writing.

Another reason that programming is harder than the writing of books and research papers is that programming demands a significantly higher standard of accuracy. Programs don’t simply have to make sense to a another human being, they must make sense to a computer.

Writing a novel isn’t quite as hard as writing a complex software system, but it’s close. It’s useful to keep story information in “high-speed random-access memory,” and I’m usually thinking subconsciously about whatever primary novel I’m working on regardless of what else is going on around me.

The only major exception is when I’m deeply into writing a proposal, which requires similar bandwidth. Program-writing might be substantially more demanding than book writing, but book writing is still shockingly demanding, especially if one is to pay attention to its details. That, in essence, is what it means to be an expert on something: to be aware of its details. I’ll return to my first sentence and reiterate it by saying that I don’t think most of us realize the sheer number of details involved in virtually every thing or activity around us. We don’t see the moss on the bark of the trees; we see the forest from 30,000 feet.

Knuth sees at a lot of scales, and he’s also good at telling people to work with each other, regardless of boundaries. He says, for example, that “Scientists always find it easiest to write for colleagues who share their own subspecialty. But George Forsythe told me in 1970 that I should be prepared to explain things to a wider group of people [. . .]” This is true of literary theorists too. But we should write for those who we might not know well, or who might not know us well, and I think the inverse of Knuth’s advice is true: people who mostly write popular works would probably be better off writing for a specialist audience at times, in order to deepen knowledge of their own field. Know everything about something and something about everything, to paraphrase a quote that Google attributes to a wide array of people. Knuth, one senses, does: “When I try to characterize my own life’s work, I think of it primarily as an attempt to balance theoretical studies with practical achievements.”

The idea of theory and practice balancing each other comes up over and over again. It resonated with me because I’ve long hated the false binary between the two. He notes that some fields are more like each other than some of us imagine too:

The best programs are written so that computing machines can perform them quickly and so that human beings can understand them clearly. A programmer is ideally an essayist who works with traditional aesthetic and literary forms as well as mathematical concepts, to communicate the way that an algorithm works and to convince a reader that the results will be correct. Programs often need to be modified, because requirements and equipment change. Programs often need to be combined with other programs. Success at these endeavors is directly linked to the effectiveness of a programmer’s expository skill.

Numerous analogies can be drawn between hacking, in the sense Paul Graham uses the term, and writing. My awareness of the likeness probably stems from my deeper-than-average knowledge of writing and my very shallow knowledge of programming, along with the sense that metaphors for writing abound. Plus, very few people compare programmers and essayists, as Knuth does here, and yet his reasons are surprisingly convincing. The key word is “surprisingly:” the two fields that don’t seem incredibly similar somehow are. That’s what good writers do. Maybe it’s what good programmers do too.

In Founders at Work Philip Greenspun said:

People don’t like to write. It’s hard. The people who were really good software engineers were usually great writers; they had tremendous ability to organize their thoughts and communicate. The people who were sort of average-quality programmers and had trouble thinking about the larger picture were the ones who couldn’t write.

People don’t like to write, and they don’t like to hack much, either. I like to write, and while I’m often interested in computer science and computer-related topics, I never had the weird, driving need I felt towards writing. To quote Graham again”: “I know a handful of super-hackers, so I sat down and thought about what they have in common. Their defining quality is probably that they really love to program.” That’s a defining quality of writers too. It feels more like writing chose me than I chose writing, even though I would posit that, logically, computer scientists and engineers have had the greatest impact on average daily life of any group over the last, say, 30 years. But both writing and programming are hard; unambiguous communication is hard (as is communication that’s artistically ambiguous).

Elsewhere Knuth notes that “Anyone who has prepared a computer program will appreciate the fact that an algorithm must be very precisely defined, with an attention to detail that is unusual in comparison with the other things people do.” Detail applies to writing as well: one not bad definition for a writer might be, “a person who attends to the details of their writing.”

Do you?

The writer's life and Donald Knuth's Selected Papers on Computer Science

Doing almost anything right is hard. Few of us appreciate how hard, and how much we have to specialize if we’re to accomplish anything significant.

Still, it’s useful to fertilize ourselves by looking at distant fields. I’m fascinated by other people’s professions and what non-specialists can take from them; I’ve never wanted to be a politician, but Chris Matthews’ Hardball offers surprisingly deep life insights. Non-soldiers love The Art of War, and Anthony Bourdain demonstrates how much we want to know about what goes on in the kitchen—and not just sexually. Being who I am, I tend to look for lessons about writing (and material to write about) in other people’s work, and Donald Knuth’s Selected Papers on Computer Science is the latest to catch my eye, especially when he discusses just how hard writing programs really is:

Software creation not only takes time, it’s also much more difficult than I thought it would be. Why is this so? I think the main reason is that a longer attention span is needed when working on a large computer program than when doing other intellectual tasks. A great deal of technical information must be kept in one’s head, all at once, in high-speed random-access memory somewhere in the brain. I found to my dismay that I could not be writing large programs while teaching my regular classes; I simply couldn’t do justice to both activities simultaneously, nor could I be happy if the programs were left unwritten. So I reluctantly took occasional leaves of absence from university teaching. In this sense I believe that program-writing is substantially more demanding than book-writing.

Another reason that programming is harder than the writing of books and research papers is that programming demands a significantly higher standard of accuracy. Programs don’t simply have to make sense to a another human being, they must make sense to a computer.

Writing a novel isn’t quite as hard as writing a complex software system, but it’s close. It’s useful to keep story information in “high-speed random-access memory,” and I’m usually thinking subconsciously about whatever primary novel I’m working on regardless of what else is going on around me.

The only major exception is when I’m deeply into writing a proposal, which requires similar bandwidth. Program-writing might be substantially more demanding than book writing, but book writing is still shockingly demanding, especially if one is to pay attention to its details. That, in essence, is what it means to be an expert on something: to be aware of its details. I’ll return to my first sentence and reiterate it by saying that I don’t think most of us realize the sheer number of details involved in virtually every thing or activity around us. We don’t see the moss on the bark of the trees; we see the forest from 30,000 feet.

Knuth sees at a lot of scales, and he’s also good at telling people to work with each other, regardless of boundaries. He says, for example, that “Scientists always find it easiest to write for colleagues who share their own subspecialty. But George Forsythe told me in 1970 that I should be prepared to explain things to a wider group of people [. . .]” This is true of literary theorists too. But we should write for those who we might not know well, or who might not know us well, and I think the inverse of Knuth’s advice is true: people who mostly write popular works would probably be better off writing for a specialist audience at times, in order to deepen knowledge of their own field. Know everything about something and something about everything, to paraphrase a quote that Google attributes to a wide array of people. Knuth, one senses, does: “When I try to characterize my own life’s work, I think of it primarily as an attempt to balance theoretical studies with practical achievements.”

The idea of theory and practice balancing each other comes up over and over again. It resonated with me because I’ve long hated the false binary between the two. He notes that some fields are more like each other than some of us imagine too:

The best programs are written so that computing machines can perform them quickly and so that human beings can understand them clearly. A programmer is ideally an essayist who works with traditional aesthetic and literary forms as well as mathematical concepts, to communicate the way that an algorithm works and to convince a reader that the results will be correct. Programs often need to be modified, because requirements and equipment change. Programs often need to be combined with other programs. Success at these endeavors is directly linked to the effectiveness of a programmer’s expository skill.

Numerous analogies can be drawn between hacking, in the sense Paul Graham uses the term, and writing. My awareness of the likeness probably stems from my deeper-than-average knowledge of writing and my very shallow knowledge of programming, along with the sense that metaphors for writing abound. Plus, very few people compare programmers and essayists, as Knuth does here, and yet his reasons are surprisingly convincing. The key word is “surprisingly:” the two fields that don’t seem incredibly similar somehow are. That’s what good writers do. Maybe it’s what good programmers do too.

In Founders at Work Philip Greenspun said:

People don’t like to write. It’s hard. The people who were really good software engineers were usually great writers; they had tremendous ability to organize their thoughts and communicate. The people who were sort of average-quality programmers and had trouble thinking about the larger picture were the ones who couldn’t write.

People don’t like to write, and they don’t like to hack much, either. I like to write, and while I’m often interested in computer science and computer-related topics, I never had the weird, driving need I felt towards writing. To quote Graham again”: “I know a handful of super-hackers, so I sat down and thought about what they have in common. Their defining quality is probably that they really love to program.” That’s a defining quality of writers too. It feels more like writing chose me than I chose writing, even though I would posit that, logically, computer scientists and engineers have had the greatest impact on average daily life of any group over the last, say, 30 years. But both writing and programming are hard; unambiguous communication is hard (as is communication that’s artistically ambiguous).

Elsewhere Knuth notes that “Anyone who has prepared a computer program will appreciate the fact that an algorithm must be very precisely defined, with an attention to detail that is unusual in comparison with the other things people do.” Detail applies to writing as well: one not bad definition for a writer might be, “a person who attends to the details of their writing.”

Do you?

Coders at Work: Reflections on the Craft of Programming – Peter Seibel

Coders at Work is consciously modeled on the Paris Review Interviews with famous writers and comes out better for it. The interviews are deep, thoughtful, wide-ranging, and show strong opinions without pedantry or needless prejudice. Many such opinions aren’t unique to programming or can be transferred easily to a wider domain area; Dan Ingalls, for example, says that “[M]y feeling about the powerful ideas that are necessary to lead a good life, it’s not clear how many of them are in this space,” this space being the intersection of computers and math. The expression is a bit awkward, which shouldn’t be surprising given that these interviews were conducted in person, but the idea of tremendous respect for powerful ideas is an attractive one that’s expressed over and over in these essays.

Coders at Work is surprisingly fun and useful, even for people whose connection to computer science is tenuous, chiefly because its metaphors and ideas about work and beauty travel. The author’s bio says, “An English major and would-be journalist in college, Peter was seduced by the web […]” and eventually became a hacker. Perhaps not surprisingly, then, I see a lot of ideas that one can apply to writing in this book. Joe Armstrong says that writing is an essential skill for programmers, and he says that writing is “actually very difficult to teach because it’s very individual.” Since I teach writing, that resonates with me, but it seems that coding is equally difficult if not quite equally individual, but the difficulty in learning both seems like a similar problem space. I write this from the position of someone with about a dilettante’s Computer Science 102 view of these things, but I see nothing in Coders at Work that’s incompatible with such a view. Both hacking and writing seem like what I call “10,000-hour problems,” or those that will require that much time to master. Ingalls implicitly agrees:

[…] I still love to just take a problem and sit down and pore over it until it’s right. There’s an analogy here: I tried to learn to play the piano fairly late in life. People said, “Oh, you should learn when you’re young. You learn so much quicker.” Although I didn’t go very far, my conclusion was that it isn’t that young people learn that much faster; it’s just they have more time. When I would put time in, I made progress.

I feel a bit the same thing with programming. When I look back on earlier times in my life, I had all the time I wanted. I would just work and work. Now there are other things going on in my life and I’ve got responsibilities that aren’t just programming. That undermines a bit of that intense focus.

Replace “programming” with “writing,” and I think the ideas about the process of learning stand. Ideas about beauty seem to transfer as well. L. Peter Deutsch says, “[… I]t’s just seeing anything around me that’s being done badly has always offended me mightily, so I thought I could do better.” Perhaps not surprisingly, Deutsch also says:

As crazy as it may seem now, a lot of my motivation for going into software in the first place was that I thought you could actually make the world a better place by doing it. I don’t believe that anymore. Not really. Not in the same way.

Maybe not: but I suspect that we make the world a better place by becoming really, really good at something—so good that no one else can do it as well as us, or some small coterie of skills that interact with one another—and then ultimately teach others that skill or suite of skills too.

The dominant idea in Coders at Work is not how to apply the skills once you have them, but the challenge and process of acquiring those skills. The coders interviewed acquire and apply them in diverse ways, but the dominant theme in all of them is starting early and intense, dedicated work. There is no other way to learn and to develop “Taste for Makers.”

One question is why more people don’t find and excel in coding, or in any particular, demanding field. Donald Knuth speculates that only about 2% of the population has the aptitude and desire for coding. Maybe. And maybe some segments of the population are turned off by the culture or cultures of coding. In a blog post, Seibel wonders whether there are “Enough women in Coders at Work?” The obvious answer from a gender parity perspective is “no,” but from a practical prospective I’d observe that a) there has been an overly low proportion of women in computer science for as long as one can remember and b) many of the interviewees came of age in the 60s and 70s, when the problem was even worse than it was now because of other institutional and cultural barriers.

Fran Allen takes up some of these issues. But Seibel is also a writer, and not directly responsible for the number of prominent, expert women coders; the fact that the issue arises is a sign of progress. Still, it is not effective to order people to learn to code or to like to code any more than it is effective to order people to become writers; the best you can do is give them an environment conducive to growth and remove institutional barriers and see what happens. Maybe some of them will learn taste and, better still, beauty.

(You can—and should—also read Joel Spolsky’s take on Coders at Work. His point: sometimes you need people who get things done.)

%d bloggers like this: