MANTENER UN PROGRAMA EN LA CABEZA

Agosto de 2007

Un buen programador que trabaja intensamente en su propio código puede retenerlo en su mente de la misma manera que un matemático sostiene un problema en el que está trabajando. Los matemáticos no responden a las preguntas trabajándolas en el papel, como se les enseña a los niños en edad escolar. Lo hacen más en sus cabezas: intentan comprender un espacio problemático lo suficientemente bien como para poder recorrerlo de la misma manera que uno puede recorrer el recuerdo de la casa en la que uno creció. En el mejor de los casos, la programación es lo mismo: uno mantiene todo el programa en su cabeza y puede manipularlo a voluntad.

Esto es particularmente valioso al comienzo de un proyecto, porque al principio lo más importante es poder cambiar lo que estás haciendo. No solo 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. Por lo tanto, solo cuando tienes el código en tu cabeza es cuando realmente comprendes el problema.

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

Incluso los mejores programadores no siempre tienen en la cabeza todo el programa en el que están trabajando. Pero hay cosas que puedes hacer para ayudar:

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

El peligro de una distracción no depende de cuánto dure, sino de cuánto te confunda el cerebro. Un programador puede salir de la oficina e ir a comprar un sándwich sin perder el código en la cabeza, pero una interrupción inadecuada puede borrarte el cerebro en 30 segundos.

Por extraño que parezca, las distracciones programadas pueden ser peores que las no programadas. Si sabes que tienes una reunión dentro de una hora, ni siquiera te pones a trabajar en algo difícil.

Trabaja en sesiones largas. Dado que 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 cortas. Por supuesto, llegará un momento en el que te volverás estúpido porque estás cansado. Esto varía de persona a persona. He oído hablar de personas que hackean durante 36 horas seguidas, pero lo máximo que he podido lograr son unas 18, y trabajo mejor en sesiones de no más de 12.

El punto óptimo no es el límite que puedes soportar físicamente. Hay una ventaja y un costo al interrumpir un proyecto. A veces, cuando vuelves a un problema después de un descanso, descubres que tu mente inconsciente ha dejado una respuesta esperándote.

Utilice lenguajes concisos. Los lenguajes de programación más potentes hacen que los programas sean más breves. Y los programadores parecen pensar en los programas, al menos parcialmente, en el lenguaje que utilizan para escribirlos. Cuanto más conciso sea el lenguaje, más corto será el programa y más fácil será cargarlo y guardarlo en la cabeza.

Puedes aumentar el efecto de un lenguaje potente utilizando un estilo llamado programación ascendente, en el que escribes programas en varias capas, y las inferiores actúan como lenguajes de programación para las superiores. Si lo haces bien, solo tienes que mantener la capa superior en tu cabeza.

Sigue reescribiendo tu programa. Reescribir un programa suele dar como resultado un diseño más limpio, pero tendría ventajas incluso si no fuera así: tienes que entender un programa por completo para reescribirlo, así que no hay mejor manera de tenerlo 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 otras prioridades. Si escribes para otras personas, es posible que no quieras que el código sea demasiado denso. Algunas partes de un programa pueden ser más fáciles de leer si las distribuyes, como en un libro de texto introductorio. Mientras que si escribes código para que sea fácil de recargar en tu cabeza, puede ser mejor optar por la brevedad.

Trabaje en grupos pequeños. Cuando manipula un programa en su cabeza, su visión tiende a detenerse en el límite del código que posee. Hay otras partes que no comprende tan bien y, lo que es más importante, con las que no puede tomarse libertades. Por lo tanto, cuanto menor sea el número de programadores, más completamente puede mutar un proyecto. Si solo hay un programador, como suele ser el caso al principio, puede hacer rediseños integrales.

No permitas que varias personas editen el mismo fragmento de código. Nunca entenderás el código de otras personas tan bien como el tuyo. No importa cuán minuciosamente lo hayas leído, solo lo has leído, no lo has escrito. Por lo tanto, si un fragmento de código está escrito por varios autores, ninguno de ellos lo entenderá tan bien como lo haría un solo autor.

Y, por supuesto, no se puede rediseñar de forma segura algo en lo que están trabajando otras personas. No es solo que haya que pedir permiso. Ni siquiera se permite pensar en esas cosas. Rediseñar un código con varios autores es como cambiar las leyes; rediseñar un código que uno solo controla 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 asígnale cada uno a una persona.

Empieza por algo pequeño. A medida que te familiarizas con un programa, resulta más fácil retenerlo en la cabeza. Puedes empezar a tratar las partes como cajas negras una vez que estés seguro de que las has explorado por completo. Pero cuando empiezas a trabajar en un proyecto, te ves obligado a verlo todo. Si empiezas con un problema demasiado grande, es posible que nunca puedas abarcarlo del todo. Por lo tanto, 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 se ven superadas por las ventajas de poder mantener un programa en la cabeza.

Es sorprendente la frecuencia con la que los programadores logran cumplir con los ocho puntos por accidente. Alguien tiene una idea para un nuevo proyecto, pero como no está oficialmente aprobada, tiene que hacerlo en horas libres, 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. Como inicialmente es solo un experimento, en lugar de un lenguaje de "producción" utiliza un mero lenguaje de "scripting", que de hecho es mucho más potente. Reescribe completamente el programa varias veces; eso no sería justificable para un proyecto oficial, pero se trata de un trabajo hecho con amor y quiere que sea perfecto. Y como nadie lo va a ver excepto él, omite cualquier comentario, salvo las notas para sí mismo. Trabaja en un grupo pequeño por fuerza, porque o bien no le ha contado a nadie más sobre la idea todavía, o parece tan poco prometedora que no se permite que nadie más trabaje 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 siendo pequeño porque la idea es pequeña al principio; solo tiene un truco interesante que quiere probar.

Aún más sorprendente es la cantidad de proyectos aprobados oficialmente que logran hacer las ocho cosas mal . De hecho, si observamos la forma en que se escribe el software en la mayoría de las organizaciones, es casi como si estuvieran tratando deliberadamente de hacer las cosas mal. En cierto sentido, lo están haciendo. Una de las cualidades que definen a las organizaciones desde que existen es tratar a los individuos como partes intercambiables. Esto funciona bien para tareas más paralelizables, como luchar en 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 valientes fueran. Pero tener ideas no es muy paralelizable. Y eso es lo que son los programas: ideas.

No sólo es cierto que a las organizaciones no les guste la idea de depender del genio individual, sino que es una tautología. No hacerlo forma parte de la definición de una organización. 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 exigir que fueran intercambiables. Podría decirse que el mercado es una de esas formas de organización, aunque quizá sea más preciso describirlo 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. Tal vez la solución óptima sea que las grandes empresas ni siquiera intenten desarrollar ideas internamente, sino que simplemente las compren . 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 propia frase "empresa de software". Las dos palabras van 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 consiguen hacer muchas cosas, pero a menudo eso exige prácticamente un acto de rebelión contra las organizaciones que los emplean. Tal vez ayude si más gente entiende que la forma en que se comportan los programadores está determinada por las exigencias del trabajo que realizan. No es porque sean irresponsables que trabajen en largas orgías durante las cuales se saltan todas las demás obligaciones, se lanzan directamente a programar en lugar de escribir especificaciones primero y reescriben código que ya funciona. No es porque sean antipáticos que prefieran trabajar solos o que les gruñen a las personas que asoman la cabeza por la puerta para saludarlos. Esta colección aparentemente aleatoria de hábitos molestos tiene una única explicación: el poder de mantener un programa en la cabeza.

Independientemente de si comprender esto puede ayudar a las grandes organizaciones o no, sin duda 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. Por lo tanto, si eres una pequeña empresa emergente, este es el lugar para atacarlas. Enfréntase al tipo de problemas que deben resolverse en un gran cerebro.

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 documento.