La carga cognitiva destroza el desarrollo
Haz foco en lo importante
En nuestro día a día como desarrolladores de software estamos sometidos a mucha complejidad. Esta complejidad, como ya he comentado en artículos anteriores, afecta a nuestro desarrollo de muchas maneras haciendo que seamos menos productivos y eficientes a la hora de aportar valor a nuestros usuarios y a nuestro negocio.
Parte de la complejidad de nuestro trabajo es influenciada por la carga cognitiva a la que estamos sometidos. Cuanta más carga cognitiva tenemos más difícil hacer foco, cosa que hace que nuestra habilidad de desarrollo y resolución de problemas se vea afectada.
Hace unos meses me integré en un equipo que, entre otras cosas, tenía un problema de carga cognitiva (aunque ahí aun no lo sabían).
Una temporada en que la situación había sido difícil, y en la que habían tenido muchos problemas de resiliencia con sus productos, los habían llevado a hacer cosas extras para intentar mitigarlos. Una de las acciones que tomaron fue hacer un checkpoint semanal para hacer un repaso de cómo iba el sprint. También establecieron una reunión los viernes para analizar los incidentes de la semana entre todos y sacar acciones. Durante el desarrollo de nuevas funcionalidades también preparaban y organizaban pruebas E2E que les llevaban horas de definir, preparar y hacer. Si no fueran pocas tareas también invertían tiempo de desarrollo en preparar al detalle presentaciones que tenemos cada 15 días con negocio. A parte carecían de un sistema de Continuous Delivery y, por lo tanto, cada nuevo cambio tenían que desplegarlo a mano (se llegaron a crear un bot de slack que les avisara todas las mañanas que había que subir).
No dudo que todas esas acciones no estuvieran justificadas de alguna u otra manera, pero el equipo de desarrollo iba ahogado y parecía que no tenían tiempo ni para desarrollar producto.
Tipos de carga cognitiva
Existen 3 tipos de carga cognitiva que nos afectan en nuestro día a día al desarrollar:
La intrínseca: esta es inherente a la complejidad de la tarea que realizamos por sí misma y a su contexto dentro del negocio. Es la que ocurre cuando trabajamos desarrollando algoritmos, cuando pensamos como estructurar nuestro código o cuando debuggeamos algún error. Es el aguante que tenemos frente a una tarea compleja y cuanto podemos soportar.
La relacional: esta es la relacionada con aprender. La carga que tenemos que superar cuando empezamos a descubrir un nuevo lenguaje, una nueva estructura de datos o una nueva metodología de desarrollo. Es la que pagamos a la hora de adquirir nuevas habilidades y comprender cosas a largo plazo.
La extraña: esta es la carga cognitiva innecesaria, la complejidad que viene dada por nuestro entorno o el de la tarea que estamos realizando. Puede venir causada por procesos pocos eficaces, un entorno de desarrollo mal configurado que nos estorba más que ayudar o un pipeline de desarrollo muy manual y complejo.
Como podemos intuir, las cargas cognitivas intrínseca y relacional son parte del corazón de nuestro trabajo. El desarrollo de software es algo complejo por naturaleza y el mantenerse al día con las últimas tendencias y tecnologías es necesario en un campo donde no paramos de avanzar.
Sin embargo, tenemos el otro tipo de carga cognitiva, la extraña, la que existe solo para estorbarnos. La que nace por las ineficiencias de nuestros procesos y de nuestro entorno. Y es justo esa la que podíamos atacar.
Las acciones
Para arreglar la situación tomamos algunas medidas que redujeran toda esa carga cognitiva y permitiesen al equipo dedicar tiempo a lo que de verdad importa: aportar valor a los usuarios.
Nos cargamos el checkpoint semanal, redujimos la frecuencia y quien tenía que asistir a las reuniones sobre incidentes, redujimos el número de E2E y procedimentamos un poco el proceso para hacerlos más amenos, el equipo de desarrollo dejó de dedicar tanto tiempo a preparar los datos para la reunión con negocio y se implementó un sistema de despliegues automáticos que nos liberara de esa tarea.
No fue un proceso de la noche a la mañana ni de una sola persona, fue algo que duró meses y que fuimos iterando en conjunto para ver qué era lo que mejor funcionaba. Poco a poco el equipo tenía menos cargas y más tiempo para dedicarle al desarrollo.
A parte de todas estas cosas también tuvimos otro tipo de cambios más organizativos, pero una cosa me quedó muy clara: todo lo que le quitamos al equipo de encima les permitió hacer foco, pero foco de verdad. El desarrollo de producto mejoró y los incidentes se redujeron. Y sé que gran parte de ello fue gracias a reducir esa carga cognitiva.
Reduce la carga cognitiva
Luchar para que el IDE nos haga caso es carga cognitiva, que el proceso de despliegue sea muy tedioso y falle muchas veces es carga cognitiva, que tengamos que pasarnos media hora intentando adivinar que hace un código mal estructurado y con deuda técnica es carga cognitiva. Y es carga cognitiva de la mala, de la que molesta. Lo mejor que podemos hacer es eliminarla para dejarle espacio a los otros tipos de carga más útiles: los de pensar y aprender.
Algunas estrategias que podemos hacer para reducir esta carga tan molesta son:
Automatizar configuraciones: Utilizar herramientas como Docker o la contenerización para automatizar y estandarizar la configuración de entornos de desarrollo entre equipos. Que no nos cueste 2 días levantarnos el entorno de desarrollo usando un README desactualizado.
Consolidar herramientas: Usar herramientas o plataformas que combinen múltiples funcionalidades para reducir la necesidad de cambiar de contexto constantemente. Saltar entre herramientas que hacen cosas similares hace que el foco y el contexto se pierda.
Automatizar despliegues: Implementar pipelines de CI/CD para automatizar procesos de construcción, prueba y despliegue, reduciendo la intervención manual y la carga cognitiva. Olvidarnos de tener que desplegar todo a mano cada vez hace que vivamos mejor.
Reducir la complejidad de tu código: Fomentar prácticas de código limpio y diseño simple para mejorar la legibilidad y mantenibilidad, reduciendo la carga cognitiva al trabajar con el código.
Limitar reuniones y comunicaciones: Establecer canales de comunicación claros y limitar las reuniones a las esenciales para evitar la sobrecarga de información (podría haber sido un email…).
Estandarizar flujos de trabajo: Definir y fomentar flujos de trabajo estandarizados para minimizar la resolución ad-hoc de problemas. Por ejemplo, hacernos playbooks o guías para los procesos complejos para no tener que mantener todo en la cabeza.
Reduciendo la carga cognitiva activamente y quitándonos de encima todo aquello que no nos aporta nos permitirá hacer foco en lo verdaderamente importante: cubrir las necesidades de nuestros usuarios.
TL;DR
La carga cognitiva en el desarrollo de software impacta directamente en nuestra productividad y eficiencia. Se divide en tres tipos: intrínseca, relacionada con la complejidad inherente a nuestras tareas; relacional, ligada al aprendizaje y la adquisición de nuevas habilidades; y extraña, causada por entornos o procesos ineficientes. Si bien la complejidad inherente y la relacionada con el aprendizaje son fundamentales, la carga cognitiva innecesaria proveniente de procesos y entornos deficientes obstaculiza nuestro desempeño.
Para optimizar nuestro trabajo, es crucial reducir esta carga molesta y permitir más espacio para el pensamiento y el aprendizaje. Automatizar configuraciones, consolidar herramientas, simplificar despliegues, mejorar la calidad del código, limitar comunicaciones y establecer flujos de trabajo estandarizados son estrategias efectivas para minimizar la carga cognitiva superflua y potenciar nuestra capacidad creativa y resolutiva como desarrolladores de software.