MANTENER UN PROGRAMA EN LA CABEZA

Agosto 2007

Un buen programador que trabaja intensamente en su propio código puede mantenerlo en su mente de la misma manera que un matemático mantiene un problema en el que está trabajando. Los matemáticos no responden a las preguntas trabajándolas en papel como se les enseña a los niños en la escuela. Hacen más en sus cabezas: tratan de entender un espacio de problema lo suficientemente bien como para poder recorrerlo como puedes recorrer el recuerdo de la casa en la que creciste. En su mejor momento, la programación es lo mismo. Tienes todo el programa en tu cabeza y puedes manipularlo a voluntad.

Esto es particularmente valioso al comienzo de un proyecto, porque inicialmente lo más importante es poder cambiar lo que estás haciendo. No sólo resolver el problema de una manera diferente, sino cambiar el problema que estás resolviendo.

Tu código es tu comprensión del problema que estás explorando. Así que sólo cuando tienes tu código en la cabeza es cuando realmente entiendes el problema.

No es fácil meter un programa en la cabeza. Si dejas un proyecto durante unos meses, puede llevar días entenderlo de nuevo cuando vuelves a él. Incluso cuando estás trabajando activamente en un programa, puede llevarte media hora cargarlo en la cabeza cuando empiezas a trabajar cada día. Y eso es en el mejor de los casos. Los programadores ordinarios que trabajan en condiciones típicas de oficina nunca entran en este modo. O, para decirlo de manera más dramática, los programadores ordinarios que trabajan en condiciones típicas de oficina nunca entienden realmente los problemas que están resolviendo.

Ni siquiera los mejores programadores tienen siempre todo el programa en el que están trabajando cargado en sus cabezas. Pero hay cosas que puedes hacer para ayudar:

Evita las distracciones. Las distracciones son malas para muchos tipos de trabajo, pero especialmente malas para la programación, porque los programadores tienden a operar al límite del detalle que pueden manejar.

El peligro de una distracción no depende de lo larga que sea, sino de cuánto desordena tu cerebro. Un programador puede salir de la oficina y ir a buscar un sándwich sin perder el código que tiene en la cabeza. Pero el tipo equivocado de interrupción puede borrar tu cerebro en 30 segundos.

Curiosamente, las distracciones programadas pueden ser peores que las imprevistas. Si sabes que tienes una reunión dentro de una hora, ni siquiera empiezas a trabajar en algo difícil.

Trabaja en tramos largos. Dado que hay un costo fijo cada vez que empiezas a trabajar en un programa, es más eficiente trabajar en unas pocas sesiones largas que en muchas cortas. Llegará un momento en el que te volverás estúpido porque estás cansado. Esto varía de una persona a otra. He oído de gente que ha estado hackeando durante 36 horas seguidas, pero lo máximo que yo he podido aguantar son unas 18, y trabajo mejor en trozos de no más de 12.

El óptimo no es el límite que puedes soportar físicamente. También hay una ventaja, además de un costo, de dividir un proyecto. A veces, cuando vuelves a un problema después de un descanso, encuentras que tu mente inconsciente ha dejado una respuesta esperándote.

Usa lenguajes sucintos. Los lenguajes de programación más potentes hacen que los programas sean más cortos. Y los programadores parecen pensar en los programas al menos parcialmente en el lenguaje que están usando para escribirlos. Cuanto más sucinto sea el lenguaje, más corto será el programa y más fácil de cargar y mantener en la cabeza.

Puedes amplificar el efecto de un lenguaje potente usando un estilo llamado programación ascendente, donde escribes programas en múltiples capas, siendo las inferiores lenguajes de programación para las superiores. Si lo haces bien, sólo tienes que mantener en la cabeza la capa superior.

Sigue reescribiendo tu programa. Reescribir un programa a menudo da como resultado un diseño más limpio. Pero tendría ventajas incluso si no lo hiciera: tienes que entender completamente un programa para reescribirlo, así que no hay mejor manera de cargarlo en tu cabeza.

Escribe código legible. Todos los programadores saben que es bueno escribir código legible. Pero tú mismo eres el lector más importante. Especialmente al principio; un prototipo es una conversación contigo mismo. Y cuando escribes para ti mismo, tienes diferentes prioridades. Si estás escribiendo para otras personas, es posible que no quieras hacer el código demasiado denso. Algunas partes de un programa pueden ser más fáciles de leer si las extiendes, como un libro de texto introductorio. Mientras que si estás escribiendo código para que sea fácil de volver a cargar en tu cabeza, lo mejor puede ser ir a por la brevedad.

Trabaja en grupos pequeños. Cuando manipulas un programa en tu cabeza, tu visión tiende a detenerse en los bordes del código que posees. Otras partes que no entiendes tan bien y, lo que es más importante, no puedes tomar libertades con ellas. Así que cuanto menor sea el número de programadores, más completamente podrá mutar un proyecto. Si sólo hay un programador, como suele ocurrir al principio, puedes hacer rediseños totales.

No tengas varias personas editando el mismo trozo de código. Nunca entiendes el código de otras personas tan bien como el tuyo propio. Por mucho que lo hayas leído, sólo lo has leído, no lo has escrito. Así que si un trozo de código está escrito por varios autores, ninguno de ellos lo entiende tan bien como lo haría un solo autor.

Y por supuesto no puedes rediseñar de forma segura algo en lo que otras personas están trabajando. No es sólo que tendrías que pedir permiso. Ni siquiera te dejas pensar en esas cosas. Rediseñar código con varios autores es como cambiar las leyes; rediseñar código que controlas tú solo es como ver la otra interpretación de una imagen ambigua.

Si quieres poner a varias personas a trabajar en un proyecto, divídelo en componentes y asigna cada uno a una persona.

Empieza pequeño. Un programa se vuelve más fácil de mantener en la cabeza a medida que te familiarizas con él. Puedes empezar a tratar partes como cajas negras una vez que te sientes seguro de haberlas explorado por completo. Pero cuando empiezas a trabajar en un proyecto, te ves obligado a ver todo. Si empiezas con un problema demasiado grande, es posible que nunca logres abarcarlo por completo. Así que si necesitas escribir un programa grande y complejo, es posible que la mejor manera de empezar no sea escribir una especificación, sino escribir un prototipo que resuelva un subconjunto del problema. Cualquiera que sean las ventajas de la planificación, a menudo se ven superadas por las ventajas de poder mantener un programa en la cabeza.

Es sorprendente lo a menudo que los programadores logran acertar en los ocho puntos por accidente. Alguien tiene una idea para un nuevo proyecto, pero como no está oficialmente sancionado, tiene que hacerlo en horas extra, lo que resulta más productivo porque no hay distracciones. Impulsado por su entusiasmo por el nuevo proyecto, trabaja en él durante muchas horas seguidas. Dado que inicialmente es sólo un experimento, en lugar de un lenguaje "de producción" usa un mero lenguaje "de script", que de hecho es mucho más potente. Reescribe el programa por completo varias veces; eso no se justificaría para un proyecto oficial, pero este es un trabajo de amor y quiere que sea perfecto. Y como nadie lo va a ver excepto él, omite cualquier comentario que no sea del tipo "nota para mí mismo". Trabaja en un grupo pequeño por la fuerza, porque o bien aún no le ha contado la idea a nadie más, o parece tan poco prometedora que no se le permite a nadie más trabajar en ella. Incluso si hay un grupo, no podrían tener varias personas editando el mismo código, porque cambia demasiado rápido para que eso sea posible. Y el proyecto comienza pequeño porque la idea es pequeña al principio; sólo tiene un hack genial que quiere probar.

Aún más sorprendentes son la cantidad de proyectos oficialmente sancionados que logran hacer todo mal. De hecho, si miras la forma en que se escribe el software en la mayoría de las organizaciones, es casi como si estuvieran tratando deliberadamente de hacerlo mal. En cierto sentido, lo están. Una de las cualidades definitorias de las organizaciones desde que existen es tratar a los individuos como piezas intercambiables. Esto funciona bien para tareas más paralelizables, como hacer la guerra. Durante la mayor parte de la historia, un ejército bien entrenado de soldados profesionales podía contar con vencer a un ejército de guerreros individuales, por valientes que fueran. Pero tener ideas no es muy paralelizable. Y eso es lo que son los programas: ideas.

No es simplemente cierto que a las organizaciones les disguste la idea de depender del genio individual, es una tautología. Forma parte de la definición de una organización no hacerlo. De nuestro concepto actual de organización, al menos.

Quizás podríamos definir un nuevo tipo de organización que combinara los esfuerzos de los individuos sin exigirles que fueran intercambiables. Tal vez un mercado sea una forma de organización de este tipo, aunque puede ser más preciso describirlo como un caso degenerado, como lo que obtienes por defecto cuando la organización no es posible.

Probablemente lo mejor que podamos hacer sea una especie de hack, como hacer que las partes de programación de una organización funcionen de manera diferente al resto. Tal vez la solución óptima sea que las grandes empresas ni siquiera intenten desarrollar ideas internamente, sino simplemente comprarlas. Pero independientemente de cuál sea la solución, el primer paso es darse cuenta de que hay un problema. Hay una contradicción en la misma frase "empresa de software". Las dos palabras se mueven en direcciones opuestas. Cualquier buen programador en una gran organización va a estar en desacuerdo con ella, porque las organizaciones están diseñadas para evitar lo que los programadores se esfuerzan por lograr.

Los buenos programadores logran hacer mucho de todos modos. Pero a menudo requiere prácticamente un acto de rebeldía contra las organizaciones que los emplean. Tal vez ayude si más gente entiende que la forma en que se comportan los programadores está impulsada por las exigencias del trabajo que hacen. No es porque sean irresponsables que trabajan en largas ráfagas durante las cuales se olvidan de todas las demás obligaciones, se sumergen directamente en la programación en lugar de escribir especificaciones primero y reescriben código que ya funciona. No es porque sean poco amigables que prefieren trabajar solos o gruñen a la gente que asoma la cabeza por la puerta para decir hola. Esta aparente colección aleatoria de hábitos molestos tiene una sola explicación: el poder de mantener un programa en la cabeza.

Ya sea que entender esto pueda ayudar a las grandes organizaciones o no, ciertamente puede ayudar a sus competidores. El punto más débil de las grandes empresas es que no dejan que los programadores individuales hagan un gran trabajo. Así que si eres una pequeña startup, este es el lugar donde atacarlos. Aborda el tipo de problemas que tienen que resolverse en una sola mente grande.

Gracias a Sam Altman, David Greenspan, Aaron Iba, Jessica Livingston, Robert Morris, Peter Norvig, Lisa Randall, Emmett Shear, Sergei Tsarev y Stephen Wolfram por leer borradores de este texto.