Si no puedes dibujarlo, no lo has entendido

Hablando con Joan Travé sobre si programar es una actividad creativa —él dice que sí, y que a sus amigos les sorprende— salió algo que llevo años usando.

Conozco gente que ve ciertas imágenes antes de poder programar algo. No es una figura retórica: literalmente necesitan visualizarlo primero.

Y un compañero mío tenía una regla al respecto:

Si no puedes hacer un diagrama, un dibujo de lo que quieres hacer, entonces es que no lo has entendido.

Él primero tenía que hacer el diagrama —de flujo, o de memoria, o de lo que fuera— y después programaba.

Por qué esto funciona como prueba

Porque dibujar algo te obliga a comprometerte con las partes.

Cuando explicas algo con palabras, puedes moverte en la ambigüedad sin darte cuenta. Dices "y entonces el sistema procesa los datos" y suena bien. En un diagrama, "el sistema" tiene que ser una caja concreta, "los datos" tienen que entrar por algún lado y salir por otro, y "procesa" tiene que ser algo.

En cuanto intentas dibujarlo, aparecen las preguntas que el lenguaje te dejaba esquivar: ¿de dónde sale eso? ¿a dónde va? ¿qué pasa si no llega? ¿esta flecha es una o son muchas?

No es que el diagrama te ayude a entender. Es que no poder dibujarlo es el síntoma. La confusión ya estaba ahí; el papel sólo la hace visible.

Lo que no significa

No significa que haya que dibujar todo, ni que haya que hacer diagramas bonitos, ni que exista una notación correcta. Un garabato en una servilleta sirve igual.

Y tampoco significa que todo el mundo piense visualmente. Hay quien no, y programa perfectamente. La prueba sigue siendo útil aunque tu forma natural de pensar sea otra: es un chequeo, no un método.

Cómo lo uso

Cuando estoy atorado en algo, lo primero que me pregunto ya no es ¿cómo lo resuelvo? sino ¿puedo dibujarlo?

Si la respuesta es no, ya sé que el problema no está en la implementación. Está antes, en que todavía no sé qué estoy tratando de hacer. Y ponerme a escribir código en ese estado es la forma más eficiente que conozco de perder una tarde.

Vale igual fuera de programar. Si no puedes dibujar el proceso de tu equipo, o el flujo de tu argumento, o la estructura de lo que estás escribiendo, probablemente todavía no lo tienes.

Este texto sale del episodio 019 del Podcast Algoritmos, una conversación con Joan Travé.