What You Had to Do

The technical publications department at GTE Data Services employed about a hundred people, and I can tell you with some confidence that not one of them, as a child, had dreamed of documenting mainframe billing programs.

Last time I described the machines — the IBM 370s, the VAX cluster, the eight shared gigabytes. This post is about the people, because the people are the part of that building that still matters.

A Department of Displaced Writers

The writers in Tech Pubs fell, roughly, into two groups.

The first group was frustrated. They were genuine writers — people with novels in drawers, essays in their heads, the real thing — who had discovered that nobody would pay them to write what they wanted to write, and that GTE would pay them, reliably and with dental coverage, to write what nobody wanted to read. Documentation for billing systems. Specifications for reports. The TPS-report genre, produced at industrial scale, fated to sit in binders that would be consulted twice and shredded in a decade.

The second group — mine — had quietly stopped being writers at all. I found the system more interesting than the output. We produced documents in Interleaf, a desktop publishing platform that ran on the VAX cluster, and I discovered that keeping Interleaf and the cluster running was infinitely more rewarding than using them to describe billing software. I had become, without anyone deciding it, a systems person wearing a writer's job code.

What both groups had in common: everybody had things they had to do and things they wanted to do, and the two lists never overlapped. I'd put in my hours documenting the mainframe, drive home, and then work until two in the morning writing code on my Amiga 2000 — doing, for free and with enthusiasm, a harder version of what I'd spent the day doing reluctantly for money.

Nobody in that building would have called their day job meaningful. They would have called it theirs — which is a different thing, and the distinction is about to matter a great deal.

The Scaffolding Theory of Employment

Here is the uncomfortable observation. Almost none of the work in that department was the point of anything. The billing programs existed to bill customers. The documentation existed because the billing programs were too arcane to operate without it. The print shop existed because the documentation had to be distributed. My job existed because the publishing system that produced the documentation needed tending.

Layer upon layer of work that existed only to support other work — scaffolding around the actual structure, which was: send accurate phone bills. The scaffolding employed thousands. It paid mortgages and sent kids to college. It was also, in the strict sense, friction: effort spent overcoming the difficulty of the tools, not creating the value the tools served.

This is not a slight against the people. The friction was real, the skill required to manage it was real, and the economy of 1990 genuinely needed all those hands. But it's worth being honest about the category, because the category is what's now in question.

Those billing programs, the ones we documented at such length? Systems like them are still running — decades of COBOL, still billing. And their maintenance is passing, year by year, to large language models that read the code directly. A machine that can read the program does not need the binder explaining the program. The documentation, the department, the print shop, the gateway PDP-11 of it all — the whole scaffold comes down, not because anyone tears it down, but because the structure no longer needs it.

The Question Nobody Got to Ask

What strikes me now about Tech Pubs is that the "want to do" list was right there the whole time. The frustrated novelists knew exactly what they'd rather be writing. I knew exactly what I'd rather be building — I went home and built it nightly, unpaid. The department was a hundred people holding their actual ambitions in suspension, eight hours a day, because the scaffolding work was what someone would pay for.

The standard anxiety about AI and employment assumes the work being displaced was good work, worth preserving for its own sake. Some of it is. But I keep thinking about that department, and I suspect that what's actually being displaced — first, fastest, most completely — is the friction work. The "had to" column. The work people did so they could afford the evenings in which they did the work they cared about.

Whether what comes after is liberation or just unemployment is a policy question, not a technology question, and I don't pretend it answers itself. But the shape of the question is older than the technology. Everyone in that department was already living it: a life split between obligation and intention, with the obligation funded and the intention not.

The machines are now taking the obligation. What that leaves is the subject of the rest of this series — starting with a wrong turn taken at the very beginning of AI, by the man who named it.