Tener un Programa en la Cabeza

Agosto de 2007

Un buen programador que trabaja intensamente en su propio código puede tenerlo en mente del mismo modo que un matemático tiene 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 suficiente como para poder recorrerlo como se recorre la memoria 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.

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. Por lo tanto, solo cuando tienes tu código en tu cabeza realmente entiendes el problema.

No es fácil meter un programa en tu cabeza. Si dejas un proyecto por unos meses, puede llevar días entenderlo realmente de nuevo cuando regresas a él. 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 ordinarios que trabajan en condiciones de oficina típicas nunca entran en este modo. O, para decirlo de forma 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:

1. 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 cuánto dure, sino de cuánto revuelve tu cerebro. Un programador puede salir de la oficina e ir a buscar un sándwich sin perder el código en su cabeza. Pero el tipo equivocado de interrupción 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 empiezas a trabajar en algo difícil.

2. Trabaja en largos periodos. Dado que hay un costo fijo cada vez que empiezas a trabajar en un programa, es más eficiente trabajar en pocas sesiones largas que en muchas cortas. Por supuesto, llegará un punto en el que te vuelvas estúpido porque estás cansado. Esto varía de persona a persona. He oído hablar de gente que programa durante 36 horas seguidas, pero lo máximo que he podido hacer es unas 18, y yo 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 además de un costo al dividir un proyecto. A veces, cuando vuelves a un problema después de un descanso, encuentras que tu mente subconsciente te ha dejado una respuesta esperando.

3. Usa lenguajes concisos. Los lenguajes de programación más potentes hacen los programas 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 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 potente usando un estilo llamado programación de abajo hacia arriba, donde escribes programas en múltiples capas, las inferiores actuando como lenguajes de programación para las superiores. Si haces esto bien, solo tienes que mantener la capa superior en tu cabeza.

4. Sigue reescribiendo tu programa. Reescribir un programa a menudo produce un diseño más limpio. Pero tendría ventajas incluso si no las tuviera: tienes que entender un programa completamente para reescribirlo, por lo que no hay mejor manera de cargarlo en tu cabeza.

5. Escribe código legible. Todos los programadores saben que es bueno escribir código legible. Pero tú eres el lector más importante. Especialmente al principio; un prototipo es una conversación contigo mismo. Y al escribir para ti mismo tienes prioridades diferentes. Si escribes 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 extiendes las cosas, como un libro de texto introductorio. Mientras que si estás escribiendo código para que sea fácil de recargar en tu cabeza, puede ser mejor optar por la brevedad.

6. 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 lo que es más importante, no puedes tomarte libertades con ellas. Por lo tanto, cuanto menor sea el número de programadores, más completamente podrá mutar un proyecto. Si solo hay un programador, como suele ocurrir al principio, puedes hacer rediseños que lo abarquen todo.

7. No hagas que varias personas editen el mismo trozo de 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. Por lo tanto, 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 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 tú solo es como ver la otra interpretación de una imagen ambigua.

Si quieres que varias personas trabajen en un proyecto, divídelo en componentes y dale cada uno a una persona.

8. Empieza pequeño. Un programa se vuelve más fácil de tener 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 haberlas explorado completamente. 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. 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. Sean cuales sean las ventajas de la planificación, a menudo se ven superadas por las ventajas de poder mantener un programa en tu cabeza.

Es sorprendente cuántas veces los programadores logran acertar los ocho puntos por accidente. Alguien tiene una idea para un nuevo proyecto, pero como no está oficialmente sancionado, tiene que hacerlo en horas extras, 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. 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 es un trabajo de amor y quiere que sea perfecto. Y como nadie más lo va a ver que él, omite cualquier comentario excepto los de tipo nota para sí mismo. Trabaja en un grupo pequeño por necesidad, porque o bien aún no le ha contado la idea a nadie más, 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 varias personas editando el mismo código, porque cambia demasiado rápido para que eso sea posible. Y el proyecto empieza pequeño porque la idea es pequeña al principio; solo tiene un truco genial que quiere probar.

Son aún más sorprendentes la cantidad de proyectos oficialmente sancionados que logran hacer todas 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 estuvieran tratando deliberadamente de hacer las cosas 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 paralelizadas, como luchar en guerras. Para la mayor parte de la historia, un ejército bien entrenado de soldados profesionales podía vencer 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 es meramente cierto que las organizaciones odien 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 organización.

Quizás podríamos definir un nuevo tipo de organización que combinara los esfuerzos de los individuos sin requerir que fueran intercambiables. Podría decirse que un mercado es una forma de organización así, 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 podemos hacer es algún tipo de hack, 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 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 tiran en direcciones opuestas. Cualquier buen programador en una organización grande va a 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 gente entiende que la forma en que se comportan los programadores está impulsada por las demandas del trabajo que hacen. No es porque sean irresponsables que trabajan en largos atracones durante los cuales descuidan 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 colección aparentemente aleatoria de hábitos molestos tiene una sola explicación: el poder de tener un programa en la cabeza.

Si comprender esto puede 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 atacarlas. Asume el 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 esto.