El miedo apropiado

Greg Poppovich es el entrador de los San Antonio Spurs (el equipo donde juega Ginóbili). Es un gran entrenador y ganó 4 títulos de la NBA. ¿Por qué lo mencionamos en este blog (además de para que nos lleguen todas esas búsquedas de Google)? Porque tiene una enfoque muy interesante sobre algo con lo que tenemos que tratar a menudo los programadores: el miedo.

A primera vista, no parece que el miedo tenga mucho que ver con lo que los programadores hacemos todos los días. Después de todo es poco probable que nuestras acciones causen daños graves a nadie. Sin embargo, todos los que hemos estado algún tiempo en esta profesión sabemos que es algo que nos acompaña todos los días. En uno de mis primeros trabajos, el miedo había llegado tan lejos que muchas de las personas en el proyecto se habían vuelto superticiosas, y no había manera de que alguien te aceptara que le alcanzaras un salero en la mano (y ni hablar de hacer una implementación un martes 13).

En el desarrollo de software, el miedo suele ser un enemigo, porque funciona como paralizante. Nos lleva a recurrir a parches en vez de realizar cambios que sabemos que son necesarios pero que nos obligarían a tocar partes del programa que nos aterrorizan. O nos hace seguir trabajando con tecnologías obsoletas (el típico "nadie fue despedido por elegir IBM").

Sin embargo, el miedo también es nuestro aliado. Cuando son las 5 de la mañana de una puesta en producción y finalmente parece que lo logramos y hacemos una última prueba antes de irnos a casa, es el miedo el que nos hace sacar fuerzas para no irnos ya a dormir. Cuando escribimos casi tantas líneas de tests de unidad cómo de código de producción también es el miedo a esas sesiones interminables de debugging el que nos ayuda a tomar ese camino, que en apariencia es más largo.

Entonces, ¿Cual es la actitud correcta frente al miedo? En mi opinión, la actitud de Poppovich: cuando un equipo gana seguido, tiende a perder perspectiva y a no tenerle miedo a los rivales. Esta actitud genera autocomplacencia y más tarde o más temprano provoca errores que causa que se pierdan partidos que se podrían haber ganado. Pero tenerle miedo a los rivales hace que uno juegue sin confianza y no se anime a tomar riesgos y que termine también perdiendo partidos que podría haber ganado. Por lo tanto, el objetivo es tener lo que Poppovich llama "Appropiate fear": suficiente miedo como para no hacer macanas por sobrar la situación, pero no suficiente como para que nos paralice.

Llegar a esta actitud lleva años tanto en basket como en desarrollo de software, pero realmente creemos que es la marca del profesional maduro de cualquiera de las dos disciplinas.

Largá el twitter!

Probablemente el consejo de usabilidad más conocido por todos los programadores es el no construir menúes con más de 7 +- 2 opciones. Seguramente nuestros lectores recuerdan el motivo de este criterio: los seres humanos (y generalmente nuestros usuarios lo son) tenemos problemas en mantener en nuestra memoria de corto plazo más de esa cantidad de elementos a la vez.

¿Qué es la memoria de corto plazo? Para explicarlo en términos nerds (y muy simplificados), es una suerte de cache donde nuestro cerebro guarda cosas que podemos acceder en forma extremadamente rápida. Cuando todo lo que necesitamos para realizar una tarea está en esta cache, el desarrollo "fluye" y se producen esos momentos en que todas las ideas que tenemos son fácilmente plasmadas en nuestro código. Es en estos momentos cuando una hora de trabajo nos rinde más que ocho horas de trabajo normal. Este fenómeno es lo que en inglés se conoce como "flow" o estar "en la zona".

Este estado de concentración total es dificil de alcanzar y es muy frágil. Cualquier interrupción hace que nuevas cosas ocupen nuestra cache y cuando queremos volver a nuestra tarea el cerebro empieza a "paginar", buscando los pedazos de información que necesita para continuar. Si estas interrupciones se producen muy a menudo, trabajamos todo el tiempo de una manera muy inferior a nuestro verdadero potencial y todas las tareas nos llevan mucho más tiempo del que deberían.

Entre las interrupciones que sufrimos normalmente, las mas comunes son las interrupciones producidas por nuestros compañeros de trabajo o, peor aún, por nuestros jefes. Estas son interrupciones dificiles de evitar. Una manera es llegar muy temprano o quedarse más tarde en el trabajo, de manera de tener unas horas de productividad por día. Otra manera es ponerse de acuerdo entre compañeros y hacer los pedidos de ayuda de una manera no intrusiva, de forma tal que la persona a la que vamos a interrumpir pueda manejar el momento en que responde a nuestro pedido (por ejemplo por mail). A riesgo de quedar como un antisocial, también es posible enchufarse los auriculares y poner "Cowboys from Hell" a todo volumen.

Otras interrupciones son mucho más fáciles de solucionar, aunque requieren más fuerza de voluntad. Me refiero a las interrupciones causadas por messengers, redes sociales, mails, etc. A menudo he visto trabajar a programadores a la vez que chatean con 3 o 4 personas y generalmente estos programadores producían código de baja calidad, con millones de bugs y mucho más lentamente que los programadores que trabajaban más concentrados. Esto no quiere decir que se deban prohibir estas herramientas (y mucho menos que los programadores deban trabajar sin conexión a internet, como he visto en algunas empresas). Quiere decir que es importante separar el tiempo en que se está programando del tiempo en que se está chateando, y que aunque parezca antiintuitivo, un programador que dedica 6 horas de su tiempo a programar y 2 a chatear va a ser mucho más productivo que si dedicara sus 8 horas a programar a la vez que chatea.

Ultimamente estoy utilizando una forma de trabajo basada en la técnica Pomodoro (aunque no siguiéndola al pie de la letra ya que esta tiene otras cosas interesantes, que espero poner en práctica en algún momento). Básicamente divido mi tiempo de trabajo en mini-sprints de 24 minutos. Durante esos mini-sprints desactivo los messengers, las notificaciones de mails y básicamente todo lo que me puede llegar a interrumpir. Trabajo totalmente concentrado durante esos 24 minutos y cuando termino me tomo unos 5 minutos para descansar. Antes de arrancar el siguiente sprint, verifico si tengo mails que contestar o si alguien intento chatear conmigo. Cada tres o cuatro sprints, me tomo un descanso un poco más largo.

De esta manera, puedo mantener períodos intensos de concentración y a la vez solo estoy incomunicado por a lo sumo 24 minutos por vez. Es interesante que en las primeras épocas en que utilicé está técnica, terminaba el día muy cansado, por la falta de costumbre de trabajar realmente a full tanto tiempo.

Nuevamente, estas ideas no apuntan a que nos comportemos como robots ni a que seamos antisociales, trabajando todo el tiempo totalmente concentrados y sin comunicación con el resto. El ambiente laboral es algo muy importante y las charlas y los chistes alrededor de la cafetera ayudan a formar ese ambiente laboral. También son muy importantes las reuniones de equipo como el Daiyly Meeting, de Scrum. Lo que buscamos es maneras de hacer que el tiempo que dedicamos a programar sea mucho productivo solo dedicándose a ..... Programar!.