La zona del programador

Soy de esa clase de personas que les gusta mucho perder invertir tiempo buscaaando y probaaaando herramientas, o peor aún, haciéndose las propias. Y no es raro que se me valla más tiempo y esfuerzo en esa búsqueda o construcción, del que llevaría resolver el problema particular para cuya resolución quiero esa herramienta. Sin ir más lejos, hace muy poquito les conté sobre un error tonto que me llevó a programar dos nuevas funciones en ZinjaI, y que encima al final ni las necesitaba. Este tipo de cosas (el desviarme para buscar, hacer y/o automatizar herramientas y procesos) me ocurre todo el tiempo, y creo que es común en muchísimos programadores. El problema es que cuando uno desarrolla estas herramientas no-indispensables uno tiende a sentirse algo culpable por no trabajar directamente en la solución del problema, sino posponerla por una deformación profesional propia. Si esto también te pasa a vos, mi valioso lector, este post viene a darte algunas excusas para que dejes de sentirte culpable y valores ese trabajo.

xkcd suele contar grandes verdades en pequeñas viñetas.

Primero una aclaración: en lo que sigue del texto, tomen como intercambiables las acciones de "buscar" una herramienta ideal para una tarea, o "desarrollarla". Tengo tendencia a hablar en términos de lo segundo, porque en general termino integrando las cosas que me resultan útiles en ZinjaI, y de ahí que requieran desarrollo. Pero lo que voy a decir habla del tiempo invertido para tener la herramienta, más allá de en qué se invirtió particularmente. Aclarado esto, por un ratito breve, voy a empezar tocando alguna cuestión psicológica ([[disclamer]] materia sobre la cual no se nada).

¿Oyeron hablar de "la zona" o "the flow" (como se le dice en inglés)? Es ese estado mental difícil de alcanzar en el que uno se siente completamente inmerso y concentrado en una actividad, cuando uno la disfruta por completo porque los astros se alinean y las cosas le salen/fluyen con naturalidad, cuando perdemos la noción del tiempo y  parece que tenemos el 100% de nuestra maquinaria funcionando aceitádamente al servicio de ese objetivo... Eso mismo. La idea se aplica en varios campos, algunos encuentran ese placentero e hiper-productivo estado estudiando o aprendiendo, otros resolviendo problemas, otros tocando un instrumento, o haciendo algún deporte (es un concepto del que se habla mucho en psicología deportiva), etc.

Ojo, esto no quiere decir que nos convirtamos en Súperman (de hecho, en alguna definición se pone como requisito que el nivel de desafío de la actividad esté en perfecto balance con la "capacidad" de la persona). Pero sí que logremos exprimir nuestro potencial al menos un poco más que lo normal, y que lo disfrutemos. Es imprescindible entonces que a uno le guste mucho lo que hace. Y la programación tiene todos esos ingredientes, empezando con que puede ser una actividad muy desafiante que requiere la máxima concentración. Entonces, no hay nada más productivo para un programador que entrar en esa zona. Y para resolver algunos problemas particularmente difíciles, puede hasta ser un requisito. El verdadero problema es que es muy muy difícil llegar, o a veces siquiera acercarse a ese estado. No es que uno se sienta a programar y a los 10 minutos está mágicamente operando al 110%. Lleva tiempo, esfuerzo, dedicación, y otros factores externos (no puedo dejar de recomendar este genial artículo acerca de lo que conlleva la puesta en marcha del programador). Lo importante, es que si uno finalmente llega a ese punto, hay que aprovecharlo, evitar como sea que se corte, hacer que las cosas fluyan.

Y es ahí, cuando estamos en medio de un razonamiento muy complejo, cuando logramos acomodar todos esos detalles difíciles en caché, cuando las piezas encajan perfectamente en el rompecabezas global, y se empiezan a hacer más evidentes los detalles importantes, cuando vemos los 0s y los 1s verdes cayendo en tiras... Es ahí, cuando el no tener la herramienta adecuada para alguna tarea, aunque sea menor o secundaria, nos puede obligar a cambiar de tema o contexto, a desviarnos del problema, a interrumpir por un instante ese flujo. Y eso puede ser terrible para la productividad, esa pausa puede romper la magia y costar muy caro, considerando lo fácil que es salir y lo difícil que es entrar en "la zona". Hace unos días leí un interesante artículo sobre la diferencia que le hacía a un programador que un proceso de compilación lleve un segundo o tres. "¿Cuál es tu límite de tolerancia?" preguntaba el autor en el título. Traduzco a continuación su genial resumen de los efectos que tiene sobre la cabeza del programador la demora en la compilación:

• Hasta 2 segundos: el programador permanece en "la zona", la productividad se mantiene alta.
• De 2 a 8 segundos: "la zona" se rompe, se empieza a percibir como una demora tediosa.
• De 8 a 30 segundos: la atención se desvía, a otras partes del código, a un email, etc. Uno empieza a hacer multitasking y la productividad se desploma.
• Más de 30 segundo: cada vez que la compilación empieza, el programador empieza otra tarea empieza a la par. Tal vez hasta se levante de la silla, tome algo, o empiece una conversación. Requiere un reinicio completo del cerebro ("full brain reboot", jeje) para volver a codificar.
• Más de 5 minutos: el programador golpea su cabeza contra el escritorio y comienza a considerar diversas formas de suicidio.

Otra genialidad de xkcd.

 
Tal vez sea un poco exagerado, pero no deja de ser muy representativo, y además extrapolable a cualquier otra tarea que se pueda meter en medio de nuestro proceso de desarrollo (por ejemplo, el profilling, o el refactory).

Es por esto que muchas veces, cuando en medio de una de estas sesiones, tan largas y complicadas, me topo con una tarea que de alguna forma me hace salirme de la linea de pensamiento que traía, prefiero directamente abortar el proceso mental (que igual ya se dañó :P) y automatizar la tarea, cueste lo que cueste. La idea es que esa detención forzosa (el "full brain reboot") ocurra esa única vez, y no cada vez que me tope con eso. Que luego de recuperado el ritmo, esa tarea secundaria ya no sea suficientemente tediosa como para potencialmente aniquilar otra vez mi productividad. Porque aunque parezca que invierto más tiempo en la solución a un problema secundario de lo que debería invertir para solucionar el problema verdadero, aquí hay una conflicto de prioridades. Lo que estoy priorizando es cuidar ese delicado estado de envión, y no cortar, una vez que con mucho trabajo y suerte lo logre, ese ritmo y esa concentración tan difíciles de alcanzar.

Así de valiosos son esos momentos, porque la productividad suele aumentar un orden de magnitud, no por una constante, y por esto creo que a la larga es una inversión y no una pérdida de tiempo. Sin embargo, tengo reconocer que me gusta desviar mi [por momentos demasiado frágil] atención, y que como esas herramientas secundarias suelen ser parte de ZinjaI, tengo un incentivo de peso adicional para hacer la parada. Es decir que, volviendo a la pregunta del otro artículo, mi límite de tolerancia suele estar bastante bajo. ¿Y el tuyo?