De hecho, la proporción de tiempo dedicado a leer frente a escribir es muy superior a 10 a 1. Estamos constantemente leyendo código antiguo como parte del esfuerzo por escribir código nuevo. — Robert C. Martin
—¿Qué perdura después de esta línea?
La lectura como trabajo principal
De entrada, Robert C. Martin desmonta una idea común en la programación: que el valor del desarrollador se mide sobre todo por lo que escribe. En realidad, sostiene que la mayor parte del tiempo se invierte en leer, interpretar y comprender código existente. Así, antes de añadir una sola línea nueva, el programador debe navegar decisiones previas, estilos heredados y dependencias ocultas. Por eso, la escritura de software no empieza en el teclado, sino en la lectura atenta. Ese cambio de perspectiva resulta crucial, porque convierte la comprensión en una habilidad central del oficio. No se trata solo de producir código, sino de entrar en conversación con sistemas ya vivos.
El peso del código heredado
A continuación, la cita apunta al papel del llamado código antiguo o legado, que acompaña casi cualquier proyecto real. Rara vez se construye desde cero; más bien, se modifica, corrige o amplía una base que otros escribieron antes. En ese contexto, cada nueva función exige primero descifrar qué hace el sistema y por qué fue diseñado de cierta manera. Esta realidad aparece una y otra vez en la industria. Martin Fowler, en Refactoring (1999), muestra precisamente que mejorar software existente requiere entenderlo antes de transformarlo. De ese modo, leer código legado deja de ser una tarea secundaria y se vuelve el terreno donde se decide la calidad del cambio futuro.
Comprender antes de intervenir
Desde ahí, la frase también encierra una ética de prudencia: quien no entiende bien lo que lee corre el riesgo de escribir cambios que rompan más de lo que arreglan. Leer código no es un trámite previo, sino una forma de investigación. Cada nombre de variable, cada función extensa y cada comentario ambiguo ofrece pistas sobre la intención original y sobre posibles fragilidades. En consecuencia, escribir bien depende de saber preguntar al código lo correcto. Un desarrollador experimentado suele dedicar tiempo a rastrear flujos, revisar pruebas y seguir dependencias antes de actuar. Esa pausa inicial, lejos de ser lentitud, es lo que evita errores costosos y permite intervenir con precisión.
La calidad de la escritura mejora la lectura
Sin embargo, la observación de Martin no solo describe cómo trabajamos; también sugiere cómo deberíamos escribir. Si otros pasarán mucho más tiempo leyendo nuestro código que nosotros redactándolo, entonces la claridad se vuelve una obligación. Nombres expresivos, funciones pequeñas y una estructura coherente no son adornos estilísticos, sino ayudas concretas para futuros lectores. Aquí resuena Clean Code (2008), donde el propio Martin defiende que el código debe comunicar intención. En otras palabras, escribir para ser leído es una forma de respeto profesional. Cuanto más fácil resulta comprender una pieza de software, más seguro y sostenible será ampliarla después.
Una lección sobre colaboración y tiempo
Finalmente, la cita revela que programar es una actividad profundamente colectiva y acumulativa. Incluso cuando un desarrollador trabaja solo, lo hace sobre rastros de decisiones ajenas o sobre código propio que más tarde le resultará casi extraño. Leer, entonces, es también colaborar a través del tiempo: entender a otros para poder continuar su trabajo sin destruirlo. Vista así, la proporción “muy superior a 10 a 1” no es una exageración retórica, sino una advertencia práctica. Los mejores equipos no solo producen mucho código; producen código legible, navegable y fácil de retomar. Y precisamente por eso, quien aprende a leer bien software suele terminar escribiéndolo mucho mejor.
Un minuto de reflexión
¿Qué pequeña acción sugiere esto?
Citas relacionadas
6 seleccionadasSi quieres ir rápido, si quieres terminar rápidamente, si quieres que tu código sea fácil de escribir, haz que sea fácil de leer. — Robert C. Martin
Robert C. Martin
A primera vista, la frase de Robert C. Martin parece paradójica: para ir rápido, hay que detenerse a escribir código fácil de leer.
Leer interpretación completa →No basta con que el código funcione; debe ser elaborado con el mismo cuidado con el que nombrarías a un hijo primogénito. — Robert C. Martin
Robert C. Martin
La frase de Robert C. Martin parte de una crítica directa a una idea muy común en desarrollo: creer que el éxito termina cuando el programa compila o produce el resultado esperado.
Leer interpretación completa →Debes nombrar una variable con el mismo cuidado con que nombras a un hijo primogénito. — Robert C. Martin
Robert C. Martin
La frase de Robert C. Martin convierte una tarea técnica en una decisión casi moral: nombrar una variable no es un gesto menor, sino un acto de responsabilidad.
Leer interpretación completa →No basta con que el código funcione. — Robert C. Martin
Robert C. Martin
A primera vista, la frase de Robert C. Martin parece sencilla, pero encierra una crítica profunda a una costumbre muy extendida: confundir funcionalidad con calidad.
Leer interpretación completa →Los programas deben escribirse para que las personas los lean, y solo de manera incidental para que las máquinas los ejecuten. - Harold Abelson
Harold Abelson
Harold Abelson coloca la legibilidad en el centro del oficio: el propósito principal del código no es “convencer” a la computadora —que acepta instrucciones literales— sino permitir que otras personas (incluido tu yo fut...
Leer interpretación completa →Los programas deben escribirse para que las personas los lean, y solo de manera incidental para que las máquinas los ejecuten. - Harold Abelson
Harold Abelson
Harold Abelson invierte la intuición común: aunque el software termina ejecutándose en una máquina, su vida real transcurre en la mente de quienes lo construyen, lo revisan y lo mantienen. Por eso, el “lector” principal...
Leer interpretación completa →Más del autor
Más de Robert C. Martin →No basta con que el código funcione; debe ser elaborado con el mismo cuidado con el que nombrarías a un hijo primogénito. — Robert C. Martin
La frase de Robert C. Martin parte de una crítica directa a una idea muy común en desarrollo: creer que el éxito termina cuando el programa compila o produce el resultado esperado.
Leer interpretación completa →Debes nombrar una variable con el mismo cuidado con que nombras a un hijo primogénito. — Robert C. Martin
La frase de Robert C. Martin convierte una tarea técnica en una decisión casi moral: nombrar una variable no es un gesto menor, sino un acto de responsabilidad.
Leer interpretación completa →No basta con que el código funcione. — Robert C. Martin
A primera vista, la frase de Robert C. Martin parece sencilla, pero encierra una crítica profunda a una costumbre muy extendida: confundir funcionalidad con calidad.
Leer interpretación completa →Si quieres ir rápido, si quieres terminar rápidamente, si quieres que tu código sea fácil de escribir, haz que sea fácil de leer. — Robert C. Martin
A primera vista, la frase de Robert C. Martin parece paradójica: para ir rápido, hay que detenerse a escribir código fácil de leer.
Leer interpretación completa →