Context is an interface to global information about an application environment. This is an abstract class whose implementation is provided by the Android system. It allows access to application-specific resources and classes, as well as up-calls for application-level operations such as launching activities, broadcasting and receiving intents, etc.
Android Docs
El contexto es una palabra un poco general para definir las circunstancias que rodean a cualquier cosa. Si nos lo llevamos a la realización de una actividad, podríamos entender el contexto como la hora del día en el que la hacemos, donde se lleva a cabo o cualquier otra casuística que pueda afectar a dicha actividad. Si matizamos un poco en el ámbito de la programación, podemos referirnos a toda la configuración e información necesaria que necesitamos mientras estamos realizando una tarea específica.
Una vez acotado a lo que nos referimos con el concepto de contexto, nos toca hablar de uno de nuestros mayores enemigos relacionado con él: los cambios de contexto.
Sin meterme en definiciones académicas ni mucho menos, simplemente por ilustrar un poco el concepto, se entiende como cambio de contexto la alteración de las circunstancias relativas a cierta tarea y que son necesarias para proceder con ella.
Basta de definiciones técnicas y palabras bien juntadas. Llevemos el concepto a un ejemplo que todos nosotros hemos vivido.
9 de la mañana. Como eres un desarrollador organizado y previsor, tienes claro lo que tienes que hacer durante el día. Repasas tu ticket de Jira por si acaso y empiezas a picar código. Depende de si pensamos en hace unos años o en la actualidad, habrá más o menos IAs metiendo bugs en el código, pero ese es otro tema. Feliz, rodeado de código, programas hasta la daily que la tienes sobre las 10:30-11:00 y cuentas a tus compis lo bien que estás avanzando. Optimista, les cuentas que probablemente lo termines en el día y que pondrás la PR después de comer. Terminada la daily de 15 minutos (en algunos lugares existen), te echas tu segundo café y vuelves a seguir con tu código a medio hacer.
Agazapado entre las sombras, acechando en busca de un jovencito confuso, aparece un mánager, alguien de operaciones o cualquier otro ser fantástico de las leyendas pidiéndote si tienes un momento para “mirarle una cosita”. Tú, como desarrollador nivel 1, incauto y con ganas de ayudar a la gente, sueltas tu amado código y le prestas totalmente la atención a esa “cosa rara” que han detectado en un gráfico, que le ha pedido un cliente o que simplemente alguien ha dejado abandonada en el felpudo.
Tras varias horas comentando la situación e intentando recopilar la mayor información posible, vuelves al código del ticket que nunca deberías haber abandonado y te creas una nueva rama para resolver ese “problemita” que es lo más urgente del mundo y que sólo puedes resolver tú, que eres el que ha hecho casito. Al final era una tontería; entre resolverlo y hacer un test para que no vuelva a pasar, se te ha ido sólo una hora. Justo a tiempo para comer, pones corriendo la PR y dejas pasando el pipeline.
Terminas de comer tranquilamente y vuelves al ordenador. Ves que todo ha pasado correctamente en la PR del bug y le mandas la versión de vuelta para que la prueben y la validen. Idealmente, esto se haría en el momento pero como sabes que ellos suelen comer tarde, tú vuelves a tu código original – ese que con tanto mimo estabas haciendo – y aprietas para intentar tenerlo cuanto antes. Obviamente, te vas dando cuenta que tu plan inicial de tener listo tu ticket hoy no se va a cumplir. Afortunadamente, tu team lead sabe de estas situaciones y no te va a echar la bronca por no cumplir con lo que has dicho en la daily pero aun así, te quedas con mal sabor de boca.
6 de la tarde, has apretado un montón, estás orgulloso de haberlo conseguido pero no te da tiempo a dejarlo todo fino. Pones la PR para que se vaya pasando el pipeline y tras no recibir noticias del bug, cierras el ordenador y te vas a sacar a los perros. Mañana será otro día. Tras muchos cambios, todo ha ido relativamente bien.
Al siguiente día empiezas con ganas de finiquitar todo y cerrar el sprint de tu equipo. La primera en la frente: ves en Slack que a las 18:30, poco después de que terminases, te habían puesto un mensaje diciendo que la versión que solucionaba el “urgente bug” no les valía. Aunque se había solucionado el error inicial, el problema se reproducía en más sitios de la aplicación y había que arreglarlo cuanto antes. Tras cagarte en <INSERTA AQUÍ TU BLASFEMIA PREFERIDA> porque no te han dado toda la información que necesitabas, vuelves a cambiar de rama corriendo para solucionar el error cuanto antes en todos lados.
Llega la daily. Le cuentas a tus compañeros tus historietas y se sienten identificados. Aunque todos sabemos la situación, y los mánagers hacen lo que pueden, muchas veces no se es tajante con las interferencias externas y se acaban haciendo cosas fuera del sprint sin estar planificadas. Dices que intentarás redirigirlos la próxima vez y les confirmas que hoy estará listo tu ticket original.
Vuelves al bug, terminas lo poco que te quedaba y pones la PR otra vez. Cambias a tu código original, revisas la PR y ves que tus compañeros te han dicho que faltan los tests y que si no, no se puede mergear. Los haces corriendo mientras ves por el rabillo del ojo que en la otra PR han fallado los tests y que el linter te dice que te has dejado cosas mal formateadas.
Tranquilos, la historia acaba bien. Al final, se terminaron las dos cosas correctamente pero en un tiempo que no era el que correspondía. No es porque nuestro amigo no fuera buen programador, el problema fue que no pudo centrarse en completar una tarea sola y que la multitarea es ineficaz por definición.
Simplemente seguir la historia puede resultar lioso ya que se juntan conceptos, nomenclaturas y cosas que van pasando en paralelo. Si es difícil leerlo, imaginad llevar el control mental para que no se pase nada por alto.
Los cambios de contexto generan pérdidas de tiempo per se. Aunque sean simples cambios de código, siempre llevan asociados tiempos de lectura de tickets, creación o cambios de ramas de git, creación de PRs… Los cambios son muchos. Por eso, aunque la cosa sea “pequeñita” cuantos más cambios tengas, menos tiempo efectivo vas a tener para desarrollar la tarea. Además, ese tiempo resultante es menos aprovechable cuando no es posible centrarse al 100%.
Como os he contado antes, tengo muchos frentes abiertos en cuanto a aplicaciones inacabadas. Cada proyecto acababa siendo de su padre y de su madre porque en base a lo visto en un post anterior, cada app tenía una arquitectura diferente, con patrones diferentes y librerías diferentes. Todos estas pruebas habían cumplido su propósito inicial que era trabajar con algo nuevo y ver de qué iba la cosa. Sin embargo, el mantenimiento de todos esos proyectos resulta muy tedioso a día de hoy.
Asumiendo que no voy a refactorizar todos los proyectos existentes, cada vez que quiero seguir trabajando en un proyecto tengo que adaptarme a las decisiones que tomé en dicho caso. Los cambios de contexto son uno de los pozos donde se pierde más tiempo ya que tenemos que adaptarnos a una nueva situación que puede ser totalmente diferente y nos distrae de nuestro foco principal.
Para que nos quedemos con buen sabor de boca, estos son algunos consejos para mitigar los efectos de los cambios de contexto:
En la medida de lo posible, intenta siempre finalizar la tareas que tengas entre manos antes de cambiar a la siguiente.
Si tienes que trabajar en varios proyectos a la vez, marca espacios de trabajo que puedas dedicar íntegramente de forma separada.
Reduce al máximo las reuniones y concéntralas en unas horas concretas de la jornada.
Las notificaciones no ayudan. Silencia las que no sean urgentes y marca espacios de tiempo para atenderlas.
Documenta los cambios que vayas haciendo. Cuando vuelvas a un proyecto antiguo, tu futuro yo te agradecerá que le eches una mano recordando de qué iba.
Hay muchas más estrategias para que podamos aprovechar mejor el tiempo pero el primer paso es detectarlo. Una vez que ves el problema, es mucho más fácil trabajar en él. No será un camino fácil pero las buenas noticias son que probablemente el resto de tus compañeros tengan los mismos problemas y os podáis poner de acuerdo para solventarlos.
Nos vemos!