"Hi, William!"

How We Trained Ourselves To Become the Largest of the Large Language Models (A Bad History)

Part One
Manual Labor: A Reminiscence

In the first half of the 1990’s, I began a career as a professional freelance writer. I don’t mean I finally started to get paid regularly for my ongoing work as a playwright, screenwriter, fiction writer, and essayist. All of that was a manifest washout, professionally.

What I started getting paid for: various kinds of writing that everybody encounters every day and doesn’t think of as writing. Like when you’re wondering what a warning light on your car’s dash means? and you fumble around in the glovebox? and haul out the manual and look it up? (OK, you might find the answer on your phone, or by asking some robot assistant, we’ll get to that—but this was the ‘90’s.) Somebody has to actually write that stuff.

And write it so that you can understand it, and write it economically enough to fit in the book. That might sound fairly easy, but the key considerations make it not as easy as it might sound. Many people don’t write clearly and economically. Even most of the people who write more or less OK are writing something that only approximates what they mean. Few are able to fulfill the number-one requirement of writing manuals: Say exactly what you mean. Which can take a good bit of thought.

Not only does someone have to write your car owner’s manual; someone has to organize it so you can quickly and intuitively find what you want while you're sitting there bewildered behind the wheel (parked, hopefully). You’ve no doubt used indexes, tables of contents, the alphabet, running page headings, sub-heads on pages, etc., etc., for years without thinking much about exactly how they get built into reference work. You notice the quality of the apparatus only when there’s a glitch and you can’t find what you want.

And even then, when people bump up against a failure like that, instead of thinking “this thing is horribly organized,” or “this thing is horribly written,” they often assume they’re missing something that should be obvious. Usually the real failure is on the production side. It’s not so easy to get these things right.

Thanks to people who think about it all the time, however, a lot of manuals are pretty good. People who do this kind of writing the best are operating in a condition of obscurity, where being taken for granted is the biggest win. Since the entire purpose is to deliver a result, the user’s relationship to the writing is largely unconscious. Success is defined by nobody noticing the success.

I didn’t write car owner’s manuals. I wrote a series of manuals for entering data in a mainframe system used by hundreds of people, every day, throughout the five boroughs of New York City, in order to document and track the referral, evaluation, and placement of special-education students in the largest public school system in the country. That process, and the computer system itself, were court-mandated, involving significant compliance issues, with major investment by class-action lawyers, and real penalties, and yet the process was so complicated, and the system so hard to operate, that “the field”—personnel in all of the school districts in all of the boroughs, and their bosses, responsible for the all-important data-entry—were up against it on a daily basis. A training unit was therefore crammed into an office at 110 Livingston Street in Brooklyn. The field would come to 110, in small groups, and sit in a training room next door to that office to learn what were, effectively, the known workarounds for defeating the system’s tendency not to function as expected.

This was my first experience of office work, and the training unit was a lively bunch: I look back with fondness on the whole experience. I may be exaggerating the mainframe system’s kludginess, but it’s true that in my memory, anyway, everyone who knew the system well took it as given that the system sucked.

Return with me, if you will, to a very particular moment in tech. These were the later days of the flashing DOS prompt and the ugly green letters and numbers against a dark screen. “Personal computing” was just coming into city offices; ours had IBM PC or clone desktops—not, at first, intra-networked, so software was installed and stored locally, on each machine, disk by disk—with a wired connection to the off-site location where the citywide computer system ran (maybe at Brooklyn Metrotech). When using the system, we were treating the PC’s as terminals, but I think the field still had a mix of dedicated terminals and PC’s.

I wasn’t one of the trainers—thank God. Some trainers knew the system very well. Others struggled with it. During trainings, the field could get rowdy, thanks to the many annoyances presented by the system, and the weaker trainers came staggering out of training sessions as hollow-eyed and pale as first-year teachers.

I was assigned to write user manuals to be distributed to the field. They’d never had manuals, which meant I had no specific models, not even negative ones. It was all new to me. I had to learn to do at least some data-entry on the system, which meant picking the brains of the trainers who actually knew the system and figuring out some things on my own. Writing those manuals taught me a lot about writing, and about organizing writing, and about the intensive complexity, in general, of public systems that serve mass ends, and the automation of such systems.