⏱️ Lectura: 10 min
Australian writer T.R. Napper, winner of the Aurealis Award, puts it bluntly in a recent blog post: the golden rule for becoming a better writer is reading a lot, and that rule applies just as much to programmers. Reading other people’s code is, for a developer, the exact equivalent of what Napper asks of a novelist.
📑 En este artículo
Napper works as a full-time writer, juggles three freelance jobs, and still reads every night instead of scrolling on his phone. His argument is simple: neither a writer nor a programmer should skip reading.
TL;DR
- Writer T.R. Napper, a science fiction author and winner of the Aurealis Award, published the golden rule for becoming a better writer on his blog.
- His rule is literal: “Read as much as you can. Read widely and well.”
- Napper works full-time as a writer, juggles three freelance jobs, and still reads every night.
- He gives three reasons: reading teaches structure and style, it sparks ideas across genres, and it physically changes the brain.
- He cites Stephen King, who names Blood Meridian, The Satanic Verses, and Huckleberry Finn among his favorites.
- According to Napper, most people who say they don’t have time to read actually do: he suggests checking their screen time.
- The same logic applies to programming: reading other people’s code teaches patterns the same way reading novels teaches structure.
- The original article, The Golden Rule for Becoming a Better Writer, is published on nappertime.com.
What happened
Napper, author of the cyberpunk series 36 Streets and winner of the Aurealis Award for best science fiction novel, wrote that there is only one non-negotiable rule in writing: reading. He calls it the golden rule and sums it up in one sentence: “Read as much as you can. Read widely and well.”
The trigger for the post was something Napper has been noticing in his workshops and mentoring classes: more and more aspiring writers answer “I don’t have time to read” when he asks them what they’re reading. Some, when they think about it a bit more, remember having read a book a while back.
His answer is direct: check your phone’s screen time. If it shows two, five, or seven hours a day, the time to read exists, it’s just being spent on something else. Napper says he himself writes full-time, keeps up three freelance jobs, and still reads every night instead of watching streaming shows.
Context and history
The idea that reading is the foundation of good writing isn’t new. Stephen King devoted a good part of his book On Writing to repeating the same rule, and as Napper recalls, King cites Blood Meridian by Cormac McCarthy, The Satanic Verses by Salman Rushdie, and Huckleberry Finn by Mark Twain among his favorite novels: three completely different styles from one another.
Napper also mentions Kazuo Ishiguro and Ray Bradbury as examples of authors whose work can only be explained by decades of accumulated reading. The logic is cumulative: every book read, good, bad, or mediocre, leaves a mark on how someone structures an idea later on.
What changes over time isn’t the rule but the excuse for not following it. It used to be television; today it’s social media and endless scrolling. Napper compares the situation to a scene from the sitcom Everybody Loves Raymond, where the main character, a journalist, responds to the suggestion of writing “the great American novel” with a joke: “Write it? I wouldn’t even want to read it.” The joke works because it describes someone with no real interest in literature.
What does this have to do with programming
Napper never talks about code in his article, but the analogy is direct. A developer who only writes and never reads other people’s code ends up reinventing patterns that already exist, poorly, and without realizing it. Reading other people’s code serves the same function as reading novels does for a writer: it exposes conventions, naming styles, error-handling approaches, and architectural decisions that later show up, without anyone noticing, in their own code.
The table below summarizes three types of reading a developer can apply today, taking Napper’s rule literally:
| What to read | What it teaches | Concrete example |
|---|---|---|
| Other people’s source code | Patterns, conventions, real production architecture | Reading a random file from the Redis repo on GitHub |
| Technical documentation and RFCs | Precision, argumentative structure, how a design decision gets explained | Reading RFC 7231 on HTTP/1.1 |
| Fiction and general nonfiction | Pacing, narrative structure, vocabulary outside technical jargon | One novel or essay per week, outside your usual stack |
Napper himself points out something that applies equally to programming: he reads genres outside what he writes. He says his best science fiction ideas don’t come from science fiction but from crime noir: reading hardboiled fiction helped him better understand the origin and thematic core of cyberpunk. A backend developer who only reads backend code misses out on solutions that are already solved in frontend, embedded systems, or databases.
💭 Key point: Napper says even a bad book teaches something, even if it’s just what not to do. The same goes for reading poorly written legacy code.
How to start reading other people’s code today
Napper doesn’t give a technical formula, but the idea can be turned into a concrete habit using tools any developer already has installed. The first step is to clone a large repository and open a random file, not looking for anything specific, just to read.
# Linux (bash)
git clone --depth 1 https://github.com/redis/redis.git ~/lecturas/redis
cd ~/lecturas/redis/src
ls *.c | shuf -n 1 | xargs less
# macOS (zsh, without GNU coreutils)
git clone --depth 1 https://github.com/redis/redis.git ~/lecturas/redis
cd ~/lecturas/redis/src
ls *.c | sort -R | head -n 1 | xargs less
# Windows (PowerShell)
git clone --depth 1 https://github.com/redis/redis.git $HOME\lecturas\redis
cd $HOME\lecturas\redis\src
Get-ChildItem *.c | Get-Random | Get-ContentAll three blocks do the same thing: they clone Redis’s source code and open a randomly chosen .c file to read it the way someone opens a book to a random page. There’s no need to run anything or fix a bug, just read.
The second step is to keep a simple reading log, the same way a reader keeps a list of finished books. A short script is enough:
const fs = require("fs");
const ARCHIVO_LOG = "lecturas.json";
function registrarLectura(fuente, minutos) {
const previo = fs.existsSync(ARCHIVO_LOG)
? JSON.parse(fs.readFileSync(ARCHIVO_LOG, "utf8"))
: [];
previo.push({ fuente, minutos });
fs.writeFileSync(ARCHIVO_LOG, JSON.stringify(previo, null, 2));
}
registrarLectura("redis/src/t_string.c", 25);
registrarLectura("RFC 7231 - HTTP/1.1 Semantics", 40);Each call adds an entry to the lecturas.json file with the source read and the minutes spent. It doesn’t measure performance or quality, only consistency, which is exactly what Napper asks for: the rule isn’t to read a perfect book, it’s to read every day.
💡 Tip: Clone a large repo (Redis, curl, the Linux kernel) and read one random file per day without looking for anything specific: it’s reading, not debugging.
flowchart TD
A["Read code, docs, and varied prose"] --> B["The brain absorbs patterns: structure, style, conventions"]
B --> C["Those patterns show up when writing, without thinking about it"]
C --> D["Better code or better prose"]
D --> AImpact and analysis
Napper’s post isn’t a paper and doesn’t come with statistics, it’s the opinion of a published author who has spent years running workshops. But the friction he describes (people who want to write without reading) has an almost identical mirror in programming: teams dragging along duplicated code, inconsistent naming, or badly copied architectures because nobody read how other projects solved it before.
The most uncomfortable part of Napper’s argument is the comparison to screen time. Applied to a development team, the same question works: how many hours per week does the team spend reviewing other people’s pull requests, reading a full RFC, or opening a reference repository, instead of just writing new tickets?
There’s an honest limit to this analogy: reading code doesn’t replace writing code, just as reading novels doesn’t replace writing novels. Napper himself makes this clear, reading is a necessary condition, not a sufficient one. A developer can read a thousand repositories and still write poorly if they never practice, get corrected, and receive feedback from others.
What’s next
Napper keeps publishing on his personal blog about the craft of writing, while also working on new fiction within the 36 Streets universe. Beyond his specific case, the debate over whether AI-assisted coding reduces exposure to other people’s code (and therefore learning through reading) remains open in the developer community, though that’s beyond the scope of this article.
What’s concrete and actionable is what the golden rule proposes: the only way to check if it works is to apply it, starting today with the first file read in full, without skipping paragraphs.
📖 Summary on Telegram: See summary
Try it: clone a repository you use every day as a dependency and read one full file before writing your next line of code.
Frequently Asked Questions
Who is T.R. Napper?
He’s an Australian science fiction writer, author of the cyberpunk series 36 Streets, and winner of the Aurealis Award. He also runs writing workshops and mentoring sessions.
What exactly is the golden rule?
“Read as much as you can. Read widely and well.” Napper considers it the only exception-free rule of the craft.
Does this only apply to fiction writers?
No. Napper talks about writers in general, and the logic extends effortlessly to anyone who regularly writes technical documentation, commit messages, or source code.
How much time per day does he recommend reading?
He doesn’t give a fixed number. His concrete suggestion is to replace part of your passive screen time (social media, streaming) with active reading, every day.
Does reading other people’s code replace practicing programming?
No. It works as a complement, just as reading novels doesn’t replace writing your own. It teaches patterns and conventions, but practice and review are still necessary.
Where can I read Napper’s original article?
It’s published on his personal site, nappertime.com, under the title “The Golden Rule for Becoming a Better Writer.”
References
- The Golden Rule for Becoming a Better Writer: T.R. Napper’s original post laying out the golden rule of reading to become a better writer.
- Stephen King: author cited by Napper as an example of a writer who advocates extensive reading as the foundation of the craft.
- Kazuo Ishiguro: one of the authors Napper mentions as an example of a body of work built on decades of reading.
- Redis repository on GitHub: example of open, readable source code, used in this article to propose a code-reading habit.
📱 Enjoying this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.
Imagen destacada: Foto de Nathan Aguirre en Unsplash
0 Comments