Cuando empecé a dar charlas supe que no tenía que ser la más experta del tema ni la que más sabe de la conferencia sobre eso, pero que si hablo de mi experiencia, añado un punto de vista único y eso lo hace valioso y, además, a la gente le gusta.
Y además, cuando estoy dando una charla siempre pienso que todo el mundo sabe más que yo, que sabe todo lo que estoy nombrando. Eso me hace tener la sensación de que sería repetir algo que ya saben y que se aburrirían.
No solo estoy poniendo a todo el mundo por encima de mí en cuanto a conocimientos, es decir, poniéndome a mí siempre por debajo (que eso ya lo trabajo con mi psicóloga, tranquis), sino que doy por hecho que se sabe y se entiende todo y eso está mal.
Hace no tanto tuve MUCHÍSIMA ansiedad mientras estaba preparando una charla porque pensaba que no tenía sentido, que no iba a aportar nada nuevo, que era demasiado básica. Incluso estuve a punto de cancelarla (solo que la ansiedad de quedar mal era mayor 🙃)
En esta charla contaba un poco las diferencias que yo he notado cuando trabajaba de front y ahora de back, así como la manera en la que trabajamos en mi equipo desarrollando producto y algunas prácticas que llevamos a cabo. El objetivo era que si les gustaba o llamaba la atención alguna de estas prácticas, pudiesen adoptarlas y adaptarlas a su equipo o, si buscan un cambio laboral, quizás buscar una empresa que trabaje de manera similar. O si no les gustaba nada de eso, pues precisamente ir en dirección contraria.
Voy a aprovechar entonces de contarles muy resumidamente una parte de la charla sobre cómo trabajamos, nuestro mindset y las prácticas que llevamos a cabo y luego contarles la sensación que tuve con respecto a los comentarios que recibí.
Las prácticas de Extreme Programming que aplicamos tienen como objetivo desarrollar software en ciclos cortos. Hacemos entrega contínua y también el aprendizaje es contínuo ya que al entregar, obtienes** feedback** de la usuaria inmediatamente para saber si tu producto se está comportando como lo esperas y, si es necesario, iterar o mejorar, así como ir midiendo.
Para poder obtener ese feedback de manera inmediata:
El código que desarrollamos es de calidad porque está testeado. Sí, los bugs también los puedes meter si tienes tests, porque al fin y al cabo los tests los haces tú, humana que se puede equivocar; pero las probabilidades son bastante menores a si no los tienes.
En nuestro caso hacemos Test Driven Development (TDD), donde escribimos primero un test, pasa en rojo porque aún no está hecha su implementación y desarrollamos la implementación con el mínimo código necesario para pasar el test en verde. Una vez que el test está en verde, hacemos commit y push, por lo que son commits muy pequeñitos, uno tras otro. De ser necesario un refactor, lo hacemos con el test en verde para tener la seguridad de que, si rompemos algo, el test nos va a avisar. El TDD nos permite tener un código fácilmente modificable que nos facilite cuando necesitemos iterar. También hay que decir que es una herramienta más, la idea es tener tu código testeado, sea con TDD o sin él. A mí me encanta y me encantaría trabajar siempre así, pero es verdad que su curva de aprendizaje no es trivial y más cuando ya has trabajado algún tiempo antes sin él (y sin testing).
Usamos Trunk Based Development (TBD), donde desarrollamos en la rama principal y los commits se pushean directamente a master/main para poder entrar en ese ciclo corto y obtener ese feedback rápido que tanto nombro. (Aquí la gente se llevó las manos a la cabeza, se escuchan murmullos y veo caras en shock)
Si estamos desarrollando una nueva funcionalidad y aún no queremos ponerla en producción, o por ejemplo hacemos un experimento que queremos sacar- medir-cerrar-iterar; usamos las Feature Flags para poder ir desplegando pero aún sin hacer release. En nuestro caso es una variable de entorno que ponemos a true/false cuando queremos que llegue a producción, o no.
Trabajamos en Pair y mob programming, de manera que el código no es responsabilidad de una sola persona y se puedan esparcir conocimientos de manera más orgánica. Aparte del beneficio del aprendizaje en conjunto.
Para asegurarnos que las decisiones que hemos tomado están aportando valor a la usuaria y que nuestro producto se está comportando como esperamos, tenemos las métricas y los logs como herramientas de observabilidad y trazabilidad.
Las métricas las revisamos diariamente todo el equipo (vamos rotando) en un tablero de Quicksight que es un servicio de AWS. Aquí vemos la evolución de, los clicks, leads y el Conversion Rate diariamente, comparándolo con el mismo día de la semana anterior y el mes anterior y así, además, podemos conocer sobre estacionalidad y saber que, por ejemplo, en enero suele haber un pico de gente buscando pisos, o que ayer cayeron los clicks porque era festivo en Colombia.
Y los logs los ponemos con el objetivo de que, al explorarlos, nos den información de lo que está pasando en nuestra aplicación en ese momento. Los guardamos en una “base de datos de logs”, en nuestro caso Cloudwatch, otro servicio de AWS.
Todas estas prácticas las nombré en la charla porque las usamos y son nuevas para mí desde que entré en este equipo, nunca había trabajado así antes cuando trabajaba en consultoras. Otra gran diferencia es la manera de trabajar que tenemos en el equipo, donde formamos parte de la definición del producto. Esto hace que estés más involucrada en lo que estás desarrollando, conocer el por qué, investigar, buscar entre todo el equipo soluciones juntas.
No todas las tareas que hacemos son de programar (que les digo, son mis favoritas) porque resolvemos problemas junto con Product Manager, leemos datos, los interpretamos, iteramos en base a ellos, definimos next steps y también hacemos Spikes para leer e investigar sobre el problema antes de meternos en ello y así poder respondernos preguntas, aprender y bajar el riesgo de error.
Las tareas las afrontamos “todas a una”. Intentamos detectar lo prioritario y vamos todas a eso simultáneamente, sea en mob porque lo requiere la tarea o hacemos split y trabajamos 2 parejas, o una pareja y un trío, depende. Esto nos ayuda a tener contexto de lo que se está trabajando y hacer una entrega más rápida para nuestro amigo: el feedback de la usuaria.
Si no es posible o las circunstancias no lo permiten y trabajamos cada pareja en una tarea distinta, luego hacemos catch up para poder traspasar conocimientos.
Discutimos sobre concerns y hacemos tareas que cuidan nuestro código y que puede que no entreguen directamente valor, pero son igual de importantes y evitamos acumular tanta deuda técnica.
Esto, les repito, ha sido una parte muy resumida de la charla y ahora quiero contarles algunas preguntas y comentarios que recibí, pero primero tienen que imaginarse la situación:
Una mujer con una camiseta de Opeth dando una charla en una universidad a un montón de ingenieros egresados y estudiantes, contándoles que es enfermera y psicopedagoga y que lo que hizo fue un bootcamp y que además hace push a master😂
La sensación que tuve en general después de las preguntas y comentarios que recibí era de incredulidad. Yo sentí que la gente pensaba que yo estaba metiendo la coba, o sea que me estaba inventado todo porque simplemente no les parece viable.
Me preguntaron que cuánto tiempo al día dedicamos en hacer tests y si no nos hemos puesto a pensar en todo ese tiempo que podríamos invertir en * desarrollar *. Porque desarrollar != tests, claro.
Me dijeron que en lo que “nuestro jefe” se entera que estamos trabajando juntas en parejas o más, se nos va a acabar el chollo.
Que vino agile, luego scrum y ahora vine yo a decir “sujétame el cubata”, con tono jocoso burlón, claro.
Que es irresponsable hacer TBD y no probar en entornos de desarrollo previamente.
Que si gano más ahora en backend que en frontend, LOL la pregunta.
Que cómo es que subimos código sin code reviews.
Que por qué no hago el grado superior “y no me digas que es por tu niño porque ya está mayor” (solo lo puede saber si me sigue en twitter jajaja), le digo que no tengo tiempo para eso y me dice -mientras señala a un grupo- que toda esta gente está estudiando mientras trabaja y le tuve que decir hola, señor, hice dos carreras ya trabajando a la par, una de ellas trabajando y embarazada; déjeme en paz.
Etc.
Saco varias conclusiones:
- Me encontré con la sorpresa de que de verdad no conocían muchas cosas (porque hola, “todo el mundo siempre sabe más que yo”). Y no me lo esperaba y me costó entender por qué ciertas preguntas y comentarios. Me llevo el aprendizaje de no dar nunca nada por hecho. Y darme un poquito de fe.
- Me quedo con la sensación de que nadie da un duro por lo que conté y eso, quieras o no, lo siento un poquito como un fracaso. Aunque espero que al menos a alguna persona le haya servido.
- Que tanta ansiedad y malestar las 3 semanas antes, para que al final sí fuese algo nuevo para el público… aunque me hubiese gustado más sensación de “wow qué guay” que de “pff, estás loca”.
- Me pregunto si hubiese sido un hombre, hubiese sido más wow que pff
Una cosa importante, yo estoy muy agradecida con haber dado estas charlas y las organizaciones no tienen nada que ver con lo que luego me digan o pregunten. Ni todo el público ha sido así <3 pero hay unos que resuenan.
Si les llama la atención saber más de cómo trabajamos, hay otras cosas interesantes que se las puedo contar luego =)
Ari
Top comments (4)
Es que mira que eres una sacrílega, no seguir el camino de formación reglada, regulada y estudiar y formarte de una manera libertina. Y encima dando charlas? Qué escándalo mare mea. Con lo bien que se sienten ellos siendo de elite o formando un parte de un grupo al que se entra según el camino establecido y tú haces atajos. Sacrílega provocadora.
Pero aparte de bromas satíricas sobre tu locutorio, la charla debió ser muy interesante y a mí se me ocurrían preguntas más interesantes que las que te hicieron. Enhorabuena.
Por ejemplo me gustaría saber si implementais código adicional para conocer la cobertura de los test, tipo 'coverage'de Python. Yo soy analista y científico de datos pero tengo curiosidad por conexiones a bases de datos, contenedores y etcétera
Pues yo no veo ningún problema a nada de lo que has comentado. Hacia el mismo lugar trato de llevar a mi equipo con mayor o menor fortuna. Todavía no hacemos TDD, pero tenemos muy claro que los test son lo más importante. Todavía no usamos TBD, pero apuntito estamos; cada miembro del equipo es autónomo para subir a master y desplegar en producción, los test nos dan seguridad total. Trabajamos en parejas con bastante frecuencia. Rotamos tareas como la revisión de logs o buzón de e-mail. En resumen, a tope con todo lo que comentas.
¡Hola Ari!
Muchas gracias por compartir tu experiencia trabajando de esta manera. ¡Me ha resultado interesante y me gustaría saber más acerca de como trabajáis!
Un saludo :)