Palabras sobre código - por David Lay M.

Disclaimer

Este post fue en gran parte inspirado por el hilo que aquí comparto de Sarah Mei (en inglés)

I talk a lot about how you can’t be a great developer without great communication skills, but I don’t think people grok how _directly_ your communication skills are reflected in your codebase. Let me give you an example.

— Sarah Mei (@sarahmei) January 31, 2019

Pero no será simplemente una traducción. Es inevitable que interprete sus palabras, agregue cosas propias y contextualice un poco. Después de todo, nuestros trasfondos (el de Sarah y el mio) son muy distintos y estoy limitado por eso.

Sarah Mei

Sarah es una desarrolladora de más de 20 años de experiencia que hoy en día divide su tiempo profesional entre consultoría de software y generación de contenido (charlas, posts, artículos, entrevistas)

Sarah apareció en mi timeline hace 1 año más o menos hablando de cosas muy necesarias como la inclusión en el desarrollo de software, mentoría, liderazgo y cosas por el estilo.

Ella siempre discute estos temas con una profundidad de esas que solo tiene alguien que ha pasado por los problemas que denuncia y además ha reflexionado sobre ellos.

Si bien no concuerdo 100% con todo lo que dice, siempre la leo, especialmente por que su crítica no es fácil de leer y me hace cuestionar aspectos de mi profesión y personalidad. Sus palabras generalmente me incomodan y eso significa que hay algo en mí que necesita ajuste o al menos, revisión.

Pero ella escribe exclusivamente en inglés y hace tiempo que tenía ganas de traducir algo para compartir de manera más abierta con ustedes y este hilo me inspiró de manera particular, ya que hace encajar muchas piezas de todo lo (importante) que he aprendido en mis humildes 12 años de experiencia.

Tu habilidad de escribir código de calidad está limitada por que tan hábil eres comunicándote con otras personas.

Del código y las personas

La analogía de los acumuladores

Los Acumuladores es uno de estos programas de televisión gringos que pasan por cable. Muestran el sufrimiento de familiares que intentan ayudar a una persona con Síndrome de acaparador compulsivo (SAC) a limpiar su casa y que generalmente terminan botando todo y dejando la casa como nueva, aunque a largo plazo los problemas vuelven igual o peor que antes.

Imagina un proyecto de software grande en el que estás trabajando o que hayas trabajado, probablemente con código que ha escrito mucha gente que probablemente ya nadie recuerda. Podemos hacer la analogía que este código es como la casa de un acumulador.

Estos proyectos normalmente están llenos de cosas de las que no sabes para que son o siquiera si se usan. Para hacer tu trabajo tienes que lograr hacer pequeños caminos de entendimiento que atraviesan el desorden, como los pequeños espacios entre pilas de basura en living de un acumulador.

Hay zonas completas del código a las que no te acercas solo por el temor de que si mueves la más pequeña cosa todo se caiga encima.

Lo que sabemos que no funciona

Para salir de este problema es tentador tomar la misma idea en la que se basa el programa de televisión: traer un equipo de limpieza, o el equivalente en desarrollo de software, hacer una re-escritura. ¡Cambiemos a microservicios!

El programa de Acumuladores ya no tiene nuevos episodios, lo cancelaron. Descubrieron que a mediano o largo plazo estaban haciendo más daño que ayudando, ya que la limpieza, por muy profunda que fuera no cambiaba los hábitos y comportamientos de las personas afectadas y recaían, más temprano que tarde.

De la misma forma, una re-escritura puede dar un pequeño alivio y aumentar la moral por un periodo de tiempo, pero no arregla los problemas de comportamiento, los hábitos y los incentivos de quienes están haciendo el software, por lo que aquellos problemas regresan.

Si hiciste una re-escritura a micro-servicios de un gran monolito sin preocuparte de las personas y los incentivos, lo único que has logrado con esa inversión de tiempo y dinero es mover los problemas hacia la capa de red donde son más difíciles de ver, analizar y corregir, volviendo a parchar, a quick-fixes y a un desorden igual o peor que el que tenían antes.

¿Estamos perdidos?

Al igual que se puede tratar a una persona con SAC de manera responsable cambiando sus hábitos lentamente y haciendo que ellos sean los que limpien su casa poco a poco, también se puede lograr que un equipo corrija sus hábitos cambiando la estructura de incentivos, enfocándose en la salud del equipo y así serán ellos mismos los que dirijan el cambio y la mejora técnica necesaria.

Lo esencial

Seguro, como yo, estás harta(o) de todos esos agilistas de teclado en LinkedIn posteando artículos con las mismas imágenes de stock cada 2 minutos sobre las habilidades blandas y abrazar árboles y que se yo.

No significa que estén equivocados. El asunto es que hemos sido engañados cuando se nos inculcó la idea de que nuestro trabajo era exclusivamente técnico y que mientras más pensamiento abstracto, cuanta más concentración, cuanto más aislado estuviéramos; mejor seríamos para este trabajo.

Este trabajo siempre fue sobre resolución de problemas. Las máquinas no tienen problemas. Las personas y las organizaciones tienen problemas. Nosotros somos personas también y nuestros equipos son de personas.

No sé como esta industria ha sobrevivido tanto tiempo entrenando técnicos retrasados socialmente al nivel que tenemos que discutir cosas básicas como empatía, compromiso y una larga lista de otras habilidades esenciales que son parte del curriculum de kinder y primaria.

Y si, habilidades esenciales es un mejor nombre que habilidades blandas. Porque son esenciales para cualquier actividad humana, pero es aún mejor llamar cada una por su nombre: empatía, simpatía, negociación, compromiso, retroalimentacion, elocuencia, argumentación, etc. Hey, no es necesario que seamos todos mega empaticos y máquinas sociales, no se trata de eso. Son solo cosas… esenciales.

Volviendo a enfocarnos en el software, podemos ver cómo estas habilidades esenciales encajan en el día a día de un desarrollo de software y efectivamente tienen efectos muy concretos en la calidad del código.

Refactoring

En el sentido más amplio de refactoring nos podemos referir al hecho de modificar la implementación de una funcionalidad sin afectar el comportamiento observable, con el motivo de obtener beneficios estructurales que permitan simplificar la mantención o extensión de esta funcionalidad.

Normalmente el refactoring es postergado en el nombre de entregar funcionalidades nuevas, hay una inherente presión en contra de dedicar tiempo a tales actividades, pero si no las haces, perjudicas el producto y al equipo al largo plazo. Otro problema es que no se puede esperar a que haya tiempo a hacer todo el refactoring de una sola vez, grandes cambios son más riesgosos, pero ¿Cómo justificas dedicar tiempo a re-hacer una pequeña cosa que ya funciona y no se ve tan mal?

Muchas personas te dirán “Es parte de tu trabajo”, “Lo tienes que hacer”, “Es tu responsabilidad como profesional” o “Si te amonestan por hacerlo, solo dí que es la forma en la que tu trabajas” pero eso viene de una posición de alto privilegio y solo funciona aveces para hombres blancos ya establecidos en la empresa. Para el resto, es más difícil y terminan etiquetados de “conflictivos”, “ingenuos” o “poco alineados con el negocio”

Además, incluso cuando llegue a funcionar, no arregla el problema de fondo. Si hay alguien jugando en contra del refactoring y otro impone su voluntad a fuerza de juicios morales, no arregla el hecho de que hay puntos de vista en un fuerte conflicto, que inevitablemente se manifestarán de otra forma.

Para corregirlo debes entender los incentivos de quienes están en oposición y generar alineamiento. No quieres simplemente que acepten a regañadientes, quieres que acepten de manera entusiasta.

Sin el alineamiento de todos los que participan en las decisiones no podrás realizar mejoras significativas en tu código. Entonces queda claro que tu habilidad de generar código de calidad está restringida por tu habilidad de comunicarte con las personas.

Lograrlo

No es tan complicado como parece, pero es una habilidad como cualquier otra que se debe ejercitar y practicar

En la superficie puede parecer que los intereses del manager están completamente opuestos a los tuyos, pero casi siempre hay un win-win escondido en alguna parte. Por eso debes partir intentando comprender cuáles son sus incentivos (¿Qué los lleva a tomar las decisiones que toma?). Puede ser que no sea lo que piensas.

Puede ser presión política desde su jefatura, puede ser una reputación que quieren ganar o mantener, puede ser que estén buscando un bono a fin de año que necesitan para liberar una deuda, puede ser una infinidad de cosas que se adentran en su mundo personal.

Los seres humanos somos sistemas complicados, operamos bajo un conjunto siempre cambiante de motivaciones e incentivos, muchos de los cuales operan de manera inconsciente. Pero a medida que mejoras tus capacidades de negociación y habilidades blandas en general, comenzarás a entender que es lo que mueve a las distintas personas.

Es un camino largo

Sin importar como sigas, hay veces en que cambiar esos incentivos y motivaciones va a ser muy difícil. Habrá veces que no te será posible lograrlo, al menos, no te será posible con la experiencia que tengas en el momento. Pero aprenderás, mejorarás y cada vez lograrás más cosas.

Para las minorías es aun más difícil

Si no eres parte de la mayoría demográfica, notarás que estas habilidades necesitan ser aun más desarrolladas para lograr un efecto. Esto es porque al ser una minoría se te escucha menos y se te considera menos. Es inevitable sentir desmotivación e injusticia, pero lo puedes lograr. Con trabajo y esfuerzo, sin duda, lo lograrás.

Recuerda: No te limita lo técnico

Lo importante es que tengas en consideración que para escribir código de calidad:

• No te limita el ignorar cuál es el framework de moda
• No te limita el tener tests lentos
• No te limita tu sentido de responsabilidad ni tu “altura moral”
• No te limita tu manager, tu PO, tu cliente ni tu scrum master

Te limitan tus habilidades de comunicación, empatía y negociación.