Escribir como parte del oficio

Hay una creencia implícita en el mundo del desarrollo que dice que el buen código no necesita explicación. Que si tienes que comentarlo es porque no está bien escrito. Que lo que importa es lo que hace el código, no lo que pensabas mientras lo escribías.

Es una creencia que tiene algo de verdad y mucho de excusa. Sí, el código debe ser legible. Pero el código no puede decirte por qué se tomó una decisión, qué alternativas se descartaron ni qué trampa hay escondida en aquella función que parece inocente. Eso solo lo puede decir quien lo escribió, si tuvo la disciplina de explicarlo.

Programar y escribir se parecen más de lo que parece. Los dos son modos de hacer explícito lo que existe solo en la cabeza. Y los dos se benefician mutuamente.

Escribir para entender

La prueba más honesta para saber si entiendes algo: intenta explicárselo a alguien que no sabe nada del tema. No en una conversación informal donde puedes gesticular y recurrir al "ya sabes, eso de...". Por escrito, con estructura, de principio a fin.

Si no puedes, es que tu comprensión tiene agujeros. Y esos agujeros se notan en el código, aunque tú no los veas.

Esto no es una metáfora — es una experiencia concreta y bastante incómoda. Cuando empecé a escribir artículos técnicos, hubo varias ocasiones en que llegué a la mitad y me quedé bloqueado. No porque no supiera escribir, sino porque el concepto que intentaba explicar tenía una parte que yo usaba por intuición sin haber entendido del todo el mecanismo. El artículo no podía seguir porque mi comprensión tampoco.

Esa es la utilidad principal de escribir: no comunicar lo que ya sabes, sino descubrir lo que creías que sabías y no sabías del todo. El proceso de explicar algo obliga a buscar la explicación que todavía no tienes.

Escribir para recordar

Mi memoria para el código es buena en la lógica general y pésima en los detalles. Puedo recordar cómo funciona un proyecto semanas después de haberlo dejado. Pero los detalles específicos — por qué usé esta solución y no aquella, qué bug me obligó a añadir esa condición aparentemente arbitraria, por qué ese script va en el head y no al final del body — esos se difuminan rápido.

El problema no es que se olviden los detalles. El problema es que sin los detalles, el código futuro ignora los errores del pasado. Vuelves a un proyecto seis meses después, ves una decisión que te parece rara, la "corriges" porque tienes una idea mejor, y al cabo de unos días descubres que la decisión original existía por una razón que ya no recuerdas.

Cuando escribes sobre lo que estás haciendo — aunque sea para ti, aunque sea en un documento privado — estás capturando no solo el qué sino el por qué. Y el por qué es lo que importa cuando tienes que retomar algo meses después o cuando otra persona tiene que continuar tu trabajo.

Un blog técnico, incluso uno con poca audiencia, es una base de conocimiento que crece contigo. Cada artículo es documentación que tu yo futuro agradecerá.

Escribir para comunicar

El desarrollo web no es un trabajo en solitario. Implica hablar con clientes que no saben qué es un CMS, explicar a un diseñador por qué su maqueta no funciona en móvil, documentar decisiones para que otro desarrollador pueda continuar el proyecto sin tener que llamarte.

Todo eso requiere algo que ningún lenguaje de programación enseña: saber traducir ideas técnicas a lenguaje comprensible. Y esa habilidad se entrena escribiendo, no programando.

He conocido desarrolladores técnicamente brillantes que en una reunión con un cliente no sabían por dónde empezar. Y desarrolladores con habilidades técnicas más modestas que, gracias a su capacidad de comunicación, eran mucho más efectivos en su equipo y conseguían que sus propuestas prosperaran. La escritura es el puente entre saber hacer y saber transmitir.

Esto vale también dentro del equipo. Un pull request con buena descripción se revisa mejor. Una propuesta de arquitectura bien escrita genera menos reuniones de aclaración. La comunicación escrita ahorra tiempo a todos, incluido a quien la escribe.

Por dónde empezar

No hace falta prosa elaborada ni publicación semanal ni audiencia. Lo que funciona como punto de partida es mucho más modesto.

Escribe sobre algo que hayas tenido que buscar más de dos veces. Si lo has buscado dos veces, lo buscarás una tercera, y haberlo escrito te ahorrará tiempo. Si lo tuviste que buscar tú, probablemente alguien más también.

Escribe la explicación que le diste a alguien esta semana. Si se la explicaste a un cliente, a un compañero o a un amigo curioso, ya tienes la estructura. Solo hay que pasarla a texto.

Escribe sobre algo que salió mal y cómo lo resolviste. Los artículos más útiles que he encontrado son los del tipo "me encontré con este problema, probé esto, no funcionó, probé esto otro, funcionó, aquí explico por qué". No requieren ninguna erudición — solo la honestidad de contar lo que pasó.

El objetivo no es construir una audiencia. El objetivo es pensar mejor. La audiencia, si llega, es un efecto secundario.

Este blog existe por todas estas razones. No sé cuánta gente lo lee. Sé que escribirlo me ha hecho entender mejor lo que hago, recordar por qué lo hago de cierta manera, y explicarlo de forma que mañana pueda seguir donde lo dejé.