Now that we have actually good AI, I have this vision of a form of computing that doesn’t involve me using a computer so much. Imagine you had the day’s emails to go through. It would be nice if the ones that required a simple decision could be dispatched with a few pen-strokes: I could write down a date that would work for that meeting; check a box to accept that invitation; etc. If an email required me to review a draft, I'd love to mark up a print version on my couch, sans screen, and have those notes scanned and sent off as if I'd done the whole thing on Google Docs.
The point is not to give up on virtuality, but just to save the end user from having to interact with it. It's great to be able to send information to anyone in the world instantly; but let me do it without the glaring screen and the thousand distractions. Is such a thing even possible? I'm not sure, but I just now uploaded a first draft of this post, handwritten in a small notebook, into ChatGPT. Its transcription was nearly perfect.
A first draft of this blog post
Here's another example: when I really want to play with re-arrangements of a complicated outline, or when I want to collaborate with someone else on one, I find myself laying physical note cards on a table. Having real objects to work with allows for more flexibility than software. If the problem demands it, you can stack cards, draw on them, cut them, tape things to them, etc.—and none of these improvised ways of organizing has to be coded up in advance.
Space turns out to be a good way to organize information. I gather that in the paper days if you had a big project you were working on, say a book, it would spill out into the room you were working in: chapter outlines pinned up on the walls, stacks of books in meaningful piles on the floors, folders with drafts and clippings. Certain sections of the work in progress would become associated in your mind with certain parts of the room. Chapter 3 would be over there.
I rarely use paper or physical space this way because it lacks critical conveniences. A huge wall-mounted paper calendar is maybe the best way to plan and visualize a large coordinated effort. (In "making-of" documentaries you find that movie shoots are often planned this way.) Everyone can see it and point to it because it's at human-scale; you can express many dimensions of information simultaneously using shape, color, position, size, and any other physical attribute. But I have a hard time understanding how I'd keep such a calendar up to date. In practice, like almost everyone else, I use a virtual calendar that automatically adds events as I'm invited to them, syncs with other people's calendars, reconciles time zones effortlessly, and interoperates with other programs like email.
Could we get the best of both worlds? In other words, shouldn't one goal of rapid technical advancement be some melding of the physical and virtual worlds such that I can sit quietly in an easy chair with pen and pad; or lay cards out on a table to organize my thoughts; or turn a room into the embodiment of a project; and yet have the same flexibility, portability, persistence, and remixability as in the digital versions of these things?
I spend a lot of my day on screens. There are many problems with these things, articulated well by Bret Victor in the context of his Dynamicland project. Screens are small, antisocial, and they have a tiny vocabulary of affordances compared to physical objects. Plus they have the problem that they make it difficult to just use your calendar, todo list, or map—or even just respond to a friend's message—without encountering something else along the way, like a social network, short-form video, Slack, the news, or some other notification. To state the obvious: your phone is the best place to keep your calendar and inbox and todo list because you always have it with you, but of course that makes it ripe for other intruders. Bundling makes your phone indispensable, but also a menace.
If nothing else I'd like it if operating systems and web browsers helped me be less distracted and frenetic, instead of encouraging exactly that multi-tasking freneticism. When I opened my phone or computer, it'd be nice if it was constrained to operate in a mode purpose-built for whatever task I intended to use it for. If I want to look something up, for instance, my phone should be a look-up machine (ie no texts, no apps, no ads, just a place for my question and the answer). If I want to compose a word of the day entry, I should launch straight into a browser with the tabs I regularly use for that, including the CRM, Webster's dictionary, and the OED; if I want to work on an article, my computer should assume the form of a typewriter, word processor, or McPhee mode note-processor depending on what stage I'm at. In each of these modes everything else should disappear, inaccessible. At least then you could mimic in software that thing you get from physical objects—which is that they are usually built to do one, and only one, thing well. My alarm clock, for instance, is just an alarm clock; and that's what I like about it!
Not too long ago I spoke to a roboticist for an article I was writing, who worked with large autonomous earth-moving machines—e.g. a retrofitted excavator that could lift a boulder, scan its every edge and dimple, then model how it would settle amongst other boulders in a retaining wall before placing it there. He imagined a future in which such machines enabled a return to natural materials in the built world. He talked about old stone walls he’d seen in New England. Those walls, made of loose rocks found in situ, are lovely and sturdy, and adaptive—constantly rebuilt as farmers go about their work and notice areas that need patching up, adding stones they find lying around. But this is the very reason such walls aren't really built anymore. They're too labor-intensive. We live in a prefab world because the scarce thing now is not material or money but "the works and days of hands."
I am moved by the idea that our future could feel less futuristic than pastoral. High tech could save us from high tech. We'd go back to the old interfaces without giving up the conveniences of the new ones. Read, write, communicate, create—and hardly ever see or touch a screen.
I'm not sure that'll happen or be what people want. But shouldn't we be thinking of ways to use the new magic to spend less time tapping and clicking?
When I first started writing for a real publication, I taught myself “reporting” with a simple self-made curriculum unfolding over six or seven articles. The first two pieces I wrote from my head, with reference to things I already knew or to books I’d read. For the third, I actually got out of the house, but didn’t yet have to play the journalist; I just wrote about taking a flying lesson in a small airplane. The fourth article required more gumption: I decided to shadow a friend of mine for a day while he did his job as a derivatives trader. I’m not sure how he got me in the door.
Real reporting involves talking to strangers. For my fifth article I did a single phone interview with someone I’d never met. That wasn’t so bad. For the seventh article, the real leap, I shadowed someone I didn’t know—my old driving instructor. I’d only met him briefly many years before. I asked to go along for a ride in his teaching car—two steering wheels, two sets of pedals. Later, we pulled over and chatted about his life and work. I had not gone to school for this. But I liked the advice I’d gotten from a journeyman reporter. He said, if you tell someone you’re a journalist they’re going to believe you. Your job is to honor their trust.
This was most of what I knew about nonfiction writing when I managed to land an assignment, on spec, to profile Douglas Hofstadter for a piece in the Atlantic’s print magazine. That felt like a big break. But I also wasn’t quite sure what I was supposed to do.
I ended up relying on a very short user’s manual I’d discovered in the The John McPhee Reader, a book of collected journalism from the New Yorker writer John McPhee. In the introduction, William L. Howarth, who edited the collection, described McPhee’s method for producing what the New Yorker called “fact pieces,” or deeply reported nonfiction. I liked the sound of the method, and I liked the products of it. So I just did my best to copy what Howarth said McPhee did. It’s basically the process I’ve used ever since. The method is not that hard to describe and it’s so useful that I think it bears broadcasting. In fact I think those two or three pages from Howarth’s introduction are a decent substitute for journalism school, at one one-hundred-thousandth the price.
In brief, McPhee’s idea is to never face a blank page. Instead, in stage one he accumulates notes; in stage two he selects them; in stage three he structures them; and in stage four he writes. By the time he is crafting sentences the structure of the piece as a whole, and of each section, even paragraph, and the logic connecting them all, is already determined, thanks to the mechanical work done in the first three stages. McPhee is on rails the whole time he writes his first draft. From there it’s all downhill and the standard thing that everybody does: revision, revision again, then refinement—a sculptor with ax, then knife, then scalpel.
Stage 1: Gathering notes
A simple but important question I had going into that first big assignment was when do you start writing? Should you do a little reporting, then write a little, then fill in the holes with more reporting? Or should you do all the reporting up front? (By “reporting” I just mean reading, doing research, calling people, going places, spending time with people in person.)
In the McPhee method, you do all the reporting up front. McPhee usually had one person at the center of each piece, so he would aim to spend a lot of time with that person. He’d go on long backpacking trips with them, or stay at their cottage for a season, or drive across the country with them. He’d immerse himself in their lives for months. And along the way he’d talk to their family, their friends, coworkers, rivals, other people in the same field—to say nothing of all the calls or visits he’d make to experts who could weigh in on this or that.
You can get a sense for what deep reporting looks like by reading one of McPhee’s articles. In “A Sense of Where You Are,” McPhee profiled Bill Bradley, then a wunderkind basketball star at Princeton. (Later, a U.S. senator.) In one set piece, Bradley is practicing jump shots in a gym somewhere.
Last summer, the floor of the Princeton gym was being resurfaced, so Bradley had to put in several practice sessions at the Lawrenceville School. His first afternoon at Lawrenceville, he began by shooting fourteen-foot jump shots from the right side. He got off to a bad start, and he kept missing them. Six in a row hit the back rim of the basket and bounced out. He stopped, looking discomfited, and seemed to be making an adjustment in his mind. Then he went up for another jump shot from the same spot and hit it cleanly. Four more shots went in without a miss, and then he paused and said, “You want to know something? That basket is about an inch and a half low.” Some weeks later, I went back to Lawrenceville with a steel tape, borrowed a stepladder, and measured the height of the basket. It was nine feet ten and seven-eighths inches above the floor, or one and one-eighth inches too low.
Another paragraph discusses Bradley’s uncanny vision on court—hence, “a sense of where you are”—as if Bradley could see “out the back of his head.”
I asked Bradley to go with me to the office of Dr. Henry Abrams, a Princeton ophthalmologist, who had agreed to measure Bradley’s total field. Bradley rested his chin in the middle of a device called a perimeter, and Dr. Abrams began asking when he could see a small white dot as it was slowly brought around from behind him, from above, from below, and from either side. To make sure that Bradley wasn’t, in effect, throwing hope passes, Dr. Abrams checked each point three times before plotting it on a chart. … When he finished plotting Bradley’s circles, the one for each eye was larger than the printed model and, in fact, ran completely outside it. With both eyes open and looking straight ahead, Bradley sees a hundred and ninety-five degrees on the horizontal and about seventy degrees straight down, or about fifteen and five degrees more, respectively, than what is officially considered perfection.
That is what you call access. Fundamentally, McPhee’s writing is good because it is filled with good facts. Good facts are rare, so you must give yourself enough time to acquire them. You have to get in close—build rapport with people, and watch them in their element. McPhee is not sitting across a table with his subjects, conducting an interview. He’s participating.
How long are you supposed to do that, before you come home and move on to Stage 2? When do you stop calling the next friend or expert? McPhee says, you stop when you start hearing the same stories for the third time.
*
The product of all this is notes. You write notes to yourself on reporter pads or notebooks you buy at the pharmacy; you highlight sentences in books, and type those up; you transcribe tape [1] and throw that into the file. Importantly, you don’t do much organizing. All I do is append my notes to a single giant Markdown file under a heading that says which book or article or interview or paper notebook they came from. A gem of a quote, a gem of a thought that will make a fine sentence, is intentionally cast into the same pile that includes arcana you’re probably going to discard.
Already in this stage you are deciding what’s important—literally, what’s noteworthy. I love that about writing. The beauty of having a piece of writing you’re working on is that it changes the way you think. You can’t help but relate whatever you’re doing to the work in progress. I wrote about this once, in More people should write:
When I have a piece of writing in mind, what I have, in fact, is a mental bucket: an attractor for and generator of thought. It’s like a thematic gravity well, a magnet for what would otherwise be a mess of iron filings. I’ll read books differently and listen differently in conversations. In particular I’ll remember everything better; everything will mean more to me. That’s because everything I perceive will unconsciously engage on its way in with the substance of my preoccupation. A preoccupation, in that sense, is a hell of a useful thing for a mind.
This is why it’s so useful to work on an article for a long time. If you’re reporting on something for six months, even if the really concentrated part, the key visit, is only a week or two of that, you have time for notes to accumulate. To give a sense of scale, for a profile I wrote of two Google programmers my notes file had 190,000 words; for an article about COVID and the immune system, the file had 109,000 words. (Granted, most of these words were not notes to self, but rather tape, excerpts from books and articles, and so on. Still: 190,000 words is something like four hundred pages.)
Stages 2 and 3: Bucketing, Structuring
When you get home and decide you’re done reporting, you must take stock of what you have. McPhee typed up all his handwritten notes and put them into a binder. As he read the entries, new ideas would suggest themselves, or there’d be some new research to do, and so he’d type up whatever new notes resulted. The binder would grow a bit, then settle. (At this stage McPhee would sometimes take a stab at the “lead,” that crucial first section, a page or two long, that sets up everything else. But that’s all the writing he’d do from his head, before turning his attention back to the binder of notes.)
Having re-absorbed in a few sittings everything he’d thought and written down about his topic, various large-scale structural ideas would occur to him. He’d have a sense for sections, scenes, and set pieces. As he went, he’d come up with little acronymic codes for these, and write those down on note cards. (For me, this process of deciding what the scenes and sections should be is both top-down and bottom-up: top-down, because sometimes a section you already want to include determines how you perceive the notes that relate to it; and bottom-up, because sometimes you might not realize a section needs to exist until you see it emerging from the notes.)
Having note cards standing for each structural unit makes it easy to consider different arrangements. Do you have to know about X before you can discuss Y? Yes, but you really want Y to come early, because it’s maybe the most fun section; and A and Y have to be next to each other—there’s a great juxtaposition there—keeping in mind that you sort of want to interleave scenes and exposition, so C and A need to be buffered by B… In other words you have a little constraint satisfaction problem. McPhee would solve it by moving his section-cards around on a table.
Do you see how clerical the process is? That is by design. Writing is extremely hard work, easy to procrastinate; the genius of the McPhee method is that it distributes your thinking and decision-making over time so that it rarely feels hard. I can tell you from experience that while “writing a first draft” is intimidating, “reading through all your notes” or moving note cards around on a table, contemplating structure, is not. In fact these tasks are kind of delightful.
*
McPhee would then go through his binder and mark individual notes as belonging to one thematic bucket or another, writing the corresponding shortcode in pencil next to it. Notes that weren’t worth keeping wouldn’t get a code. “Writing is selection,” McPhee likes to say. Which of your notes are worth including? Your writing can only be as good as your taste. As Howarth writes:
McPhee has a passion for details, for they convince readers that he deals in actualities. Added to his journalist’s reverence for facts is a novelist’s propensity for symbols. His task is to burnish objects until they become reflectors of character and theme. Instead of sermonizing on thrift or prodigality, he notes that Donald Gibbie’s teapot is plugged with fourteen wood screws, or that the light in Lt. Arthur Ashe’s closet at West Point is always burning.
Having labeled each note with an acronymic code, McPhee would literally go through his big binder with a pair of scissors, cutting out all the coded notes, sorting them into file folders. The process is recursive. That is, for each file folder he’d go through the same exercise, if a little less rigorously: re-read the notes, feel out the sub-structural beats, make notecards for each of those, arrange them into a logical sequence, then label and file the notes once more.
If you do this, what you end up with is at least two levels of structure: the major sections of the piece, and for each, the flow of ideas through that section. When you go to write, everything you want to say and all the material that supports your saying it is already laid out.
If the best New Yorker fact pieces feel rich, it is maybe because they are grown bottom-up from a huge repository of notes, sifted and arranged for impact. Compare the way one might naively think writing happens: perhaps the author sits at their keyboard with an impulse to say something, and draws on the facts, metaphors, and anecdotes that come to mind. People do write that way, but it’s not what you do if you’re after the thing that McPhee is famous for. If you’re a curious reporter diving into worlds you don’t know—oranges; nuclear science; geology; the life of a long-haul trucker—you first have to go out there with some notebooks and soak, and soak, until you’ve soaked so much that you feel like you get it—and your task then is to rebuild for the reader, in compressed form, all of what you saw and learned to get you to that point. I don’t know how to do that except by building the piece out of the notes themselves.
Interlude: Organizing notes digitally
Lest you think that McPhee is a product of a bygone era, working with paper, binders, scissors and pen, he actually switched early to computers. The software he has been using since the mid-1980s is in fact more sophisticated and tailored to his needs than that of almost any writer working today.
He described his setup in detail in a piece called “Structure.” A friend of McPhee’s, named Howard Strauss, in the Princeton I.T. department, customized a text editor called Kedit for him. One sub-program was called Structur:
Structur exploded my notes. It read the codes by which each note was given a destination or destinations (including the dustbin). It created and named as many new Kedit files as there were codes, and, of course, it preserved intact the original set. In my first I.B.M. computer, Structur took about four minutes to sift and separate fifty thousand words. My first computer cost five thousand dollars. I called it a five-thousand-dollar pair of scissors. … Some of those files created by Structur could be quite long. So each one in turn needed sorting on its own, and sometimes fell into largish parts that needed even more sorting… So Howard wrote Alpha. Alpha implodes the notes it works on. It doesn’t create anything new. It reads codes and then churns a file internally, organizing it in segments in the order in which they are meant to contribute to the writing.
Hovering over a note with Structur, McPhee could type a series of keys and the note under his cursor would get assigned to a bucket, sent instantly to a separate file; another key would mint a new bucket, or change its shortcode. Then, turning to Alpha, notes that had been filed into separate buckets could be re-integrated into something like an outline. (At least that’s how I imagine it works.)
For the longest time, when I worked my own notes using the McPhee method, I would do all the bucketing via cut-and-paste. I used a program called Textmate on my Mac. From one big Markdown file I would cut notes and paste them into sub-files according to topic or scene. (A pale imitation of Structur.) Working inside one of the sub-files, I’d arrange notes within Markdown headings. Keyboard shortcuts inside Textmate helped, but the process was still tedious. (A pale imitation of Alpha.) In about 2021 I found myself lamenting that John McPhee, then already ninety years old, had a more sophisticated setup for managing his notes than I did. I’m a programmer, for God’s sake.
I ended up landing on a solution that uses org-mode inside Emacs. I call it “McPhee mode”. When I turn it on with a keyboard shortcut, my entire file of notes is optimized for refiling into buckets. Each bucket gets assigned a shortcode, corresponding to a keybinding—as simple as the letter A or l, or more complicated if I have lots of buckets. Whenever I see a line or excerpt I want to file away, I need only hit the corresponding keys to have the note slurped into a bucket. As notes are filed they get highlighted. Each note keeps track of where it came from. Doing this within a single large file makes undo/redo work automatically. The tool has made the filing process not just tolerable but even sort of pleasant.
A short screencast of my “McPhee mode” Emacs refiling system in action.
Stage 4: Drafting
Outlined in this fashion, McPhee’s writing methods may seem excessively mechanical, almost programmatic in his sorting and retrieval of data bits. But the main purpose of this routine is at once practical and aesthetic: it runs a line of order through the chaos of his notes and files, leaving him free to write on a given parcel of work at a given time. The other sections cannot come crowding in to clutter his desk and mind; he is spared that confusion by the structure of his work, by an ordained plan that cannot come tumbling down. The strategy locks him in, gives him no easy exits from the materials at hand, which he must confront with that humorless partner, the typewriter. –Howarth, The John McPhee Reader
The main advantage of the McPhee method is that so much of the hardest work is done up front. Writing can proceed without interruption. I dread but then always enjoy the intense period where I emit a first draft. It requires gearing up for. But thanks to the McPhee method, once I start drafting I’m usually at it for just five or six nights. It takes me about five or six hours each night to write a section, plowing through the notes that have been scrupulously prearranged.
I should say that in those nightly encounters I rarely go straight from notes to full sentences. I bridge the gap with a kind of pseudowriting. In effect it’s an outline that takes the form of paragraphs, mixed in with the raw notes. I write good full sentences, broken half-sentences, non-sentences that also include todos in them. I use a lot of square brackets. Suppose I’m working on a scene set at Alta, Utah, among the “snow safety” patrollers, in an article about avalanches. At the pseudowriting stage, the first paragraph might look like this:
One night earlier this winter, the only road out of Alta, Utah, was closed down. [warning signs inside hotels]… That season, there had already been [n] feet of snow… I had flown in that morning after being told that a storm had dumped… Our lodge, like the others… [concrete buildings like bunkers; 3/4 of all buildings in avalanche path!]. [the most serious avalanche hazard in the country. highway 210 has highest AHI in the country - 1045. at 40 you already require avalanche controller]
… then cut to ski patrol
Underneath this mess, all the relevant notes are on hand. Writing this way you are not staring into the abyss. You’ve got good facts; they’re in a good order. Your only job at that point is to turn them into something that’s fun to read:
One night earlier this winter, the only road out of Alta, Utah, was closed down. At ski lodges, signs warned guests to stay inside or face fines. Already that season, twenty-two feet of snow had fallen, and, the day before, a storm had dropped thirty-three inches; another foot was predicted by morning. The most dangerous time for avalanches is after a rapid snowfall, and three-quarters of the buildings in Alta are threatened by a known avalanche path. A standard measure for danger on roads, the Avalanche Hazard Index, computes risk according to the size and frequency of avalanches and the number of vehicles that are exposed to them. An A.H.I. of 10 is considered moderate; at 40, the road requires the attention of a full-time avalanche forecaster. State Highway 210, which runs down the mountain to Salt Lake City, if left unprotected, would have an A.H.I. of 1,045.
Just before 5 A.M., a small group of ski patrollers gathered at a base by the resort’s main lift. …
So much of writing is managing your own emotions. The virtue of “pseudowriting” is that it helps you preserve hope for as long as possible—hope that what you will eventually put in place of those square brackets will be good. Hope keeps you coming back: it is more pleasant and low-stakes to pseudowrite than to fix actual language into the draft; and it is less daunting to return to a document where it feels like all that’s left is for you to fill in some blanks. Do that enough times and you will, in fact, end up with something you can read top to bottom.
The rest of the process is the stuff everyone already does. “All writing is rewriting.” You revise, you check your facts, you do more reporting, you restructure, you revise, you compress. But god is this easier once that first draft is in hand. The McPhee method offers a reliable procedure for getting there.
If you’re interested in the McPhee method, you should start by reading William L. Howarth’s introduction to The John McPhee Reader, then the McPhee articles themselves, and finally McPhee’s own Draft No. 4: On the Writing Process.
Footnote
[1] A word about tape: McPhee “never uses tape recorders when interviewing, for they inhibit some people and are too subverbal for his purposes,” according to Howarth. “The writing process must begin with words—a scrap of talk, bits of description, odd facts and inferences—and only a pencil and notebook will answer those needs with literacy and economy.” It’s true that the brain is the best filter, because what sticks with you after a conversation is often what’s most interesting, both to you and to the eventual reader. If you pay too much attention to the tape, and not to your own impressions, you might actually give the reader a worse sense of what it’s like to be around a person.
Even so, conversations move fast. Notes help. I personally can’t listen well and take good notes at the same time. I’ve settled on a routine in which I record most conversations, but write highlights and impressions as I go and just after I finish. (I recall McPhee saying somewhere he made an exception for highly technical conversations, especially among multiple people. A lot of what I write about is technical, and so tape is my friend.)
On podcasts it's pretty common to hear something like this:
So Alexander Hamilton has just finished law school, and he's trying to
make a name for himself. He's only been in New York a few years. So he
takes on this case...
The problem with the past tense ("Hamilton had just finished law school,
and was trying to make a name for himself") is that, very subtly, it
preserves the distance that history already has. Old worlds can feel
unreal. The "historical present," as deployed here, invites you into
Hamilton's shoes. It's the rhetorical equivalent of that transformation
that Peter Jackson pulled with World War I footage in They Shall Not
Grow
Old.
At its best, it makes history feel... present.
But you've got to pick your spots. The historical present might be
valuable when you're describing a scene---a moment---and an individual
acting in it. It can make those moments vivid. But if you just use it
willy-nilly anytime you talk about the past, it's confusing. After all,
it's the wrong tense.
I've found that the New York Times's
Daily reaches for the
historical present almost as if it were against the style guide not to.
And yet this is a podcast that normally takes such great pains to be
clear.
Here's an example from an
episode
about the reaction in Wuhan to the coronavirus outbreak. The host,
Michael Barbaro, wants to get the reporter to talk in the historical
present. The reporter sometimes obliges, but sometimes swings to the
past tense. The result is a muddle:
MICHAEL BARBARO
And what is the scene at the airport?
AMY QIN
The scene at the airport was a little bit frenzied. [...] So I'm in
the airport lobby and I'm waiting for my flight. [...]
MICHAEL BARBARO
So what happens once you land?
AMY QIN
So once I land, I find that I am at the Miramar Marine base in San
Diego, California. [...] And I've never seen people come together
like this before---and people were so upset about his death.
MICHAEL BARBARO
And what are they saying?
AMY QIN
A lot of people were posting candle emojis and other kinds of
remembrances for Dr. Li.
For a while, it still works. But jumble tenses long enough, and the
timeline becomes genuinely hard to follow:
AMY QIN
So the reaction is really remarkable. [...] It was so clear that
this was something that had really tapped into the frustration that
was happening.
MICHAEL BARBARO
And what do you make of those reactions? Because it feels like it no
longer is really just about this virus and the way that it was
handled?
AMY QIN
Yeah so at this point, it is clear that this is becoming so much
bigger than just the virus. [...] People in China are already used
to a pretty high level of censorship, but when it comes to censoring a
warning about public health, that goes too far. And the reaction is so
overwhelming that the government quickly realizes that they need to do
something. And that's when we see China's leader Xi Jinping come
forward out of the shadows and try to take control of the situation.
Barbaro's first question---"What do you make of those reactions?"---is
ambiguous. Does he mean, What do you make of those reactions today,
right now, as we're speaking, or, What did you make of those reactions
at the time? He means the latter.
This kind of miscue happens often when you use the historical present to
refer to the recent past---because what tense are you supposed to use to
refer the actual present?
Just yesterday I was listening to another episode, this one about kids
returning to school amid the Delta
variant.
Once again, the host, Sabrina Tavernise, tried to foist the historical
present upon the guest. Once again, perhaps because that felt so
unnatural, the guest only halfheartedly went along:
SABRINA TAVERNISE
Richard, what happens when the Delta variant starts surging in
Arkansas?
RICHARD FAUSSET
So, Arkansas, like most states, saw this really nice trough with very
low numbers of new cases that went from the spring into the early
summer. The whole idea of wearing a mask starts to fade into the
background. And life starts to kind of return to normal. But then
Delta hits in the summertime. And you started to see [...] And this
vaccine hesitancy became [...]
The two continued mostly in the historical present, sometimes switching
tenses like this, gradually narrating events until the timeline got
closer and closer to now. Fine. The real trouble came when the reporter
wanted to talk not about specific events but about broader themes:
RICHARD FAUSSET
So the governor is going around the state and, particularly recently,
we've seen some of the vaccination numbers go up in the state. But
it's still lagging compared to a lot of states. And in the meantime,
the beginning of school is looming ever larger. [...] And it kind
of rolls into this big ball of concern about how kids are actually
going to be able to go back to school safely. And it's that concern
that really brought the question of masks in school back to the
forefront of the conversation in Arkansas.
The "particularly recently" makes it sound like we're talking about
where things stand right now; the last sentence makes it sound like no,
we've been setting something up in the historical present. It's hard to
parse.
I'm not cherrypicking; the Daily does this in almost every episode.
That's because Barbaro pushes the conversation that way:
This tense is in the air; when you start listening for it, you hear it
everywhere. On the BBC's In Our
Time, the
host only occasionally nudges his guests into the historical present;
mostly they go there themselves. Often it works; sometimes it doesn't.
On an episode about the Siege of
Paris, the group is happily
using the historical present throughout. Here's a typical example:
JULIA NICHOLLS (40:25)
If we look at the event itself, it almost has an outsized legacy
compared to what the event is. [...] It's taken up by various
different international left movements [...]
Later in the episode, the host, Melvyn Bragg, finds that the present
tense has been burned talking about the past:
JULIA NICHOLLS (44:30)
I think that the Communards also saw this as a continuation of a
battle that had been going on since 1789 [...] It was their duty,
it was an obligation to fight against those people.
MELVYN BRAGG
What do they think about this in France?
ROBERT GILDEA
What do they think about it NOW?
MELVYN BRAGG
Yeah
I love the historical present---I've used it a few times in this
post---but I wish it were deployed more thoughtfully. It's great for
narration, less so for exposition. It works well for the far past (the
Triassic, say), when there's no chance of ambiguity, but it can make a
mess of recent history. It's especially fraught when you want to mix
timeframes, like on podcasts that discuss the news or the legacy of
historical events.
When in doubt, is it so crazy to use the past tense to describe the
past?
The game of Five'Em was invented by two friends of mine, Ben Gross and Rich Berger, to combat Hold'Em fatigue.
The rules are simple: You're dealt five hole cards instead of two, and after each round of community cards comes out (starting with the flop), you discard one of these extras. After the river is dealt, and you've discarded your third extra card, you end up with a classic Hold'Em hand.
Five'Em has some of the pre-flop dynamics of Omaha, in that a seemingly excellent hand -- say, a pair of kings and a pair of tens -- might actually lead to some hard decisions, because you'll only be able to hold on to one of those pairs. But since you always seem to have decent shot at a good hand, it's hard to imagine folding early.
The extra decision on each "street" forces you to think more explicitly about odds and outs. It's one thing to be on a straight draw, and another to weigh playing for that draw against, say, holding on to the top two pair.
It's as if you're playing multiple people's Hold'Em hands simultaneously, with the twist that you're forced to fold one at each turn. It's more fun than the classic game because you've always got more chances -- but of course your opponents do too, which means you've got to adjust your sense of a winning hand.
As a one-time offer, we're waiving the $15 licensing fee -- if you've got a standard deck of cards, feel free to start playing!
In 1963, the philosopher Edmund Gettier published a three-page paper in the journal Analysis that quickly became a classic in the field. Epistemologists going back to the Greeks had debated what it meant to know something, and in the Enlightenment, a definition was settled upon: to know something is to have a justified true belief about it:
justified in the sense of deriving from evidence
true, because it doesn't make sense to "know" a falsehoood
belief, i.e., a proposition in your head
Gettier, in his tiny paper, upended the consensus. He asked "Is Justified True Belief Knowledge?" and offered three cases---soon to be known as "the Gettier cases"---that suggested you could have a JTB about something and yet still we would want to say you didn't know it. For that, he earned lasting fame, and his paper generated a literature all its own.
A Gettier case
Supppose you're standing in a field and off in the distance you see a cow. But suppose that what you're actually looking at isn't a cow, it's just a convincingly lifelike model of a cow made out of papier-mâché. You're not seeing a cow, you're seeing the model. But then finally suppose that right behind the papier-mâché cow is a real cow!
On the one hand, you have a justified true belief that "there is a cow in the field": (1) you believe there's a cow in the field; (2) that belief didn't come from nowhere, but is justified by your seeing something that looks exactly like a cow; (3) and there is, in fact, a cow in the field. Still, we wouldn't want to say that you know there's a cow in the field, because in a sense you got lucky: by a strange coincidence, there happened to be a real cow there---a cow you knew nothing about.
In software engineering
At my old company, Genius, the CTO---who'd studied philosophy as an undergrad---was obsessed with these Gettier cases. He called them "gettiers" for short. So we used to talk about gettiers all the time, no doubt in part just because it felt clever to talk about them, but also because when you're a programmer, you run into things that feel like Gettier cases with unusual frequency. And once you have a name for them, you start seeing them everywhere.
Here's a recent example. I was working on a web application that used a client-side framework that had been developed in-house. My app was a little search engine, and in my latest pull request, I'd made it so that when you hit Enter in the search field, the field lost focus, so that folks who like to browse the web via their keyboard wouldn't have to manually escape from the input box.
When I released the new version, I noticed that I'd broken the autofocusing of the search field that was supposed to happen on pageload. I started poking around, only to discover that I couldn't seem to get the correct behavior back. No matter what code I changed, which lines I commented out, how many times I hard-refreshed the browser, etc., I couldn't get the autofocus to work.
What had actually happened is that a coworker of mine had made a change to the framework itself, which changed how certain events were bound to the root DOM element, and as a result broke the "autofocus" attribute. At some point, I did a routine rebase on top of this change (and many other unrelated changes). Which meant that when I deployed my little pull request, I was also deploying a bug I had nothing to do with---one that ended up breaking autofocus. It only appeared as though my changes caused the problem, because I'd edited some code having to do with focus in the search field.
Note that I had a justified belief that "the pull request I just deployed broke autofocus on the production site," and in fact my change did break it---making the belief true. But the break actually happened for a completely different reason!
(Yes, I should have caught the bug in testing, and in fact I did notice some odd behavior. But making software is hard!)
Here's another example. (This one's from a long time ago, so the details might be a bit off.) A user once reported that on-site messages were no longer generating email notifications, and I was asked to investigate. Soon, I discovered that someone had recently pushed a change to the code that handled emails in our web app; the change seemed to introduce a bug that was responsible for the broken behavior. But---gettier!---the email service that the code relied on had itself gone down, at almost the exact same time that the change was released. I could have had a JTB that the code change had caused the emails to stop delivering, but still we wouldn't want to say I "knew" this was the cause, because it was actually the service outage that was directly responsible.
A new term of art
A philosopher might say that these aren't bona fide Gettier cases. True gettiers are rare. But it's still a useful idea, and it became something of a term of art at Genius---and has stuck with me since---because it's a good name for one of the trickiest situations you can get into as a programmer: a problem has multiple potential causes, and you have every reason to believe in one of them, even though another is secretly responsible.
Having a term for these tricky cases allows you, I think, to be ever-so-slightly more alert to them. You can be a better developer this way. As I've spent more time writing software, I've gotten better at sensing when my assumptions are probably wrong---when something gettieresque might be going on: have I forgotten to clear the cache? Am I working off the wrong branch? Am I even hitting this code path?
Software is a complex and ephemeral business. More than most people, developers are daily faced with bizarre epistemological problems. It helps to be able to distinguish a cow in the field from, well, a gettier.
