La Sinergia del Equipo

“La belleza de un movimiento de ajedrez no se refleja en su apariencia, sino en el pensamiento que hay detrás de él.” Tarrasch

“A los usuarios finales les da igual que usemos o no DDD, ellos eso no lo ven”. Creo que esta frase puede ser escuchada en cualquier equipo de desarrollo de software. Es una creencia muy común, y bajo mi punto de vista errónea, que los usuarios finales no sean conscientes que usemos o no ciertos patrones/diseños que den calidad a nuestro código. Es verdad que no van a conocer el término DDD y les va a importar poco lo que quieran decir sus siglas; pero ellos sí van a percibir si el producto software que están usando ha sido desarrollado con calidad o se ha sacado una versión rápida por presiones de tiempo o cualquier otro impedimento.

…Una vez más ahí estaba Resharper, resaltándome una variable que no está siendo usada en mis narices. Programando soy un poco despistado. Menos mal que el programita de JetBrains te avisa de estas cosas y solo con acercar el ratón a la variable te sale la bombilla, le das a arreglar y listo. Creo que es una de las mejores herramientas de programación, ¡no sé qué haría yo sin ella!…

Un producto software siempre tiene un equipo detrás. El product owner, el scrum master, los desarrolladores, los analistas, los diseñadores, los posibles comerciales de ese producto, etc. ¿Creéis que el usuario final no ve si en un equipo ha habido compenetración desarrollándolo? En mi opinión eso es algo que se acaba viendo. Quizás no se oyen los gritos que puedas percibir en un restaurante cuando hay mal ambiente entre camareros y cocinas, como pasa en los programas de Chicote; pero puede que esos “gritos” o malentendidos dentro del equipo de desarrollo o entre los desarrolladores y las demás piezas de un producto software, no se escuchen literalmente, pero seguro que quedan reflejados en algún bug, alguna implementación no optimizada para el uso de un usuario o incluso en alguna grave vulnerabilidad.

…Se ha acercado Juan a mi sitio. Se cree muy listo. Le quería preguntar una cosa sobre si era posible quitar un switch del código. Él siempre dice que se pueden eliminar, pero como se cree tan “listillo” casi nadie le hace caso ya cuando habla. Tienes que ir con pies de plomo con él. Pues después de resolverme la pregunta me ha dicho: “¿pero esa variable la estas usando? Si no la usas bórrala”. No sé para qué me avisa de esas cosas ¿Para hacerse el importante? ¿Acaso le he preguntado sobre eso? El código funciona con o sin esa variable. Como le gusta encontrar los fallos de los demás…

¿Habéis sido alguna vez Juan? ¿O quizás habéis sido alguna vez el programador/programadora que se metía con Juan? ¿Y qué me decís del que usaba Resharper? Está muy de moda el término de “Comunicación No Violenta”, y su práctica en el mundo del software entre desarrolladores. ¿Creéis que Juan ha sido mucho más violento que Resharper? Ambos han dado la misma información; pero su receptor ha obtenido el mensaje de manera diferente. ¿Y si os dijera que el desarrollador/desarrolladora que se metía con Juan era el mismo que dijo la frase de Resharper?

Yo pienso que nos estamos volviendo locos. Si ya es difícil dominar el arte de la programación, añadir a nuestras aptitudes el arte de la comunicación no violenta me parece demasiado. Creo que más que el emisor del mensaje, hay que trabajar en el receptor, para que no vea maldad en su equipo. Es fácil que el emisor del mensaje tienda a exagerar el estado del código, sobre todo si su visión es negativa, ya que en nuestro lenguaje tendemos a exagerar más las cosas negativas que a elogiar las positivas. Pero eso no debe bloquear al equipo y quedarse mirando el dedo que señala la luna; sino que, para mí, en un buen equipo el receptor debería ser consciente que detrás de ese dedo le están señalando la luna que se le ha pasado sin querer, y si éste no es capaz de reaccionar así, debe haber algún miembro del equipo que medie para que los dos desarrolladores se entiendan.

Quizá si una máquina te dice que tienes una vulnerabilidad porque estás paginando los resultados de tu consulta de EF no te moleste tanto si te lo dice tu compañero de enfrente. Claro, tu compañero de enfrente, ese con el que “compites” por tu puesto. A Resharper nadie le va a quitar el puesto…

Yo he estado en los dos lados. En el de Juan y en el de su compañero. Me da pena que vivamos en un mundo capitalista donde se “compite” por un puesto de trabajo y muchas veces los sueldos de los programadores no sean acordes a su función en el equipo, pero son las reglas del tiempo que nos ha tocado vivir y eso debería quedar aparte. Nunca se compite con tus compañeros de equipo. Esa lucha del sueldo será siempre entre tu jefe y tú, pero tu equipo debe quedar fuera de esa batalla. Por tanto, nadie compite contra nadie, mucho menos dentro de un mismo equipo creando un producto software, por mucho que esté en juego el puesto de jefe del producto estrella de tu empresa donde te da acceso directo a cosas de jefes. Eso será más política que desarrollo de software, y si no eres capaz de tener un equipo sin ese tipo de problemas, tu usuarios finales “oirán” esas discusiones en tu producto final.

Evidentemente influye la manera que tenemos de expresarnos. Es algo que no hay que esconder. Pero vuelvo a la pregunta de: ¿es Juan más violento que Resharper? Es muy complicado ser siempre complaciente con tu receptor, en especial si ya te han etiquetado de “hater”. Confiamos ciegamente en lo que dice Resharper, porque, sin lugar a dudas, es mucho más fiable que cualquier persona; pero no somos capaces de preguntar después de una crítica de un compañero el porqué de su feedback negativo. Es decir, quizás sea cierto que sin eso no funcione, pero cuando alguien dice “eso es una mierda” hay un motivo detrás, y si lo único que pensamos es en nuestro ego y en que ha dicho que lo nuestro es una mierda por atacarnos, nos vamos a perder ese porqué, esa oportunidad de aprender algo nuevo. Ya que, seamos realistas, es una oportunidad. Puede que eso que esconde ese “esto es una mierda”, “no sé como programáis aquí” o un largo etcétera de expresiones “violentas” no sea más que un desconocimiento por parte del emisor, pero ¿no merece la pena escucharlo si tenemos alguna duda al respecto?

He estado en el lado de Juan y sé que es difícil que se pasen el día cuestionando tus comentarios. Sobre todo porque no los haces por molestar, los haces por mejorar al equipo. Pero se produce un efecto rebote y el equipo, en lugar de mejorar, empeora, ya que acaba tomando una posición a la defensiva frente a ti.

También he estado en el lado de sentir el ego muy alto por algo que habían dicho sobre mi código. Tengo que reconocer que al principio me lo tomaba todo fatal. De hecho, no era capaz de reaccionar. Pero ahora intento siempre responder con un “¿por qué dices eso?” ante alguien dice que eso está “mal”. Hay muchos tonos de mal y a mí me gusta saber la mejor solución a un problema software; aunque luego no dé tiempo a implementarla si estamos muy justos de tiempo o haya cualquier otro impedimento que no nos permita refactorizarlo todo.

Por eso soy un fiel defensor de las PRs, donde todo el mundo puede recibir feedback de cualquiera del equipo. Pero para ello hay que ser serios. No dejemos que las herramientas automáticas nos dominen y hablemos como personas. Un feedback sobre nuestro código siempre está hecho para que lo mejoremos, olvidemos rencillas personales y preguntemos qué hay detrás de un comentario, ya que no sabemos si lo que nos han dicho en un tono “violento” es porque esa persona ha tenido una mala semana en el ámbito personal, si está desarrollando mucho código que no le gusta como está y tiene ya la expresión de “mierda de código” en la cabeza o simplemente está cansado de que lo cuestionen.

Creemos un equipo de desarrollo con una sinergia positiva. Actuemos como personas entre todos y para paliar las rencillas que existan si hay alguna se pueden tomar medidas como: desayunar juntos los viernes, comer juntos un día a la semana en equipo sin hablar de código, ir a tomar cervezas con todo vuestro equipo para reír por cualquier tontería. El contacto humano fuera de los bits mejora mucho la unidad del equipo de desarrollo.

Hay que trabajar en equipo esa sinergia para que no nos acaben dominando las máquinas como Resharper y no tengamos que acabar hablando como ellas, sin expresividad, ya que lo bueno que todavía tenemos los programadores es que somos personas humanas. Disfrutemos del tiempo que nos queda programando hasta que esas máquinas sin expresividad nos sustituyan; pero mientras ¡hablemos! ¡mejoremos como equipo! Y compartamos todas las ideas que tenemos en la cabeza con los demás sin prejuicios absurdos.

¡Disfrutad de vuestros equipos! No solo programando, sino disfrutar también de las personas que tenéis detrás de esos programadores. Esa sinergia o complicidad o lo que surja entre vosotros seguro que acaba llegando al usuario final.

Porque, parafraseando la frase del principio, la belleza de un producto software no radica en su apariencia, sino en los pensamientos o ideas que han surgido en el equipo que hay detrás de él.