SOPORTANDO UN PROGRAMA EN LA CABEZA
Agosto de 2007
Un buen programador, trabajando intensamente en su propio código, puede soportarlo en su mente de la misma manera en que un matemático soporta un problema en el que está trabajando. Los matemáticos no responden a las interrogantes trabajándolas sobre papel de la forma en que se les enseña a los niños en las escuelas. Hacen algo más: tratan de entender el espacio de un problema lo suficientemente bien que pueden caminar a su alrededor de la manera en que puedes caminar alrededor del recuerdo de la casa en que creciste. La mejor programación es así. Cargas todo el programa en tu cabeza, y lo puedes manipular a voluntad.
Esto es particularmente valioso al inicio de un proyecto, ya que inicialmente lo más importante es poder cambiar lo que estás haciendo. No sólo 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 se está explorando. Así que es sólo cuando tienes el código en tu cabeza que realmente entiendes el problema.
No es fácil poner un programa en tu cabeza. Si dejas un proyecto por unos meses, puede tomar días para realmente entenderlo de nuevo cuando regresas al mismo. Incluso cuando se está trabajando activamente en un programa puede tomar media hora cargarlo en tu 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 a este modo. O para decirlo de forma más dramática: los programadores ordinarios que trabajan en condiciones típicas de oficina nunca entienden realmente los problemas que están resolviendo.
Incluso los mejores programadores no siempre tienen cargado en la cabeza todo el programa en el que están trabajando. Pero hay cosas que puedes hacer para ayudar:
1. Evita las distracciones. Las distracciones son malas para muchos tipos de trabajo, pero son especialmente malas 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 cuanto dura, sino de cuánto revuelve tu cerebro. Un programador puede salir de la oficina e ir por un sándwich sin perder el código en la cabeza. Pero el tipo equivocado de interrupción puede borrar tu cerebro en 30 segundos.
Aunque parezca mentira, 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 duro en algo.
2. Trabaja en periodos 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á, por supuesto, un punto en el que te vuelves estúpido porque estás cansado. Esto varía de persona a persona. He escuchado de personas que hackean durante 36 horas seguidas, pero lo más que he sido capaz de manejar son 18, y funciono mejor en periodos de no más de 12.
Lo óptimo no es el límite que físicamente puedes soportar. Hay una ventaja, así como un costo, de romper un proyecto. A veces, cuando vuelves a un problema después de un descanso, encuentras que tu inconsciente te tiene una respuesta esperando.
3. Utiliza lenguajes concisos. 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 utilizando para escribirlos. Cuanto más conciso el lenguaje, más corto el programa, y más fácil es cargarlo y soportarlo en tu cabeza. Se puede ampliar el efecto de un lenguaje potente mediante el uso de un estilo de programación denominado bottom-up, en el que escribes programas en múltiples capas, en donde las inferiores actúan como lenguajes de programación para las de arriba. Si haces esto bien, sólo necesitas mantener la capa superior en tu cabeza.
4. Continua reescribiendo el programa. Reescribir un programa a menudo te genera un diseño más limpio. Pero tendría ventajas incluso si no fuera así: hay que entender un programa completamente para reescribirlo, así que no hay mejor manera de cargar uno en la cabeza.
5. Escribe código releíble. Todos los programadores saben que es bueno escribir código legible. Pero tú mismo eres el lector más importante. Sobre todo al principio; un prototipo es una conversación con uno mismo. Y cuando se escribe para sí mismo se tienen prioridades diferentes. Si estás escribiendo para otras personas, puedes no querer hacer que el código sea demasiado denso. Algunas partes de un programa pueden ser más fáciles de leer si separas las cosas, como un libro introductorio. Mientras que si estás escribiendo código para hacerlo más fácil de recargar en tu cabeza, puede ser mejor buscar la brevedad.
6. Trabaja en grupos pequeños. Cuando manipulas un programa en tu cabeza, tu visión tiende a detenerse a las orillas del código que posees. Otras partes no las comprendes tan bien, y más importante aún, 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 un solo programador, como ocurre a menudo en un primer momento, puedes hacer rediseños que lo abarquen todo.
7. No hagas que varias personas editen el mismo trozo de código. Nunca entiendes tan bien el código de otras personas, como el tuyo propio. No importa lo bien que lo hayas leído, sólo lo has leído, no escrito. Así que si una parte del 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 con seguridad algo en lo que otras personas están trabajando. No es sólo que tendrías que pedir permiso. Ni siquiera te permitirías pensar en tales cosas; rediseñar código con varios autores es como cambiar las leyes; rediseñar código que sólo tú controlas es como ver la imagen oculta en una ilusión óptica.
Si quieres poner a varias personas a trabajar en un proyecto, divídelo en componentes y dale cada parte a una sola persona.
8. Comienza con algo pequeño. Se vuelve más fácil soportar un programa en la cabeza a medida que te familiarizas con él. Puedes comenzar a tratar las piezas como cajas negras una vez que te sientas seguro que las has explorado completamente. Pero cuando empiezas 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. Así que si necesitas escribir un programa grande y complejo, puede que la mejor manera de comenzar no sea escribiendo una especificación para el mismo, sino escribir un prototipo que resuelve un subconjunto del problema. Cualesquiera que sean las ventajas de la planificación, a menudo son superadas por las ventajas de ser capaz de soportar un programa en tu cabeza.
Es sorprendente cuan a menudo los programadores consiguen dar con los ocho puntos por accidente. Alguien tiene una idea para un nuevo proyecto, pero debido a que no está oficialmente aprobado, tiene que hacerlo en horas inhábiles —que resultan ser más productivas porque no hay distracciones. Llevado por su entusiasmo por el nuevo proyecto trabaja en el mismo durante muchas horas seguidas. Debido a que en un principio es sólo un experimento, en lugar de usar un lenguaje de "producción", utiliza un simple lenguaje de "scripting" — que en realidad es mucho más potente. Reescribe por completo el programa varias veces; eso no sería justificable para un proyecto oficial, pero este es un trabajo por amor al arte y quiere que sea perfecto. Y como nadie lo va a ver, excepto por él, omite cualquier comentario, salvo los del tipo que son notas para uno mismo. Trabaja en un pequeño grupo forzosamente, porque no le ha dicho a nadie sobre la idea todavía, o porque 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, ya que cambia demasiado rápido para que eso sea posible. Y el proyecto empieza pequeño, porque la idea es pequeña al principio; es sólo que tiene un pequeño “hack” que quiere probar.
Aún más sorprendente es el número de proyectos oficialmente aprobados que se las ingenian para hacer mal las ocho cosas. De hecho, si nos fijamos en la forma en que se escribe software en la mayoría de las organizaciones, es casi como si estuvieran tratando deliberadamente de hacer mal las cosas. En cierto sentido, lo están. Una de las cualidades definitorias de las organizaciones desde que existen ha sido tratar a las personas como piezas intercambiables. Esto funciona bien para tareas más paralelizables, como combatir en las guerras. Durante la mayor parte de la historia se puede dar por descontado que un ejército bien entrenado de soldados profesionales puede vencer a un ejército de guerreros individuales, por muy valientes que sean. Pero tener ideas no es muy paralelizable. Y eso es lo que son los programas: ideas.
No es cierto que a las organizaciones simplemente no les guste la idea de depender de la genialidad individual, eso es una tautología. Es parte de lo que define a una organización no hacerlo. Al menos, en nuestro concepto actual de una organización.
Tal vez podríamos definir un nuevo tipo de organización que combina los esfuerzos de individuos sin que tengan que ser intercambiables. Podría decirse que un mercado es una forma de organización, aunque puede que sea más exacto 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 podamos hacer sea algún tipo de hack, como hacer que las piezas de programación de una organización trabajen de manera diferente a las demás. Tal vez la solución óptima es que las grandes compañías ni siquiera deberían tratar de desarrollar ideas en casa, sino simplemente comprarlas. Pero independientemente de cual resulte ser la solución, el primer paso es darse cuenta de que hay un problema. Hay una contradicción en la frase misma "empresa de software." Las dos palabras están tirando en direcciones opuestas. Cualquier buen programador en una gran organización estará en conflicto con ello, ya que las organizaciones están diseñadas para evitar lo que los programadores tratan de conseguir.
Los buenos programadores consiguen hacer mucho de todos modos. Pero a menudo se requiere prácticamente un acto de rebelión contra las organizaciones que los emplean. Quizás ayudará si más gente entendiera que la forma en que se comportan los programadores es impulsada por las exigencias del trabajo que realizan. No es porque sean irresponsables que trabajan en largos periodos de embriaguez durante los cuales botan todas las demás obligaciones, se sumergen directamente en la programación, en lugar de primero escribir especificaciones, 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 su cabeza en la puerta para saludar. Esta colección aparentemente aleatoria de hábitos desagradables tiene una sola explicación: la capacidad de soportar un programa en la cabeza.
Sea o no que entender esto pueda ayudar a las grandes organizaciones, sin duda puede ayudar a sus competidores. El punto más débil en las grandes empresas es que no dejan que los programadores individuales hagan trabajo grandioso. Así que si eres una pequeña startup, este es el lugar para atacarlos. Aborda el tipo de problemas que deben ser resueltos 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 borradores de esto.
Traducido de Holding a Program in One's Head por Paul Graham.
Traducción: Armando Alvarez