MANTENER UN PROGRAMA EN LA CABEZA

August 2007

Un buen programador trabajando intensamente en su propio código puede mantenerlo en su mente de la forma en que un matemático mantiene un problema en el que está trabajando. Los matemáticos no responden preguntas resolviéndolas en papel como se enseña a los escolares. Hacen más en sus cabezas: intentan comprender un espacio de problemas lo suficientemente bien como para poder caminar a su alrededor de la forma en que puedes caminar por la memoria de la casa en la que creciste. En su mejor momento, la programación es la misma. Mantienes todo el programa en tu cabeza y puedes manipularlo a voluntad.

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

Tu código es tu comprensión del problema que estás explorando. Por lo tanto, solo cuando tienes tu código en tu cabeza realmente comprendes el problema.

No es fácil meter un programa en tu cabeza. Si dejas un proyecto por unos meses, puede llevarte días volver a comprenderlo realmente cuando regresas a él. Incluso cuando estás trabajando activamente en un programa, puede llevarte media hora cargarlo en tu cabeza cuando comienzas a trabajar cada día. Y eso es en el mejor de los casos. Los programadores ordinarios que trabajan en condiciones de oficina típicas nunca entran en este modo. O para decirlo más dramáticamente, los programadores ordinarios que trabajan en condiciones de oficina típicas nunca realmente comprenden los problemas que están resolviendo.

Incluso los mejores programadores no siempre tienen 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 su duración, sino de cuánto te desorganiza el cerebro. Un programador puede salir de la oficina e ir a comer un sándwich sin perder el código en su cabeza. Pero el tipo de interrupción equivocado puede borrar tu cerebro en 30 segundos.

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

Trabaja en tramos largos. Como hay un costo fijo cada vez que comienzas a trabajar en un programa, es más eficiente trabajar en unas pocas sesiones largas que en muchas sesiones cortas. Por supuesto, llegará un punto en el que te vuelvas tonto porque estás cansado. Esto varía de persona a persona. He oído hablar de personas que han estado pirateando durante 36 horas seguidas, pero lo máximo que he podido administrar es alrededor de 18, y trabajo mejor en períodos de no más de 12.

El óptimo no es el límite que puedes soportar físicamente. También hay una ventaja, así como un costo de dividir un proyecto. A veces, cuando regresas a un problema después de un descanso, descubres que tu mente inconsciente te ha dejado una respuesta esperando.

Usa lenguajes concisos. Más poderosos lenguajes de programación 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 conciso sea el lenguaje, más corto será el programa, y más fácil será cargarlo y mantenerlo en tu cabeza.

Puedes magnificar el efecto de un lenguaje poderoso usando un estilo llamado programación ascendente, donde escribes programas en múltiples capas, las inferiores actuando como lenguajes de programación para las que están arriba. Si lo haces bien, solo tienes que mantener la capa superior en tu cabeza.

Sigue reescribiendo tu programa. Reescribir un programa a menudo produce un diseño más limpio. Pero tendría ventajas incluso si no lo hiciera: tienes que entender un programa completamente para reescribirlo, por lo que no hay mejor manera de hacer que se cargue 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 que el código sea demasiado denso. Algunas partes de un programa pueden ser más fáciles de leer si se extienden, como un libro de texto introductorio. Mientras que si estás escribiendo código para que sea fácil volver a cargarlo en tu cabeza, puede ser mejor optar por la brevedad.

Trabaja en grupos pequeños. Cuando manipulas un programa en tu cabeza, tu visión tiende a detenerse en el borde del código que posees. Otras partes que no entiendes tan bien, y más importante aún, no puedes tomarte libertades. Por lo tanto, cuanto menor sea el número de programadores, más completamente puede mutar un proyecto. Si hay solo un programador, como suele haber al principio, puedes hacer rediseños que lo abarcan todo.

No permita que varias personas editen el mismo fragmento de código. Usted nunca entenderá el código de otras personas tan bien como el suyo propio. No importa cuánto lo hayas leído, solo lo has leído, no lo has escrito. Entonces, si un fragmento 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 solo que tendrías que pedir permiso. Ni siquiera te permites pensar en esas cosas. Rediseñar código con varios autores es como cambiar leyes; rediseñar código que solo controlas tú es como ver la otra interpretación de una imagen ambigua.

Si quieres poner a varias personas a trabajar en un proyecto, divide en componentes y dale uno a cada persona.

Empieza poco a poco. 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 sientas seguro de que las has explorado completamente. Pero cuando comienzas a trabajar en un proyecto, te ves obligado a ver todo. Si empiezas con un problema demasiado grande, es posible que nunca puedas abarcarlo por completo. Entonces, si necesitas escribir un programa grande y complejo, la mejor manera de empezar puede no ser escribir una especificación para él, sino escribir un prototipo que resuelva un subconjunto del problema. Cualesquiera que sean las ventajas de la planificación, a menudo son superadas por las ventajas de poder mantener un programa en tu cabeza.

Es llamativo la frecuencia con la que los programadores logran dar en el clavo con los ocho puntos por accidente. A alguien se le ocurre una idea para un nuevo proyecto, pero como no está oficialmente autorizado, tiene que hacerlo en horas extras, lo que resulta ser más productivo porque no hay distracciones. Impulsado por su entusiasmo por el nuevo proyecto, trabaja en él durante muchas horas seguidas. Como inicialmente es solo un experimento, en lugar de un lenguaje de "producción" utiliza un simple lenguaje de "scripting", que de hecho es mucho más potente. Él reescribe completamente el programa varias veces; eso no sería justificable para un proyecto oficial, pero esto es una labor de amor y él quiere que sea perfecto. Y como nadie va a verlo excepto él, omite los comentarios excepto la variedad de notas para sí mismo. Trabaja en un grupo pequeño por fuerza, porque o todavía no se lo ha contado a nadie más sobre la idea, o parece tan poco prometedora que a nadie más se le permite trabajar en ella. Incluso si hay un grupo, no podrían tener a 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; él solo tiene un truco genial que quiere probar.

Incluso más sorprendentes son la cantidad de proyectos oficialmente autorizados que logran hacer las ocho cosas mal. De hecho, si observas la forma en que se escribe el software en la mayoría de las organizaciones, es casi como si quisieran hacer las cosas mal a propósito. En cierto sentido, sí lo hacen. Una de las cualidades definitorias de las organizaciones desde que existen es tratar a los individuos como partes intercambiables. Esto funciona bien para tareas más paralelizables, como luchar guerras. Durante la mayor parte de la historia, se podía contar con que un ejército bien entrenado de soldados profesionales derrotara a un ejército de guerreros individuales, sin importar cuán valerosos fueran. Pero tener ideas no es muy paralelizable. Y eso es lo que son los programas: ideas.

No solo es cierto que a las organizaciones no les gusta la idea de depender de un genio individual, es una tautología. Es parte de la definición de una organización no hacerlo. Al menos de nuestro concepto actual de organización.

Tal vez podríamos definir un nuevo tipo de organización que combinara los esfuerzos de los individuos sin requerir que sean intercambiables. Podría decirse que un mercado es una de esas formas de organización, aunque puede que sea más preciso describir un mercado como un caso degenerado, como lo que se obtiene por defecto cuando la organización no es posible.

Probablemente lo mejor que haremos será algún tipo de truco, como hacer que las partes de programación de una organización funcionen de manera diferente al resto. Quizás la solución óptima es 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. Existe una contradicción en la frase "empresa de software". Las dos palabras están tirando 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 buscan.

Los buenos programadores logran hacer mucho de todos modos. Pero a menudo requiere prácticamente un acto de rebelión contra las organizaciones que los emplean. Quizás ayude si más personas comprenden que la forma en que los programadores se comportan está impulsada por las exigencias del trabajo que realizan. No es porque sean irresponsables que trabajan en binges largos durante los cuales ignoran todas las demás obligaciones, se lanzan directamente a la programación en lugar de escribir especificaciones primero, y reescriben código que ya funciona. No es porque sean antipáticos que prefieren trabajar solos o gruñen a las personas que asoman la cabeza por la puerta para decir hola. Esta colección aparentemente aleatoria de hábitos molestos tiene una sola explicación: el poder de mantener un programa en la cabeza.

Ya sea que comprender esto pueda ayudar o no a las grandes organizaciones, ciertamente puede ayudar a sus competidores. El punto más débil de las grandes empresas es que no permiten que los programadores individuales hagan un gran trabajo. Entonces, si eres una pequeña startup, este es el lugar para atacarlos. Asume el tipo de problemas que deben resolverse en un cerebro 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 los borradores de esto.