Hay una frase que se atribuye a casi todo el mundo y que viene a decir que el código se escribe una vez y se lee cien. Sea de quien sea, es cierta. Y, aun así, cuando pensamos en aprender a programar, pensamos en escribir: cursos, ejercicios, proyectos propios. Casi nadie enseña a leer.
Leer código ajeno es probablemente lo que más hago en una semana normal. Una librería que no se comporta como esperaba, un proyecto heredado, el código de una herramienta que uso a diario, una duda sobre cómo resuelve algo otro desarrollador. Y creo que es, con diferencia, la habilidad más infravalorada del oficio.
Por qué es difícil
Escribir es fácil porque tienes el contexto en la cabeza. Leer es difícil porque ese contexto no está: las decisiones, los descartes, la presión con la que se escribió algo un viernes por la tarde. Lo único que llega es el resultado, y no siempre es bonito.
Por eso leer código ajeno incomoda. Nos parece desordenado, raro, "mal hecho". La mayoría de las veces no lo está: está hecho con información que nosotros no tenemos. Aprender a leer es, en buena parte, aprender a suspender el juicio el tiempo suficiente para entender por qué alguien lo hizo así.
Lo que se aprende leyendo
Hay cosas que ningún tutorial te da y que el código de otros sí:
- Otras formas de resolver el mismo problema. Escribes siempre con tus propios hábitos. Leer te enseña que existen más caminos, algunos mejores.
- Cómo envejece el código. Un proyecto con diez años de historia enseña más sobre mantenimiento que cualquier libro: qué decisiones aguantaron y cuáles se convirtieron en una carga.
- Qué es legible de verdad. Se descubre rápido, sufriéndolo, que lo "listo" suele ser lo difícil de leer, y que lo claro casi siempre gana.
- Cómo funcionan las herramientas que usas. Abrir el código de tu generador estático, tu empaquetador o tu librería favorita desmitifica la magia. Después de hacerlo una vez, ya no te dan miedo.
- A depurar. Un error en una dependencia solo se arregla, o se entiende, si eres capaz de moverte por código que no has escrito.
Qué merece la pena leer
No hace falta empezar por lo más grande. De hecho, mejor no hacerlo. Algunas ideas, de menos a más ambición:
- Librerías pequeñas que ya usas. Las que hacen una sola cosa y caben en un par de ficheros. Son el mejor entrenamiento: poco código, un propósito claro.
- El código de tu propia herramienta de trabajo. El generador del sitio, el linter, el servidor de desarrollo. Aprendes cómo funciona lo que das por sentado.
- Proyectos con buena reputación por su claridad. Hay código abierto que se estudia precisamente porque está bien escrito. Merece la pena buscar cuáles son en tu lenguaje.
- Código con historia. Los proyectos con un historial de cambios cuidado permiten ver no solo cómo es el código, sino cómo evolucionó. Las discusiones en las propuestas de cambio enseñan tanto como el propio código.
- Código antiguo, el tuyo incluido. Abrir un proyecto tuyo de hace tres años es un ejercicio de humildad y de aprendizaje a partes iguales.
Lo que no recomiendo es leer sin objetivo durante horas. Funciona mejor con una pregunta: ¿cómo gestiona esto los errores?, ¿cómo organiza las rutas?, ¿por qué eligió esta estructura de datos?
Un truco: léelo como si fuera un texto
Un código no se lee de arriba abajo como una novela. Se explora, y lo que me funciona es parecido a leer un artículo largo: primero el índice (estructura de carpetas y nombres), luego el resumen (el punto de entrada, qué hace en grandes líneas) y solo después los detalles de la parte que me interesa. Si cada vez que algo no encaja te metes en el fondo del asunto, acabas perdido en la tercera capa de abstracción sin saber por qué.
Y mucha atención a los tests: son, a menudo, la mejor documentación que existe. Cuentan cómo se espera que se use cada pieza, con ejemplos que además funcionan.
Por qué importa más que nunca con la IA
Ahora una parte creciente del código que llega a nuestros proyectos no lo hemos escrito nosotros ni lo ha escrito otro desarrollador al que podamos preguntar: lo ha generado una herramienta. Lo comentaba en mi experiencia con Claude Code: lo que hace útil a un asistente no es que escriba, sino que alguien con criterio revise lo que escribe.
Revisar es leer. Quien lee bien detecta lo que sobra, lo que falta y lo que suena convincente pero no es correcto. Quien no tiene el hábito, acepta lo que funciona a primera vista y deja para más adelante los problemas. En un mundo donde producir código es cada vez más barato, entenderlo es lo que no se puede automatizar.
Por eso creo que, de todas las cosas que puede hacer hoy un desarrollador junior para mejorar, leer mucho código bueno está entre las que más rendimiento dan, y de las pocas que no caducan con la próxima moda.
Un hábito pequeño
No hace falta un plan. Basta con reservar un rato a la semana, aunque sean veinte minutos, para abrir el código de algo que usas y leerlo con curiosidad. Sin tomar notas, sin intención de arreglar nada. Al cabo de unos meses cambia la forma en que escribes, y la forma en que trabajas con el código de otros, y entiendes mejor por qué el código abierto ha sido tan importante para todo el sector: es una biblioteca abierta de la que cualquiera puede aprender.
Escribir código se aprende escribiendo, pero escribirlo bien se aprende, sobre todo, leyendo el de los demás. Y como casi todo lo que merece la pena en este oficio, entra dentro del aprendizaje continuo que nunca termina.
