“Indeed, the ratio of time spent reading vs. writing is well over 10:1. We are constantly reading old code as part of the effort to write new code. …[Therefore,] making it easy to read makes it easier to write.”

— Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

Before ChatGPT and its ilk, programmers generally understood what they wrote. This is no longer the case. LLMs are good at translating an intention into a sprawling prototype at superhuman speed. What they don’t readily hand over, and likely will not for the foreseeable future, is an intuitive feel for how something works.

And that’s why we have ReadCode.

More code is entering the world than ever before, and fewer “programmers” can make heads or tails of it. Speak to seasoned Unix wizards (portly fellows with majestic beards who fondly recall System V), and eventually you’ll come to the same diatribe: “higher level languages have taken us away from the hardware; these damn kids don’t know a stack pointer from a hole in the ground!” *

And now we’re moving away from software.

Just like Latin and Sanskrit, COBOL has fallen by the wayside as its adherents have steadily retired or died (though COBOL still holds up a huge percentage of the world’s banking infrastructure). Legacy systems, like ancient texts, need native or native-ish speakers. Coming generations, and maybe current ones thanks to AI dependence, may find themselves content with reciting a japing mantra that has found a chillingly serious life: we don’t know why it runs, it just does—not an especially reassuring engineering philosophy.

And yes, this includes software engineering.

Budding apprentices used to earn their chops through tedium that LLMs now let them sidestep. You can ship a product without building the intuition that lets you fix hidden (or not-so-hidden) bugs. The person you hire to smooth over these issues is likely using the same LLM (albeit, perhaps more adroitly). The on-ramp that used to force understanding on you has been paved over, and there is no reason to believe this will stop.

The scarce skill, the one whose value will keep climbing as writing code gets cheaper, is reading. In practice, this means making sense of a project you didn’t create, that maybe was not “made” by a single human hand, and grasping what it does before it catches fire in production.

BWV 210a Soprano Part, 10th Movement Excerpt—The two different sets of lyrics are in J.S. Bach’s hand. Musical notation by Anna Magdalena Bach.

The Craft Nobody Studies

“Programs must be written for people to read, and only incidentally for machines to execute.”

— Abelson & Sussman, The Structure and Interpretation of Computer Programs

More than ever developers are craftspeople who primarily consume their own work. This is abnormal.

Musicians study scores. Authors are voracious readers first. Architects explore buildings inside and out. Chefs eat everywhere and take notes. Every mature craft treats the study of existing masterworks as a prerequisite to advancement.

Programmers typically read code they’re about to change on a screen under a deadline, with an IDE whispering completions and a notification badge tugging at the corner of their eye. All of this is more like triage. You skim toward the part you need to touch, and the moment you wrap your fingers around it, you probably let go.

Deep reading is different. There’s no keyboard, cursor, or irrepressible itch to adjust. It’s how the legends of yesterday became masters. The machines of earlier eras were small enough to force it, back when you could hold an entire system in your head because you had no other choice.

Ken Thompson & Dennis Ritchie at the PDP-11

Out of Your Workshop

“You can’t trust code that you did not totally create yourself. (Especially code from companies that employ people like me.)”

— Ken Thompson

The move is simple, and almost nobody does it: read a whole codebase the way you’d read a book. Pick one you admire and go through it from start to finish.

I could never make myself do this on a PC. The computer is a workshop. Sitting in a workshop swearing you won’t pick up the tools is a losing game. So I built a utility to remove this urge.

ReadCode turns any source code folder into a Kindle-ready EPUB. Point it at a folder, click Create EPUB, and you get a properly paginated e-book with a real table of contents and syntax-highlighted source. Then it’s ready to drop on a Kindle, sideload into Apple Books, or open in any EPUB reader.

ReadCode turns any folder of source into a Kindle-ready EPUB — folders become chapters, files become sections, syntax intact.

The table of contents is nested: the top level is the directory tree, expanding down to every file, with deep links so you can jump straight to the one you want. It auto-detects 500-plus languages, so Python, Rust, Go, TypeScript, Haskell, Elixir, LISP and hundreds more come through properly formatted.

The syntax highlighting is tuned for e-ink: bold keywords, italic comments, restrained color so it stays legible on a grayscale screen, with a Kindle-optimized theme by default and a handful of others if you want them.

Drag a folder onto the window or paste a path; filter by extension or deny-list what you don’t want; .git, node_modules, .venv and friends are skipped automatically. It’s built for the repos you want to read, up to around 5,000 files. For anything larger, just point it at one subdirectory at a time.

Your code never leaves your computer. ReadCode builds the EPUB locally and outputs the finished text in your desired directory. Then you are free read it on a device that physically cannot run a build, open a tab, ping you, or disrupt your sleep with blue light.

Woodcut from Andreas Vesalius, De humani corporis fabrica libri septem (Basel: Johannes Oporinus, 1543). Wellcome Collection (public domain).

The Future is on Your Bedstand

“The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.”

— Edsger Dijkstra, “The Humble Programmer” (1972). Full text from the University of Texas.

Please don’t misconstrue this as nostalgia. We’re looking towards the future. When anyone can generate code, the person who can read it stays in control. They become immeasurably valuable.

Read more code than you write. This is where we’re headed. It was good advice thirty years ago. Soon it’s going to be the whole game.

ReadCode runs on Windows 10 (build 17763) or newer and produces standard EPUBs that open on Kindle, Apple Books, Kobo, Calibre, Google Play Books, and anything else that reads the format. [Get it here →]

* While the conversations don’t inevitably lead to this and some old-heads have wholeheartedly embraced languages like Python, the sentiment is common enough.

Notes & Sources

Epigraphs

Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship (Prentice Hall, 2008).

Harold Abelson and Gerald Jay Sussman, with Julie Sussman, Structure and Interpretation of Computer Programs (MIT Press, 1985), from the preface.

Ken Thompson, “Reflections on Trusting Trust,” Communications of the ACM 27, no. 8 (August 1984) — his Turing Award lecture.

Edsger W. Dijkstra, “The Humble Programmer,” Communications of the ACM 15, no. 10 (October 1972). The full text is in the E. W. Dijkstra Archive at the University of Texas at Austin.

The COBOL figures come from Reuters, “Banks scramble to fix old systems as IT ‘cowboys’ ride into sunset” (11 April 2017): roughly 43% of banking systems run on COBOL, along with 95% of ATM-swipe transactions and 80% of in-person transactions — some $3 trillion in daily commerce.