Flujo, la psicología de la experiencia óptima

Tras décadas dedicado a estudiar los estados en los que las personas alcanzan su máximo potencial, Mihaly Csikszentmihalyi publicó en el año 1990 su libro, Flow: The Psychology of Optimal Experience. El libro se basaba en cientos de entrevistas y decenas de estudios que indican que las personas son más felices cuando alcanzan un estado de alta concentración que Csikszentmihalyi llamó Flow -flujo o fluir-. Si alguna vez habéis estado enfrascados en una tarea tan sumamente interesante que habéis perdido la noción del tiempo y habéis "vuelto a la realidad" horas después, satisfechos pero cansados y hambrientos, seguramente os suene esta sensación.

Pero para entender mejor qué es un estado de flujo, quizá sea conveniente analizar antes el estado justamente opuesto: lo que Csikszentmihalyi llama entropía psíquica. Un estado de entropía psíquica es aquel en el que no hay ningún orden en la conciencia, en el que los pensamientos aparecen y desaparecen caprichosamente sin que podamos controlarlos. Es lo que ocurre cuando te vas a la cama dándole vueltas a algo que te preocupa. Lo mejor sería olvidarte del asunto para poder dormir tranquilo y mañana, con la cabeza más despejada, ver qué se puede hacer para solucionarlo. Pero es inútil, porque cuando te encuentras muy preocupado, los pensamientos tienen vida propia y no podemos controlarlos.

La entropía psíquica es un estado muy desagradable que suele estar relacionado con otros problemas como la inseguridad, la depresión o la ansiedad y que, de repetirse con frecuencia, puede hacer muy infelices a las personas.

El opuesto a la entropía psíquica es el estado de flujo. Cuando la mente fluye, uno se siente completamente atento y en control de sí mismo, despreocupado y con una agradable sensación de estar haciendo lo correcto. Todo toma sentido y los problemas que nos encontramos parecen apasionantes desafíos a los que nos enfrentamos con gusto, no amenazas hacia nuestro bienestar o seguridad personal.

El estado de flujo ha sido descrito, esencialmente de la misma forma, por personas dedicadas a empresas completamente distintas. Cuando se les pregunta a cirujanos, corredores de fondo, marineros, escritores, escaladores, jugadores de ajedrez o trabajadores de una cadena de montaje cuáles son las condiciones en las que se sienten más felices y realizados, todos describen un estado similar al que Csikszentmihalyi denomina flujo. La actividad en concreto parece no tener demasiada importancia. Algunas personas pueden alcanzar un estado de flujo navegando en solitario alrededor del mundo y otras negociando un contrato o en una reunión social. La actividad que le permite a cada uno alcanzar un estado de flujo depende de su personalidad: lo que a un jugador de ajedrez le parece emocionante puede parecerle mortalmente aburrido a un atleta profesional. Y viceversa.

Aún así, Csikszentmihalyi identificó algunas de las condiciones o características del estado de flujo.

  • La tarea debe tener unos objetivos claros y la persona que la realiza debe conocerlos perfectamente y tener muy claro que se está acercando a ellos. Cuando te encuentras en un estado de flujo tienes la sensación de que estás haciendo las cosas bien y que conseguirás lo que te propones.

  • La tarea a realizar debe suponer un desafío para la persona que la realiza. Es difícil entrar en un estado de flujo sentado en el sofá tratando de respirar. Eso es tan fácil que resulta aburrido.

  • Al mismo tiempo, debe ser una tarea al alcance del que la realiza. Si la tarea es demasiado difícil, la persona tendrá dudas acerca de su capacidad, sentirá ansiedad y esto hará imposible que se alcance un estado de flujo.

El estado de flujo es por su propia naturaleza, algo inestable que requiere un ajuste constante para alcanzar el equilibrio perfecto entre demasiado fácil y demasiado difícil. Cuando empezamos a jugar al tenis, el darle a la bola y pasarla por encima de la red puede parecer todo un desafío. Pero al cabo de poco tiempo, lo que antes nos parecía un desafío se vuelve una tarea trivial y debemos ensayar nuevos golpes o enfrentarnos a rivales más difíciles para no aburrirnos. Buscar el estado de flujo conlleva inevitablemente la mejora de nuestras habilidades y la búsqueda de nuevos desafíos.

Lo más interesante del estado de flujo es el papel que desempeña en la capacidad de muchas personas para ser felices. Diversos estudios parecen indicar que algunos factores como el dinero tienen, en realidad, un papel relativo en nuestra felicidad. El dinero, por ejemplo, es importante cuando tenemos poco -igual que la comida es muy importante cuando te mueres de hambre-, pero cuanto más dinero tenemos menos influye éste en nuestra felicidad. Para los niveles de poder adquisitivo de los que disfrutamos en los países desarrollados, existen factores mucho más importantes que el dinero que determinan nuestra felicidad. En cambio, disfrutar de estados de flujo hace que una persona se sienta más segura de sí misma, menos ansiosa y más feliz.

Tras tantos estudios y discusiones filosóficas, el secreto de la felicidad no parece tan secreto: se trata, tan sólo, de disfrutar con lo que se hace.

100% de cobertura del código

Las métricas que se obtienen en un entorno de integración continua son muy útiles para detectar posibles errores en zonas del código. Sin embargo, el que tu código obtenga una buena puntuación en cualquier métrica no garantiza absolutamente nada.

Por ejemplo, la métrica más usada, por su utilidad, es el tanto por ciento de cobertura del código: el tanto por ciento de código que se ejecuta al lanzar los test. El problema con esta métrica es que se puede falsear trivialmente como demuestra el siguiente ejemplo:

class Sumador
  def self.suma(op1, op2)
    return op1 - op2 #  Estamos restando, no sumando!
  end
end

class TestSuma < Test::Unit::TestCase
  def test_suma
    Sumador.suma 0, 2
    assert(true)
  end
end

Esta es una implementación rota de una clase para sumar - que, en realidad, resta- y que sin embargo tiene un 100% de cobertura de código.

Incluso cuando no hay ningún ánimo de hacer trampas, un 100% de cobertura del código no garantiza que la implementación sea correcta. Para cualquier código no trivial es imposible conseguir un 100% de cobertura de las bifurcaciones del código, o probar una función para todos los valores posibles de entrada.

Entonces, ¿qué sentido tiene esforzarnos por conseguir una alta cobertura del código? Muy sencillo: una baja cobertura indica que el código es defectuoso o, mejor dicho, está incompleto. Si tus test cubren un 0% del código -es decir, no hay tests- entonces tienes un problema. Si tienes una cobertura alta, es muy probable que tu código sea de alta calidad y esté poco acoplado.

Software con opinión

En el desarrollo de software tener muchas opciones entre las que elegir puede ser algo positivo, sin embargo a veces tener demasiadas opciones también puede ser un problema.

Pensemos, por ejemplo, en los frameworks de javascript. Existen docenas de ellos: jQuery, Prototype, Yahoo UI, Dojo, ExtJs, GWT, MooTools... Todos son buenos y elegir la mejor opción es algo muy complicado: para encontrarla deberíamos pasar un tiempo considerable evaluando cada uno de ellos, sus ventajas y sus inconvenientes, y como solucionan los problemas que tenemos.

Pero, ¿merece la pena tanto esfuerzo? Probablemente no. Aunque haya un framework que sea inherentemente mejor que los demás, vamos a perder más tiempo buscándolo y evaluando posibles opciones, que si utilizásemos directamente el segundo o el tercer mejor framework, porque, entre los más conocidos todos son suficientemente buenos.

En mi opinión, la mejor solución para este problema es la que toma Ruby on Rails. Rails es Opinionated Software, software con opinión. Cuando creamos una aplicación nueva con Rails, la aplicación viene ya "con las pilas incluidas": ya tiene un framework javascript -prototype- una librería de testing, librería para fixtures , un motor de plantillas, un librería de ORM; la aplicación ya tiene una estructura: los controladores van en este directorio, las vistas en este otro; Rails utiliza Convention Over Configuration para darle nombre a las tablas en la base de datos, a las vistas y a los controladores; todas las tablas utilizan como clave principal un id autonumérico. Nada más empezar, el equipo de Rails ya ha tomado un montón de decisiones difíciles por ti.

Todas estas decisiones son discutibles, pero en la práctica resulta que en la inmensa mayoría de los casos, las decisiones que ha tomado el equipo de rails son suficientemente buenas. Rails es software con opinión, dice: yo hago las cosas así. Si luego quieres cambiar cualquier cosa, puedes hacerlo. Ruby es un lenguaje tan dinámico que eso no suele ser problema: aunque rails venga, por ejemplo, con su ORM -ActiveRecord- o su motor de plantillas -ERB-, se puede sustituir ActiveRecord por DataMapper o ERB por Haml. Yo, por ejemplo, cuando programo con Rails suelo utilizar jQuery en vez de Prototype, el framework javasacript que trae Rails por defecto.

Si lo hago es porque tengo claro lo que quiero y sé lo que estoy haciendo. Pero si no lo tienes claro, Rails ya te da un stack que funciona muy bien y te ahorrará muchas indecisiones y quebraderos de cabeza.

Parálisis por análisis

Cuentan la historia de un burro que murió de hambre porque le pusieron delante un cubo de alfalfa y otro de cebada y no supo por cuál decidirse.

Siempre pensamos que tener muchas opciones disponibles es algo inherentemente bueno, una ventaja en cualquier situación. Tener muchas opciones puede ser algo conveniente en ciertas circunstancias, pero también puede conducir a lo que se conoce como parálisis por análisis.

Para estudiar cómo tomamos decisiones complejas, los investigadores Eldar Shafir y Donald Redelmeie dieron a un grupo de médicos el historial hipotético de un paciente de 67 años que sufría de dolor crónico de cadera. El paciente llevaba años de tratamiento con distintos medicamentos que no le habían solucionado su problema, por lo que los doctores se estaban planteando una operación de sustitución de cadera. Esta operación es muy traumática y tiene una recuperación larga y complicada por lo que sólo está indicada en casos los que otras terapias ya han fracasado.

Sin embargo, justo antes de que el paciente se sometiese a la operación, los doctores descubrieron que había un medicamento que no se había probado con el paciente y que podría ayudarle. Ante este historial, el 47% de los doctores optaron por el procedimiento menos agresivo de recurrir a la cirugía si este último medicamento tampoco surtía efecto.

Sin embargo, cuando los investigadores cambiaron la historia para que no sólo quedase un medicamento por probar, sino dos, sólo el 28% de los doctores se decantaron por probar con los medicamentos.

El sentido común nos dice que hay más posibilidades de que cualquiera de los dos medicamentos ayude al paciente, pero este factor no parece determinante en la decisión de los doctores. ¿Qué está pasando?

Cuando nos enfrentamos a una decisión complicada, cuantas más opciones tengamos, más confuso se vuelve el asunto y más difícil es decidirse. Al final, llegamos a una situación de confusión en la que ninguna opción parece claramente mejor, cuanto más analizamos el asunto más difícil resulta tomar una decisión. Sufrimos lo que se conoce parálisis por análisis, una parálisis que nos impide tomar ninguna decisión. En esa situación, suele ganar la ley de la inercia: lo más fácil es no tomar ninguna decisión y que las cosas sigan como estaban.

La fuerza de voluntad es un recurso finito

A menudo pensamos que existe gente con una gran fuerza de voluntad y otros que simplemente son vagos y perezosos. Y esto es así, pero también lo que parece vagancia puede ser, a veces, simple agotamiento.

En 1998 un grupo de investigadores americanos realizaron una serie de experimentos destinados a medir cómo el ser humano hace uso de su fuerza de voluntad. En los experimentos se citaba a un grupo de estudiantes universitarios para participar en un supuesto estudio sobre la percepción del sabor. Los investigadores pidieron a los estudiantes que se saltaran una comida antes del estudio y que no comieran nada en las tres horas anteriores al experimento para asegurarse de que tenían hambre.

Justo antes de que llegaran los conejillos de indias, los investigadores cocinaron en la sala contigua al estudio una remesa de galletas que inundó el ambiente de aroma a chocolate. Cuando los estudiantes llegaron se les sentó en una sala, llena de ese delicioso aroma a chocolate, en la que había una mesa con dos fuentes: una llena de galletas recién horneadas y la otra llena de rábanos. Los investigadores intentaban poner a prueba la fuerza de voluntad de los sujetos: les pidieron a la mitad que comieran galletas de chocolate y a la otra mitad que comieran rábanos. Además, dejaron solos a los sujetos para favorecer la tentación de comer galletas de chocolate.

En principio, parecía que todo el montaje había sido en vano porque ninguno de los desgraciados comedores de rábanos sucumbió a la tentación y se comió una galleta prohibida. Sin embargo, lo que ocurrió poco después demuestra que la tentación de las galletas sí que dejó huella en los comedores de rábanos.

Después unos minutos saboreando la comida que les había caído en suerte -rábanos o galletas- los investigadores proporcionaron a los estudiantes un par de cuestionarios. Cuando los estudiantes terminaron de responder, los investigadores dieron por finalizado el experimento y dieron paso a un nuevo estudio sobre la capacidad cognitiva de los estudiantes. Este experimento consistía en pedir a los estudiantes que resolvieran varios puzzles complicados, trazando una serie de figuras geométricas sin levantar el lápiz de papel. Les dijeron a los estudiantes que no importaba cuanto tiempo tardasen en resolver el puzzle ni el número de intentos que empleasen.

El único problema es que esos puzzles no tenían solución posible: los investigadores simplemente medían la perseverancia de los sujetos. Y en ese test sí que se observó una gran diferencia entre los comedores de galletas y los comedores de rábanos: los comedores de galletas estuvieron intentando resolver el puzzle una media de 19 minutos, e hicieron por término medio 34 intentos. Sin embargo, los comedores de rábanos sólo emplearon una media de 8 minutos y 19 intentos.

Los investigadores eligieron a los comedores de rábanos al azar, no eran gente menos perseverante o motivada que sus compañeros comedores de galletas. Y, sin embargo, perseveraron mucho menos en resolver el puzzle. ¿Por qué? Por lo que se conoce como agotamiento del ego: Podemos emplear la fuerza de voluntad para resistir nuestros impulsos, pero esta capacidad de esfuerzo es finita y se agota si la forzamos demasiado. Nuestra fuerza de voluntad es finita. Usadla para algo positivo.