⏱️ Lectura: 11 min
El escritor australiano T.R. Napper, ganador del premio Aurealis, lo dice sin vueltas en una entrada reciente de su blog: la regla de oro para escribir mejor es leer mucho, y esa regla vale también para quien programa. Leer código ajeno es, para un desarrollador, el equivalente exacto a lo que Napper le pide a un novelista.
📑 En este artículo
Napper trabaja como escritor de tiempo completo, suma tres trabajos freelance y aun así lee todas las noches en vez de mirar el teléfono. Su argumento es simple: ni un escritor ni un programador deberían saltarse la lectura.
TL;DR
- El escritor T.R. Napper, autor de ciencia ficción y ganador del premio Aurealis, publicó en su blog la regla de oro para escribir mejor.
- Su regla es literal: “Read as much as you can. Read widely and well” (leé todo lo que puedas, y leé variado y bien).
- Napper trabaja tiempo completo como escritor, suma tres trabajos freelance y aun así lee todas las noches.
- Da tres razones: la lectura enseña estructura y estilo, inspira ideas cruzando géneros y cambia físicamente el cerebro.
- Cita a Stephen King, quien nombra Blood Meridian, The Satanic Verses y Huckleberry Finn entre sus favoritos.
- Según Napper, la mayoría de quienes dicen no tener tiempo para leer sí lo tienen: sugiere revisar el tiempo de pantalla.
- La misma lógica aplica a programar: leer código ajeno enseña patrones igual que leer novelas enseña estructura.
- El artículo original, The Golden Rule for Becoming a Better Writer, está publicado en nappertime.com.
Qué pasó
Napper, autor de la serie cyberpunk 36 Streets y ganador del premio Aurealis a mejor novela de ciencia ficción, escribió que existe una sola regla no negociable en la escritura: leer. La llama la regla de oro y la resume en una frase: “Read as much as you can. Read widely and well”.
El disparador de la entrada fue algo que Napper viene notando en sus talleres y en las clases que da como mentor: cada vez más aspirantes a escritores responden “no tengo tiempo para leer” cuando les pregunta qué están leyendo. Algunos, cuando lo piensan un poco más, recuerdan haber leído un libro hace un tiempo.
Su respuesta es directa: revisá el tiempo de pantalla del teléfono. Si marca dos, cinco o siete horas por día, el tiempo para leer existe, solo está ocupado por otra cosa. Napper cuenta que él mismo escribe a tiempo completo, mantiene tres trabajos freelance y aun así lee todas las noches en lugar de ver streaming.
Contexto e historia
La idea de que leer es la base de escribir bien no es nueva. Stephen King dedicó buena parte de su libro On Writing a repetir la misma regla, y según recuerda Napper, King cita Blood Meridian de Cormac McCarthy, The Satanic Verses de Salman Rushdie y Huckleberry Finn de Mark Twain entre sus novelas favoritas: tres estilos completamente distintos entre sí.
Napper también menciona a Kazuo Ishiguro y a Ray Bradbury como ejemplos de autores cuya obra solo se explica por décadas de lectura acumulada. La lógica es acumulativa: cada libro leído, bueno, malo o mediocre, deja una huella en cómo alguien estructura una idea después.
Lo que cambia con el tiempo no es la regla sino la excusa para no seguirla. Antes era la televisión; hoy son las redes sociales y el scroll infinito. Napper compara la situación con una escena de la sitcom Everyone Loves Raymond, donde el protagonista, un periodista, responde a la sugerencia de escribir “la gran novela americana” con un chiste: “¿Escribirla? Ni siquiera querría leerla”. La broma funciona porque describe a alguien sin ningún interés real en la literatura.
Qué tiene que ver esto con programar
Napper no habla de código en ningún momento de su artículo, pero la analogía es directa. Un desarrollador que solo escribe y nunca lee código ajeno termina reinventando patrones que ya existen, mal, y sin saberlo. Leer código ajeno cumple la misma función que leer novelas para un escritor: expone convenciones, estilos de nombrado, formas de manejar errores y decisiones de arquitectura que después aparecen, sin que uno se dé cuenta, en el propio código.
La tabla siguiente resume tres tipos de lectura que un desarrollador puede aplicar hoy mismo, tomando la regla de Napper de forma literal:
| Qué leer | Qué enseña | Ejemplo concreto |
|---|---|---|
| Código fuente ajeno | Patrones, convenciones, arquitectura real en producción | Leer un archivo al azar del repo de Redis en GitHub |
| Documentación técnica y RFCs | Precisión, estructura argumentativa, cómo se explica una decisión de diseño | Leer el RFC 7231 sobre HTTP/1.1 |
| Ficción y no ficción general | Ritmo, estructura narrativa, vocabulario fuera de la jerga técnica | Una novela o ensayo por semana, fuera del stack habitual |
El propio Napper señala algo que aplica igual a programar: lee géneros fuera de lo que escribe. Dice que sus mejores ideas de ciencia ficción no salen de la ciencia ficción, sino de la novela negra: leer hardboiled fiction lo ayudó a entender mejor el origen y el núcleo temático del cyberpunk. Un desarrollador backend que solo lee código de backend se pierde soluciones que ya están resueltas en frontend, en sistemas embebidos o en bases de datos.
💭 Clave: Napper dice que incluso un libro malo enseña algo, aunque sea qué no hacer. Lo mismo pasa con leer código legado mal escrito.
Cómo empezar a leer código ajeno hoy
Napper no da una fórmula técnica, pero la idea se puede convertir en un hábito concreto con herramientas que cualquier desarrollador ya tiene instaladas. El primer paso es clonar un repositorio grande y abrir un archivo al azar, sin buscar nada puntual, solo para leer.
# 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, sin coreutils de GNU)
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-ContentLos tres bloques hacen lo mismo: clonan el código fuente de Redis y abren un archivo .c elegido al azar para leerlo como quien abre un libro por una página cualquiera. No hay que ejecutar nada ni resolver un bug, solo leer.
El segundo paso es llevar un registro simple de la lectura, igual que un lector lleva una lista de libros terminados. Un script corto alcanza:
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);Cada llamada agrega una entrada al archivo lecturas.json con la fuente leída y los minutos dedicados. No mide rendimiento ni calidad, solo constancia, que es exactamente lo que pide Napper: la regla no es leer un libro perfecto, es leer todos los días.
💡 Tip: Clona un repo grande (Redis, curl, el kernel de Linux) y lee un archivo al azar por día sin buscar nada puntual: es lectura, no debugging.
flowchart TD
A["Leer código, docs y prosa variada"] --> B["El cerebro absorbe patrones: estructura, estilo, convenciones"]
B --> C["Esos patrones aparecen al escribir, sin pensarlo"]
C --> D["Mejor código o mejor prosa"]
D --> AImpacto y análisis
La entrada de Napper no es un paper ni trae estadísticas, es la opinión de un autor publicado que lleva años dando talleres. Pero la fricción que describe (gente que quiere escribir sin leer) tiene un espejo casi idéntico en programación: equipos que arrastran código repetido, nombres inconsistentes o arquitecturas mal copiadas porque nadie leyó cómo lo resolvieron otros proyectos antes.
La parte más incómoda del argumento de Napper es la comparación con el tiempo de pantalla. Trasladada a un equipo de desarrollo, la misma pregunta funciona: ¿cuántas horas por semana pasa el equipo revisando pull requests ajenos, leyendo un RFC completo o abriendo un repositorio de referencia, en lugar de solo escribir tickets nuevos?
Hay un límite honesto en esta analogía: leer código no sustituye escribir código, igual que leer novelas no sustituye escribir novelas. Napper mismo lo aclara, la lectura es condición necesaria, no suficiente. Un desarrollador puede leer mil repositorios y seguir escribiendo mal si nunca practica, corrige y recibe revisión de otros.
Qué sigue
Napper sigue publicando en su blog personal sobre el oficio de escribir, además de trabajar en nueva ficción dentro del universo de 36 Streets. Fuera de su caso puntual, la conversación sobre si programar con asistencia de IA reduce la exposición a código ajeno (y por lo tanto el aprendizaje por lectura) sigue abierta en la comunidad de desarrollo, aunque excede lo que cubre este artículo.
Lo concreto y accionable es lo que propone la regla de oro: la única forma de comprobar si funciona es aplicarla, empezando hoy con el primer archivo que se lea completo, sin saltar párrafos.
📖 Resumen en Telegram: Ver resumen
Pruébalo: clona un repositorio que uses todos los días como dependencia y lee un archivo completo antes de escribir tu próxima línea de código.
Preguntas frecuentes
¿Quién es T.R. Napper?
Es un escritor australiano de ciencia ficción, autor de la serie cyberpunk 36 Streets y ganador del premio Aurealis. También da talleres y mentorías de escritura.
¿Cuál es la regla de oro exacta?
“Read as much as you can. Read widely and well”: leé todo lo que puedas, leé variado y leé bien. Napper la considera la única regla sin excepciones del oficio.
¿Esto aplica solo a quienes escriben ficción?
No. Napper habla de escritores en general, y la lógica se extiende sin esfuerzo a cualquiera que redacte documentación técnica, mensajes de commit o código fuente con regularidad.
¿Cuánto tiempo por día recomienda leer?
No da un número fijo. Su sugerencia concreta es reemplazar parte del tiempo de pantalla pasivo (redes, streaming) por lectura activa, todos los días.
¿Leer código ajeno reemplaza practicar programación?
No. Funciona como complemento, igual que leer novelas no reemplaza escribir las propias. Enseña patrones y convenciones, pero la práctica y la revisión siguen siendo necesarias.
¿Dónde puedo leer el artículo original de Napper?
Está publicado en su sitio personal, nappertime.com, bajo el título “The Golden Rule for Becoming a Better Writer”.
Referencias
- The Golden Rule for Becoming a Better Writer: la entrada original de T.R. Napper que plantea la regla de oro de leer para escribir mejor.
- Stephen King: autor citado por Napper como ejemplo de escritor que defiende la lectura extensa como base del oficio.
- Kazuo Ishiguro: uno de los autores mencionados por Napper como ejemplo de una obra construida sobre décadas de lectura.
- Repositorio de Redis en GitHub: ejemplo de código fuente abierto y legible, usado en este artículo para proponer un hábito de lectura de código.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Imagen destacada: Foto de Nathan Aguirre en Unsplash
0 Comentarios