La Diferencia Entre Leer Código y Escribir Código
Es fácil sentirse un desarrollador fluido mientras apenas se escribe código propio. Revisar pull requests, leer la implementación de un compañero, rastrear un stack trace para encontrar dónde vive realmente un bug — todo eso es trabajo real y valioso, y de verdad mantiene afilada una habilidad. Simplemente no es la misma habilidad que producir código desde cero.
Leer código y escribir código comparten mucha superficie, y eso es exactamente lo que facilita confundirlos. Puedes ser excelente detectando qué está mal en el bucle de alguien más y aun así quedarte, un poco, congelado cuando te piden escribir uno tú mismo desde un editor en blanco. Esa brecha no aparece en ningún momento del trabajo diario — solo aparece en el instante en que algo te obliga a producir en vez de evaluar.
Por qué la comprensión se mantiene fuerte mientras la producción se apaga en silencio
Leer código recibe práctica constante e inevitable: cada pull request, cada reporte de bug, cada archivo desconocido que abres. Escribir código desde cero, en cambio, es cada vez más algo que un asistente hace en un primer borrador, mientras tú revisas y ajustas en lugar de producirlo tú mismo. Una habilidad se ejercita por defecto; la otra solo se ejercita a propósito — y una habilidad que solo se ejercita a propósito es exactamente el tipo que se deteriora sin que nadie lo note.
La sala de entrevistas es donde la brecha se vuelve visible
Por esto exactamente un buen revisor de código puede pasarlo mal en una entrevista de programación en vivo. Leer y criticar una solución terminada se apoya en reconocimiento de patrones construido durante años; escribir una desde un archivo vacío, bajo presión de tiempo, sin un asistente que complete la sintaxis, se apoya en un tipo de recuerdo completamente distinto — y es el que ha tenido mucho menos ejercicio reciente para gran parte de los desarrolladores con experiencia en este momento.
Lo que cada habilidad realmente requiere
- Leer: reconocer la intención. Seguir la lógica de otra persona, detectar el bug real en un diff y entender por qué se eligió un enfoque determinado — todo reconocimiento de patrones sobre código que no tuviste que producir tú mismo.
- Escribir: recordar la sintaxis exacta. Producir estructura de bucles, nombres de métodos y flujo de control correctos de memoria, sin nada que sugiera la siguiente línea — un tipo de recuerdo mucho más literal que el que exige leer.
- Escribir: sostener todo el plan en la cabeza. Estructurar una solución desde cero significa decidir la forma de la respuesta antes de que exista una sola línea, no reaccionar a una forma que alguien, o algo, ya definió de antemano.
- Ambas: saber cuándo realmente estás atascado. Es fácil confundir "reconocería la respuesta correcta" con "podría producir la respuesta correcta" — las dos solo se distinguen realmente al intentar escribirla.
Ejercitar la mitad que se apaga en silencio
Nada de esto es un argumento en contra de la revisión de código, ni de leer el trabajo de otras personas — ambas siguen siendo genuinamente valiosas y vale la pena hacerlas. Es un argumento para tratar el escribir-desde-cero como su propia habilidad, que necesita su propio ejercicio deliberado, en vez de asumir que ya queda cubierta por todo lo demás que implica un trabajo de ingeniería normal.
Ese es el hueco específico que los ejercicios de SoloScript están hechos para cerrar — ejercicios cortos que te obligan a producir realmente una solución, no solo reconocer una correcta, en la práctica.
Gratis, sin necesidad de cuenta. Unos minutos al día bastan para sentir la diferencia.
Empezar a practicar