MANTENIENDO UN PROGRAMA EN LA CABEZA

Agosto de 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 sostiene 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 entender un espacio de problemas lo suficientemente bien como para poder caminar a su alrededor, como puedes caminar alrededor de la memoria de la casa en la que creciste. En su mejor momento, la programación es lo mismo. Mantienes todo el programa en tu cabeza y puedes manipularlo a voluntad.

Eso es particularmente valioso al inicio 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. Así que solo es cuando tienes tu código en tu cabeza que realmente entiendes el problema.

No es fácil meter un programa en tu cabeza. Si dejas un proyecto durante unos meses, puede llevar días volver a entenderlo cuando regresas a él. Incluso cuando estás trabajando activamente en un programa, puede llevar media hora cargarlo en tu cabeza cuando comienzas a trabajar cada día. Y eso en el mejor de los casos. Los programadores ordinarios que trabajan en condiciones de oficina típicas nunca entran en este modo. O para ponerlo de manera más dramática, los programadores ordinarios que trabajan en condiciones de oficina típicas nunca entienden realmente 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 distracciones. Las distracciones son malas para muchos tipos de trabajo, pero especialmente malas para la programación, porque los programadores tienden a operar en el límite del detalle que pueden manejar.

El peligro de una distracción no depende de cuánto tiempo dure, sino de cuánto revuelve tu cerebro. Un programador puede salir de la oficina e ir a comprar un sándwich sin perder el código en su cabeza. Pero el tipo equivocado de interrupción puede borrar tu mente 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 largas sesiones. 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 que te volverás estúpido porque estás cansado. Esto varía de persona a persona. He oído hablar de personas que programan durante 36 horas seguidas, pero lo máximo que he podido manejar son unas 18, y trabajo mejor en bloques de no más de 12.

El óptimo no es el límite que puedes soportar físicamente. Hay una ventaja, así como un costo, en dividir un proyecto. A veces, cuando regresas a un problema después de un descanso, descubres 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 es el lenguaje, más corto es el programa, y más fácil es cargarlo y mantenerlo en tu cabeza.

Puedes magnificar el efecto de un lenguaje poderoso utilizando un estilo llamado programación de abajo hacia arriba, donde escribes programas en múltiples capas, las capas inferiores actuando como lenguajes de programación para las superiores. Si lo haces bien, solo tienes que mantener la capa más alta 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, así que no hay mejor manera de cargar uno en tu cabeza.

Escribe código que se pueda releer. 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, puede que no quieras hacer el código demasiado denso. Algunas partes de un programa pueden ser más fáciles de leer si distribuyes las cosas, como un libro de texto introductorio. Mientras que si estás escribiendo código para facilitar su recarga 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 no las entiendes tan bien y, más importante, no puedes tomarte libertades con ellas. Así que cuanto menor sea el número de programadores, más completamente puede mutar un proyecto. Si hay solo un programador, como a menudo ocurre al principio, puedes hacer rediseños abarcadores.

No permitas que varias personas editen la misma parte del código. Nunca entiendes el código de otras personas tan bien como el tuyo. No importa cuán a fondo lo hayas leído, solo lo has leído, no lo has escrito. Así que si una parte del código es escrita por múltiples autores, ninguno de ellos lo entiende tan bien como lo haría un solo autor.

Y, por supuesto, no puedes rediseñar de manera 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 tales cosas. Rediseñar código con varios autores es como cambiar leyes; rediseñar código que controlas solo tú 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 dale cada uno a una persona.

Comienza pequeño. Un programa se vuelve más fácil de mantener en tu cabeza a medida que te familiarizas con él. Puedes comenzar a tratar partes como cajas negras una vez que te sientes seguro de haberlas explorado completamente. Pero cuando comienzas a trabajar en un proyecto, te ves obligado a ver todo. Si comienzas con un problema demasiado grande, puede que nunca seas capaz de abarcarlo del todo. Así que si necesitas escribir un programa grande y complejo, la mejor manera de comenzar 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 sorprendente cuán a menudo los programadores logran cumplir los ocho puntos por accidente. Alguien tiene una idea para un nuevo proyecto, pero como no está oficialmente sancionado, tiene que hacerlo en horas no laborables, que resultan ser más productivas porque no hay distracciones. Impulsado por su entusiasmo por el nuevo proyecto, trabaja en él durante muchas horas seguidas. Debido a que inicialmente es solo un experimento, en lugar de un lenguaje de "producción", utiliza un mero lenguaje de "script", que de hecho es mucho más poderoso. Reescribe completamente el programa varias veces; eso no sería justificable para un proyecto oficial, pero este es un trabajo de amor y quiere que sea perfecto. Y dado que nadie más lo va a ver excepto él, omite cualquier comentario excepto el tipo nota para uno mismo. Trabaja en un grupo pequeño por fuerza, porque o 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 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; solo tiene un truco genial que quiere probar.

Aún más sorprendente es el número de proyectos oficialmente sancionados que logran hacer las ocho cosas mal. De hecho, si miras la forma en que se escribe 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. Una de las cualidades definitorias de las organizaciones desde que ha habido tal cosa 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 un ejército bien entrenado de soldados profesionales para vencer 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 es simplemente cierto que las organizaciones deseen la idea de depender del 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 una organización.

Quizás podríamos definir un nuevo tipo de organización que combinara los esfuerzos de los individuos sin requerir que sean intercambiables. Se podría argumentar que un mercado es tal forma de organización, aunque puede ser más preciso describir un mercado como un caso degenerado, como lo que obtienes por defecto cuando la organización no es posible.

Probablemente lo mejor que haremos es 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 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 tiran en direcciones opuestas. Cualquier buen programador en una gran organización estará en desacuerdo con ella, porque las organizaciones están diseñadas para prevenir 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 entienden que la forma en que se comportan los programadores está impulsada por las demandas del trabajo que realizan. No es porque sean irresponsables que trabajan en largas sesiones durante las cuales ignoran 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 antipáticos que prefieren trabajar solos, o gruñen a las personas que asoman la cabeza por la puerta para saludar. Esta aparentemente aleatoria colección de hábitos molestos tiene una única 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 permiten que los programadores individuales hagan un gran trabajo. Así que si eres una pequeña startup, este es el lugar para atacarlos. Enfréntate a los tipos 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 esto.