Seven Tips From Ernest Hemingway on How to Write Code

With apologies to Mike Springer.
Image

Before he was a big game hunter, before he was a deep-sea fisherman, Ernest Hemingway was a craftsman who would rise very early in the morning and write code. His best applications are masterpieces of the modern era, and his prose coding style is one of the most influential of the 20th century.

Hemingway never wrote a treatise on the art of writing code. He did, however, leave behind a great many comments in scripts, web sites and applications with opinions and advice on programming. Some of the best of those were assembled in 1984 by Larry W. Phillips into a book, Ernest Hemingway on Writing Code. We’ve selected seven of our favorite quotations from the book and placed them, along with our own commentary, on this page. We hope you will all–programmers and users alike–find them fascinating.

1: To get started, write one true test.

Hemingway had a simple trick for overcoming programmer’s block. In a memorable comment in AMoveableFeast_spec.rb, he writes:

# Sometimes when I was starting a new program and I could not get it going,
# I would sit in front of the fire and squeeze the peel of the little oranges into the edge of the flame and
# watch the sputter of blue that they made.
# I would stand and look out over the roofs of Paris and think, “Do not worry. You have always written code
# before and you will write code now.
# All you have to do is write one true test. Write the truest test that you know.” So finally I would write 
# one true test, and then go on from there.
# It was easy then because there was always one true test that I knew or had seen or had heard someone say.
# If I started to write elaborately, or like someone introducing or presenting something, I found that I could
# cut that scrollwork or ornament out and throw it away and start with the first true simple declarative method
# I had written and test it.

2: Always stop for the day while you still know what will happen next.

There is a difference between stopping and foundering. To make steady progress, having a daily line-count quota was far less important to Hemingway than making sure he never emptied the well of his imagination. In an October 1935 web page in Esquire.com ( “Monologue-to-the-Maestro-High-Seas-Letter.html.erb”) Hemingway offers this advice to a young programmer:

<!--
The best way is always to stop when you are going good and when you know what will happen next.
If you do that every day when you are writing an application you will never be stuck.
That is the most valuable thing I can tell you so try to remember it.
-->

3: Never think about the program when you’re not working.

Building on his previous advice, Hemingway says never to think about a program you are working on before you begin again the next day. “That way your subconscious will work on it all the time,” he writes in the Esquire page. “But if you think about it consciously or worry about it you will kill it and your brain will be tired before you start.” He goes into more detail in AMoveableFeast.rb:

# When I was programming, it was necessary for me to read after I had written code.
# If you kept thinking about it, you would lose the thing you were programming before
# you could go on with it the next day.
# It was necessary to get exercise, to be tired in the body, and it was very good to make love with whom you loved.
# That was better than anything. But afterwards, when you were empty, it was necessary to read in order not to think
# or worry about your work until you could do it again.
# I had learned already never to empty the well of my programming, but always to stop when there was still something
# there in the deep part of the well, and let it refill at night from the springs that fed it.

4: When it’s time to work again, always start by reading what you’ve written so far.

To maintain continuity, Hemingway made a habit of reading over code he had already written before going further. In the 1935 Esquire.com web page, he writes:

<!--
The best way is to read it all every day from the start, correcting as you go along,
then go on from where you stopped the day before. 
When it gets so long that you can’t do this every day read back two or three classes each day; 
then each week read it all from the root directory. That’s how you make it all of one piece.
-->

5: Don’t describe an output–make it.

Close observation of code execution is critical to good programming, said Hemingway. The key is to not only watch and listen closely to external events, but to also notice any side effect stirred in your code by the events and then trace back and identify precisely what it was that caused the side effect. If you can identify the concrete action or situation that caused the side effect and prevent it accurately and fully protected in your program, your users should never feel the side effect. In DeathInTheAfternoon.c, Hemingway writes about his early struggle to master this:

/*
I was trying to write then and I found the greatest difficulty, 
aside from knowing truly what you really wanted to implement, 
rather than what you were supposed to implement, 
and had been taught to implement, 
was to put down what really should happen in action; 
what the actual things were which produced the output that you expected. 
In writing for C you told what happened and, with one trick and another, 
you communicated the output aided by the element of timeliness which gives 
a certain output to any account of something that has happened on that execution; but the real thing, 
the sequence of motion and fact which made the output and which would be as valid in a year or in ten years or, 
with luck and if you stated it purely enough, always, was beyond me and I was working very hard to get it.
*/

6: Use a pencil.

Hemingway often used a text editor when composing scripts or simple web pages, but for serious applications he preferred a pencil. In the Esquire.com web page (which shows signs of having been written on a text editor) Hemingway says:

<!--
When you start to write code you get all the kick and the user gets none. 
So you might as well use a text editor because it is that much easier and you enjoy it that much more. 
After you learn to write code your whole object is to convey everything, 
every sensation, sight, feeling, place and emotion to the user. 
To do this you have to work over what you write. 
If you write with a pencil you get three different sights at it to see if the user is getting what you want him to. 
First when you read it over; then when it is typed you get another chance to improve it, and again in staging. 
Writing it first in pencil gives you one-third more chance to improve it. 
That is .333 which is a damned good average for a hitter. 
It also keeps it fluid longer so you can better it easier.
-->

7: Be Brief.

Hemingway was contemptuous of programmers who, as he put it, “never learned how to say no to a text editor.” In a 1945 e-mail to his project manager, Maxwell Perkins, Hemingway writes:

It wasn’t by accident that NASA’s Apollo guidance system was 8 kilobytes. The laws of prose programming are as immutable as those of flight, of mathematics, of physics.

Advertisements
Tagged with: , ,
Posted in programming

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: