We live inside this bubble, so it's hard to remember, but the job you have today appeared as suddenly as that of a linotype operator.

— Sandi Metz, 2013

Sandi tells our future

I've always enjoyed content about software, whether articles, books, or talks. I can often get more out of reading an hour-long article than I can from spending that same hour tinkering with a program. The best content doesn't just teach me something new; it changes how I think.

A couple years ago, I watched a talk called "Sandi Metz Tells Your Future", and I've re-watched it countless times since. Although the talk is available online, I haven't seen much other discussion about it. This recording is my favourite. Its only comment warns others that the talk contains no technical content. In the narrowest sense, that person is right, but they also completely missed the point.

Sandi Metz is a true OG in the programming community. She is highly technical and wrote the famous POODR book. However, this talk isn't about object-oriented programming nor Ruby. Instead, Sandi shares the history of writing over thousands of years, and what that can tell us about the future of programming. While the content is not technical, it's profoundly important for a technical audience.

The automation of writing

I won't repeat Sandi's talk — instead, I encourage you to watch it yourself. However, I'll summarise the history.

Written information was once recorded in scrolls, made up of a single long page. Scrolls were replaced by codexes, the early form of books, whose pages enabled easy access to and replacement of sections of the text. In both cases, producing copies required human scribes to physically write out the text again.

Gutenberg's printing press made copies cheap and fast, but every letter on a page still had to be manually arranged. Linotype machines used a keyboard and reusable matrices to cast whole "lines of type" from molten metal. Finally, computers removed the metal altogether, replacing "hot type" with "cold type".

One of the slides in Sandi's talk contains a photograph of a decommissioned Linotype machine. Hanging from it is a handwritten sign:

Linotype is COLD

It's both a eulogy and an explanation: hot type had given way to cold type, leaving this machine literally cold. It was once the future, but the future continued without it. I also wonder if the sign has another meaning: Linotype is cold type, its next form in an ongoing journey. This is all just my interpretation, anyway.

The automation of programming

Programmers are writers too. We just write with programming languages instead of natural languages. (Or in addition to, of course.) In both cases, writing is the process of turning thoughts into symbols, which are parsed by a human or a computer. Like other writing, computer programs can now be distributed around the world at almost no cost.

Programming is already built upon layers of automation. Programs were once written as instructions for a specific machine to execute directly. Assemblers and compilers have allowed us to code in progressively higher-level languages. As a result, we can ignore large parts of how code actually executes, in favour of grander problems.

Each of the writing revolutions shared in Sandi's talk happened more quickly than the previous revolution. Scrolls dominated for thousands of years before codexes, but Linotype lasted less than a century before the computer. Inventions build upon each other, seemingly increasing the rate of revolution over time.

These progressions seem obvious in hindsight. It's harder to look forward from where we are now and recognise today as another temporary point in the same progression. Our present technologies and way of life can easily feel like the natural destination of everything that came before us — the end of the long road of human ingenuity. Why should they be?

The next revolution

Writing takes time, no matter what's being written. While the hardest part is deciding what to actually write, it's inarguable that the process of translating these thoughts into symbols still requires mechanical grunt work.

One pattern from the history of writing stood out to me: impressions. Gutenberg cast letters from individual matrices, stereotyping cast pages from matrix compositions, and Linotype cast lines from assembled matrices. In each case, an impression preserved something difficult to make or arrange, enabling cheap reproduction. What would it look like to make an impression of code?

Scratch and no-code systems resemble this superficially, offering pre-made building blocks instead of text. They make programming more accessible, but clicking and dragging boxes is not a revolutionary interface — it does not dramatically reduce translation time, and it loses flexibility and expressiveness. They have not led to an explosion of software in the same way that the printing press led to an explosion of books.

I don't know what the next revolution will look like. How do we get from thought to code with minimal friction — some sci-fi brain interface? And then what happens when the brain itself becomes the next bottleneck?

Preparing for change

Many of my fellow computer science students complain that our classes are too theoretical. They want to learn the languages and frameworks used in "the real world". It's understandable: their goal is to be gainfully employed, and employers seem to hire for specific tools.

I believe that these tools can be learned relatively easily on top of a strong foundation. Personally, I haven't struggled to pick up new tools despite focusing on theory. The not-so-secret secret is to deeply understand problems rather than memorising any current solution. That being said, I haven't been too successful in finding gainful employment.

What happens when the rote task of translating a specific solution into symbols, or copying and pasting an answer from Stack Overflow, is automated? If our contribution is purely mechanical, that mechanism changing makes us vulnerable. We have to become the authors, not the scribes.

The cost of progress

I believe that technological progress is ultimately good, even when it makes existing jobs obsolete. Few people wish that books still needed to be copied by hand or that elevators still needed human operators. We take old inventions for granted because the difficult transitions happened before our time, but the prospect of losing today's jobs tomorrow feels completely different.

For a Linotype operator, the transition to cold type was more than a mention in a Wikipedia article. It nullified their skill and occupation, leaving them displaced. Innovation brings societal benefits and even new jobs, but still comes with a real human cost.

Programmers can sometimes be a little too gleeful about automation, in my opinion. It would do us well to consider that we're not immune simply because we know how to code.

Conclusion

Our present day will eventually be the future's history. On a long enough timeline, programming as we know it today will cease to exist. The question is not if, but when, and how suddenly. Will we be ready?