El comienzo del cambio

Cuando comencé hace 2 años en la empresa que actualmente me encuentro, llegué con un equipo bastante bueno. Liderado por una dev bastante talentosa: Cecilia Torres.

Tabla de contenido

1. Mi primer encuentro formal con la deuda técnica
2. La influencia implícita de la implementación de pruebas unitarias
3. Lo aprendido de esta parte del camino
4. La implementación personal
5. Agradecimientos

❕ Mencionó dev, sin referirme a títulos como tal para evitar hacer distinciones

Ceci, líder de un equipo con 3 miembros: Saul Sáenz, Luis Vega y Tito Placencia. Quienes se encargaban de mantener 3 proyectos principalmente. Al llegar me asignaron con Luis Vega, para colaborar con el proyecto que el tenia a cargo.

Como dato, el team se nombró: HackstreetBoys, antes de que entrará… entonces me tocó ser parte de este increible equipo

Mi primer encuentro formal con la deuda técnica

En los primeros meses mi cabeza estaba 🤯🤯🤯, no solo por el cambio de ambiente, tecnologías, cuestiones técnicas, etc… Sino por el equipo como tal con el cual estaba. Pero da la casualidad de que Ceci comenzó con un reto llamado: “Killing the Tech Debt“, honestamente no recuerdo si era exclusivamente para el proyecto que llevaban entre Saul y Tito o si era general, el objetivo era identificar puntos de oportunidad en el o los proyectos, reportarlos, trabajarlos y/o documentarlos y por cada aspecto que se tratará sumabas puntos, al final quien más puntos tuviera era el ganador y obtenía un premio, si mal no recuerdo.

Este fue el punto inicial y de partida para que le tomara mucha más importancia al tema de seguir haciendo las cosas lo más modulares posibles, tratando de hacer las ya no solo reutilizables sino también escalables y abstractas.

La influencia implícita de la implementación de pruebas unitarias

Personalmente no hice actividad alguna relacionada con el reto, principalmente porque era relativamente nuevo y nunca había tocado el proyecto.

Comentar este punto es importante, ya que a los aprox. 2 años después y con mi evolución, he aprendido que al igual que yo; muchos de los compañeros, ya sea por miedo, pena, las posibles criticas y demás… puede que no se sientan cómodos o seguros al participar activamente, he de aquí que se hace clara la razón por la cual normalmente la participación es baja en ciertas actividades como a lo que se le llama: Xxxx Talks, internamente… No lo mencionó porque realmente no se si pueda 😅😅🤭🤭

Desde hace tiempo me llevaba preguntando el como manejar o cambiar esa parte en el equipo en donde me encontraba principalmente, pero no tenía el conocimiento hasta ahora, y lo que hay que tomar en cuenta es algo llamado: Psycological Safely o Seguridad Psicológica, si mal no recuerdo es el término.

Ya que había pocas o nula cantidad de pruebas en el proyecto, moverle significaba la propensión a tener un impacto muy alto si algo fallaba. Poco después de esto entre los lideres de equipo (Ceci Torres y Jesús Escamilla), se comenzó a difundir la parte de las Pruebas Unitarias.

Fue aquí en donde comencé “de lleno” con la implementación de las pruebas unitarias, pero como el framework que se usaba era Vue 2 y Vue 3 y yo no manejaba ninguno… Me aventé a hacerlo en un “entorno seguro”, por decirlo de alguna forma, experimentando con un proyecto que ya tenia desarrollado con Angular y Firebase, esto fue mucho de ayuda porque, si bien Angular le agrega un poco de complejidad por su forma de hacer las cosas y quizá te lo complica un poco al inicio a largo plazo ayuda, pude aprender, entender y comprender muchas cosas que posteriormente me sirvieron para llevar a cabo la implementación de pruebas unitarias hacia Vue. Además de que si fundamentos o las bases con las mismas, los conceptos cambian un poco o la implementación es distinta, a final de cuentas fue pensar: “Ok si yo lo hago de esta forma con X herramienta como hago lo mismo en esta otra” y era el extrapolar los casos de uso que ya había realizado.

Lo aprendido de esta parte del camino

Hasta este momento, aprendí la importancia de manejar lo mínimo de deuda técnica posible, la importancia de implementar pruebas unitarias, la forma divertida y diferente de incentivar la participación y la colaboración entre los compañeros con el fin de lograr un objetivo en común, técnico y que beneficia al proyecto

La implementación personal

Debido a que surgieron estos temas… justamente me decidí a comprobar si el efectivamente era muy difícil el implementar las pruebas en el transcurso del desarrollo y desde el inicio, con un proyecto sin pies ni cabeza, sin objetivos o requerimientos bien definidos y que comenzara con simples operaciones CRUDs (Create, Read, Update, Delete).

El resultado y la respuesta: No, no es difícil, únicamente requiere de paciencia, dedicación, esfuerzo y si acaso algo de experiencia.

Con esto, no quiero decir que para todo mundo sea fácil o que a la primera te va a salir… pero hay varias cosas a tomar en cuenta:

– De los errores se aprende: Inténtalo y si fallas, no te des por vencido ni te desesperes, si no funcionó busca otro enfoque para poder hacerlo, el chiste es que salga de una u otra forma
– Itera y remueve la procrastinación: Si lo intentaste, funcionó pero al tiempo encontraste o viste una mejor forma de hacerlo, has un refactor y documenta el cambio, de ti, de tu proceso, del enfoque y de los objetivos, para que los demás puedan aprender de tus fallas
– Reduce la deuda técnica: El dejar deuda técnica es peligroso, por los riesgos y cambios que van surgiendo y más si son pocas personas dentro del desarrollo, ya que hay muchos puntos críticos en donde la supervivencia del proyecto y de tu trabajo mismo corre peligro
– Deja de buscar y poner pretextos: Es muy sencillo dar cualquier excusa para no hacer las cosas, sal de tu zona de confort y dale la oportunidad, además es buena forma de adquirir experiencia y aprender mil y un cosas en el camino

El querer es poder, y si aunque suene a cliché, pero es cierto… si no sabes busca, pregunta, investiga… el momento, ocasión o situación va a llegar y si no llega… Crea el momento y ocurra esa oportunidad

Obviamente esto que comentó es teniendo en cuenta la conciencia de los limites, riesgos, el coste-beneficio y el que tanto estas dispuesto a arriesgar con tal de que ese cambio ocurra.

Para finalizar, como Staff Manager he aprendido y he descubierto que esta parte que involucra el ser Staff Manager, y con todo el peso que involucra, me gusta… y lo último pero muy importante, para cerrar con Broche de Oro, es darle las gracias a todas aquellas personas que me han apoyado, que han estado ahí y con las cuales me he apoyado para conocer, aprender y crecer. (Obviamente hablando y centrado desde el enfoque profesional, porque del personal también hay varias personas a las cuales agradecer).

Agradecimientos

Muchas gracias… por enseñarme, guiarme, aprender juntos… por todos esos momentos tanto divertidos, como de incertidumbre o duda por ciertas cosas que hacer o que se presentaron en el camino… desde la perspectiva técnica me han ayudado directa e indirectamente a crecer, ni hablar de la personal porque también han aportado ciertas cosas.

Una persona por ser reconocida como el “genio” de algo, no necesariamente lo convierte en el mejor sino es el mejor por todo ese background, por todas esas personas que hacen o hicieron posible ese reconocimiento. Y el reconocimiento no solo es para el genio sino para todos con los que el genio trabaja.

Espero que me haya expresado bien o que se haya entendido pero si no… trataba de hacer referencia a The Genious Myth o El mito del Genio (Winters, 2020, 28)

• Cecilia Torres
• Saul Sáenz
• Tito Placencia
• Jesús Escamilla
• Laydy Martinez
• Fernando Flores
• Alejandro Lopéz
• Marco Ortiz

Winters, T. (2020). Software Engineering at Google : Lessons Learned from Programming Over Time. https://openlibrary.telkomuniversity.ac.id/home/catalog/id/167353/slug/software-engineering-at-google-lessons-learned-from-programming-over-time.html