(Spanish translation of «Holding a program in one's head» of Paul Graham)
Agosto 2007
Un buen programador, que trabaja intensivamente en su propio código, puede mantener en su cabeza todo un programa de la misma forma que un matemático puede mantener en la suya el problema en el que trabaja. Los matemáticos no encuentran soluciones trabajando sobre un papel, como se enseña a hacerlo a los niños en el colegio. Lo que hacen es tener todo el problema en su cabeza: tratan de comprender el espacio del problema lo suficientemente bien hasta el punto de ser capaces de recorrer todos sus detalles de las misma forma en la que tu puedes recorrer con la memoria todas las habitaciones de la casa donde te criaste. Cuando se programa de la forma correcta sucede lo mismo. Eres capaz de mantener todo el programa en tu cabeza, donde puedes manipularlo a tu antojo.
Esto es particularmente valioso cuando se comienza un proyecto, porque es entonces cuando es más importante ser capaz de cambiar lo que estás haciendo. No solo para resolver el problema de una forma diferente sino incluso para cambiar el propio problema que tratas de resolver.
Un programa no es más que tu comprensión del problema que estás explorando. Cuando todo el código de tu programa está en tu cabeza es cuando realmente comprendes el problema.
No es sencillo mantener un programa en tu mente. Si dejas un proyecto durante unos meses puede llevarte días comprenderlo de nuevo si quieres volver a trabajar en él. Incluso cuando estás trabajando de forma activa en el programa puedes necesitar media hora cargar en tu mente todo lo necesario para ponerte a trabajar en él cuando arranca cada jornada. Y eso en el mejor caso. Los programadores ordinarios trabajando en las condiciones de oficina típicas nunca llegan a entrar en este modo de trabajo. O, poniéndonos dramáticos, los programadores ordinarios trabajando en la oficina típica nunca comprenden realmente el problema que están tratando de resolver.
Incluso los mejores programadores no siempre tienen todo el programa en el que están trabajando cargado en su mente. Pero hay cosas que les pueden ayudar a hacerlo..
- Evitar distracciones.Las distracciones son malas para muchos tipos de trabajos, pero son especialmente nefastas en programación, porque los programadores tienden a operar en el límite de detalle que sus mentes pueden manejarEl peligro que representa una distracción no depende de lo larga que sea, sino de cuanto sea capaz de marear a tu mente. Un programador puede salir de la oficina e ir a por un sandwich sin perder el código que tiene en su mente. Pero otras distracciones pueden vaciar tu mente en 30 segundos.Por extraño que parezca, las distracciones planificadas pueden ser aún peores que las que te sorprenden. Si tienes una reunión en una hora es posible que ni te plantees comenzar a trabajar en serio en el programa.
- Trabajar durante periodos prolongados. Como comenzar a trabajar en un programa tiene un coste fijo, es más eficiente trabajar durante una serie de sesiones largas que que hacerlo en muchas sesiones cortas. Por supuesto siempre corres el riesgo de que comenzar a hacer cosas estúpidas debido al cansancio. Esto varía de unas personas a otras. He escuchado decir que hay gente que es capaz de hackear durante 36 horas seguidas. Pero lo máximo que y he sido capaz de trabajar en un mismo programa es entorno a 18 y trabajo mejor en sesiones de no más de 12 horas.El punto óptimo no está en el máximo periodo de tiempo que puedas aguantar trabajando. Existen ventajas y desventajas en romper un proyecto en distintas sesiones. En ocasiones, cuando vuelves a un problema después de haber descansado, tu mente subconsciente puede haber encontrado una respuesta a un problema sin que te des cuenta.
- Usa lenguajes sucintos. Lenguajes de programación más poderosos te permiten crear programas más cortos. Y los programadores parecen pensar sobre un programa empleando el lenguaje de programación que están usando para escribirlo. Cuanto más sucinto sea el lenguaje de programación, más corto será el programa, y más sencillo será cargarlo y mantenerlo en tu mente. Puedes magnificar este efecto si empleas un estilo de programación llamado «bottom-up», donde escribes los programas creando múltiples capas donde las de abajo actúan como lenguajes de programación para las que se encuentran encima de ellas. Si lo haces bien, solo tendrás que mantener en tu cabeza la capa superior del programa.
- Reescribe tu programa a menudo. Reescribir un programa a menudo nos lleva a un diseño más limpio. Pero incluso si no lo hace nos seguirá ofreciendo ventajas: tienes que comprender un programa completamente para poder reescribirlo, así que no hay mejor manera de cargar un programa en tu mente que reescribirlo.
- Escribe código re-legible. Todos los programadores saben que es bueno escribir código legible. Pero el lector más importante de tu código eres tu mismo. Especialmente al principio: un prototipo es una conversación contigo mismo. Y cuando escribes para tí mismo puede que tengas otras prioridades. Si escribes para otras personas no querrás hacer el código muy denso. Algunas partes de un programa son más fáciles de leer si haces todos los pasos evidentes, como en un libro de texto. Mientras que si escribes el código pensando en hacer sencillo cargarlo en tu mente, es posible que lo mejor sea hacerlo breve.
- Trabaja en equipos pequeños. Cuando manipulas el programa en tu mente, tu visión tiende a parar en el límite de tu propio código. No comprendes las partes creadas por otros tan bien como las tuyas, y lo que es más importante, no puedes tomarte libertades con ellas. Así que cuanto más pequeño el número de programadores, más sencillo será mutar un proyecto. Si solo hay un programador, como suele ocurrir al principio, podrás hacer rediseños generales sin problemas.
- Don't have multiple people editing the same piece of code. You never understand other people's code as well as your own. No matter how thoroughly you've read it, you've only read it, not written it. So if a piece of code is written by multiple authors, none of them understand it as well as a single author would.And of course you can't safely redesign something other people are working on. It's not just that you'd have to ask permission. You don't even let yourself think of such things. Redesigning code with several authors is like changing laws; redesigning code you alone control is like seeing the other interpretation of an ambiguous image.If you want to put several people to work on a project, divide it into components and give each to one person.
- Comienza con algo pequeño. Es más sencillo mantener un programa en tu cabeza cuanto más te familiarices con él. Puedes comenzar a tratar las distintas partes de un programa como cajas negras una vez que consideres que las has explorado completamente. Pero cuando comienzas a trabajar en un proyecto, estarás forzado a verlo todo. Si comienzas con un problema demasiado grande puede que nunca seas capaz de comprenderlo completamente. Así que si necesitas escribir un programa grande y complejo, la mejor manera de comenzar no será escribir una especificación del problema, sino escribir un prototipo que resuelva un subconjunto del problema. Cualesquiera que sean las ventajas que hacer una planificación previa, son rápidamente superadas por las ventajas de ser capaz de mantener el programa en tu mente.
Es sorprendente como de a menudo los programadores son capaces de seguir estos ocho puntos por accidente. Alguien tiene una idea para un nuevo proyecto, pero debido a que no ha sido autorizado oficialmente, comienza a trabajar en él en sus horas libres (que resultan ser más productivas debido a que no hay distracciones). Guiados por su entusiasmo por el nuevo proyecto, trabajan numerosas horas seguidas en él. Como inicialmente es solo un experimento, en lugar de emplear un lenguaje de «producción» suelen emplear un lenguaje de «scripting», que es de hecho más poderoso. Es normal que se reescriba el programa en numerosas ocasiones, lo que no sería justificable en un proyecto oficial, pero como se trata de un proyecto personal el programador nunca pretende que el código sea perfecto. Debido a que nadie va a leer el código a excepción de su creador, se omiten los comentarios excepto por una notas con recordatorios que solo entiende el autor. El programador trabajará con un pequeño equipo forzosamente, puesto que solo ha hablado del programa con unas cuantas personas o el proyecto es tan poco prometedor que nadie más está autorizado a trabajar en él. Incluso si existe un equipo, no será posible que distintas personas trabajen en el mismo código porque cambiará demasiado rápido para que sea posible. Por último, el proyecto arrancará pequeño porque la idea será pequeña al principio, el programador solo quiere probar algún hack curioso para resolver el problema.
Incluso más sorprendente es el número de proyectos autorizados oficialmente que consiguen equivocarse en los ocho puntos. Si observas la forma en al que el software se escribe en la mayoría de las organizaciones, es casi como si trataran de forma deliberada de hacer las cosas mal. Y en cierto sentido es lo que desean. Una de las cualidades que definen a las organizaciones desde que existen es la de tratar a los individuos como piezas intercambiables. Lo que no es una mala idea para la mayoría de las tareas paralelizables, como por ejemplo combatir en guerras. Durante la mayoría de la historia, un ejercito profesional bien abastecido podía contar con la victoria frete a un ejército de guerreros individuales, sin importar lo valerosos que estos fuesen. Pero tener ideas no es una tarea paralelizable. Y los programas no son más que ideas.
No solamente es cierto que las organizaciones aborrecen la idea de depender del genio de unos pocos individuos, es de hecho una tautología. Es parte de la definición de organización no depender de ellos. O al menos de nuestro actual concepto de organización.
Puede que podamos definir un nuevo tipo de organización que combine los esfuerces de unos cuantos individuos sin requerir que sean intercambiables. Se puede argumentar que un mercado es ese tipo de organización, aunque sería más preciso definir un mercado como un caso degenerado, puesto que es lo que ocurre cuando establecer una organización no es posible
Probablemente lo mejor que podamos hacer es emplear una especie de hack, como por ejemplo considerar que la partes de la organización relacionadas con programar trabajen de forma diferente al resto. Quizá la solución óptima sea que las grandes empresas ni siquiera traten de desarrollar ideas internamente, sino que directamente las compren. Sea cual sea la solución, el primer paso es reconocer que hay un problema. Hay una contradicción en la propia expresión «empresa de software». Las palabras apuntan en direcciones opuestas. Cualquier buen programador en una empresa grande se encontrará incómodo en ella, debido a que las organizaciones son diseñadas para prevenir los programadores anhelan.
Los programadores realmente buenos consiguen sacar trabajo adelante de todas formas. Pero a menudo requiere prácticamente rebelarse contra las organizaciones que les emplean. Quizá ayudaría si la gente comprendiese que la manera en la que los programadores se comportan es consecuencia de las demandas de su trabajo. Que trabajen durante largos periodos de tiempo ignorando todas las demás obligaciones no es consecuencia de que sean unos irresponsables, lanzándose a programa antes de escribir una especificación, y reescribir el código que ya funciona. Que trabajen solos o que gruñan a la gente que se pasa por su puerta para decir hola no se debe a que tengan personalidades asociales. Esta colección de hábitos tan molestos tiene una explicación: la capacidad de mantener en su mente un programa.
Comprender todo esto pueda ayudar o no a las grandes organizaciones, pero lo que esta claro es puede ayudar a sus mayores competidores: las startups. El punto débil de las grandes empresas es que no pueden permitir a los programadores individuales hacer lo que mejor saben hacer. Así que si eres una startup pequeña, debes aprovechar esta situación. Trabaja en la clase de problemas que solo pueden ser solucionados dentro de un única gran mente.
Gracias a Sam Altman, David Greenspan, Aaron Iba, Jessica Livingston, Robert Morris, Peter Norvig, Lisa Randall, Emmett Shear, Sergei Tsarev, and Stephen Wolfram por leer borradores de este ensayo.