Este artículo es una introspección de toda mi evolución desde que he cambiado de trabajo. Centraré la narrativa en lo que aprendí y no expondré marcas ni empresas.
Mis bases
Llevaba casi 5 años siendo parte de una fábrica de software, pero al mismo tiempo outsourcing; llevando al límite de detalle y cuidado cada una de las aplicaciones que realizaba, alcance un nivel considerable como especialistas en Angular.
Por otro lado, dedicaba mi tiempo libre para aprender de otras tecnologías que me llevaban a romper límites, llevando mi visión del producto mucho más lejos; de hecho muchos de esos proyectos están justo en este blog y el mismo blog incluido.
Cerca de 5 grandes proyectos entregados con éxito, muchos de esos hechos por mí desde el cero absoluto, aplicando patrones de seguridad, rendimiento y diseño, que fui mejorando día tras día a partir de errores y muchas horas leyendo.
El poco reconocimiento que recibí fue por parte de mis clientes, era como si estuviera solo y la empresa que me pagaba no notaba ese crecimiento; mi salario no iba acorde a mi experiencia.
Si eres la persona más inteligente en una habitación, entonces estás en la habitación equivocada.
Me empezaba a aburrir, las tareas eran demasiado fáciles y las lograba analizar a un punto en que contemplaba cada mínimo detalle en cuestión de minutos.
Antes de irme, estuve en una última iteración del producto y realmente fue el feature más demandante y complejo que he hecho en toda mi carrera; me dolió hacer mi último release, pero era claramente hora de partir.
Nuevo Horizonte
Al cambiar hice un salto realmente importante, cambié:
- Presencial/híbrido -> Remoto
- Trabajar solo -> Trabajar en equipo
- Español -> Inglés
- Angular -> React + .Net Core
- Frontend -> Software Engineer (Fullstack y más)
- Nacional -> Internacional
Abandoné la confianza y reconocimiento de mis contactos más cercanos, mi rol favorito, todos mis patrones y una aplicación con casi cero deuda técnica; por integrarme a un nuevo equipo con un ritmo de trabajo muy distinto. Si a esto no se le llama salir de tu área de comfort entonces no sé que lo sea.
Mi experiencia casi al instante se notó al atender cada nuevo feature, me logré integrar super fácil, ya que no debía atender solo yo toda la aplicación.
Lo que me esta costando es dominar tanta deuda y reducir la complejidad técnica para que lo comprendan los stakeholders; ya que no es lo mismo en mi lengua madre que en inglés..
Tampoco se me da bien discutir conceptos tan complejos con arquitectos, ingenieros, DBA y otros; que era de mis reuniones favoritas en mi rol anterior, pero vamos que no llevo ni el año y cada vez me desenvuelvo mejor...
Los features que me rompieron
Han pasado 11 meses, me mantenía en el filo de mi área de comfort (incluso diría que fuera de él) y procuraba entregar todo al máximo nivel que podía dar; hasta que llegó un feature que parecía sencillo..
Consistía en permitir al usuario descargar dos reportes de casi toda la información de la base de datos al darle a sus botones correspondientes. En el Refinement de la historia de usuario incluso pensamos que esta tarea fuera atendida por la misma persona, porque eran muy parecidas y eso fue lo que hice.
Empecé a programar y noté que eran muchas columnas que mapear hacia el reporte, aproximadamente 48 columnas con lógica en cada una de ellas. Mi primer error fue asumir toda la responsabilidad de la estimación sin comunicarlo; me quedé unas cuantas horas fuera de la jornada mapeando información.
Si lo hubiera comunicado, el equipo hubiera tenido más noción de la extensión de la historia y de esa forma pivotando mejor la prioridad del Sprint.
Unos días después, noté unos campos que estaban mal configurados y guardados en base de datos, empecé a armar un script que reemplazara esos campos por la información correcta en todos los ambientes y poder cumplir con lo que deseaba el negocio.
Por suerte eso sí lo comuniqué, sin embargo sí tomé parte de mi tiempo libre para hacerlo, debí ser más transparente para proyectar realmente el tiempo que me estaba consumiendo.
El desenlace
Hubo un primer Sprint donde el primer reporte funcionó y ya me encontraba armando el segundo; pero al subirlo al ambiente el compañero me dice: "El reporte me da un error al descargarlo", el problema era un timeout en la base de datos, debía optimizar la consulta.
Después de preguntar a alguien con más experiencia en el proyecto, tenia la claridad de cuales serian los siguientes pasos y qué debía contemplar; optimicé lo que pude, pero se me acababa el tiempo.
Empezó un segundo Sprint, se volvió a analizar la funcionalidad para que ya no fuera una descarga instantánea; sino que se accionara un job y se enviara por correo; vendiendo la idea de que eso daría suficiente tiempo a la base de datos para consultar toda la información, pero en ningún momento se hizo un cambio a la consulta, solo se cambio la entrega.
Sentí mayor holgura para atender el problema, pero me tocaba ahora armar un job que enviara un correo al cliente con el reporte; aproveché para terminar el segundo reporte y aplicar todas las optimizaciones posibles, pero se acabó el Sprint y aún no tenía la certeza si este último reporte podría ser descargado sin problemas.
El de negocio se enojó por ver que tenía muchas tareas incluidas en la historia de usuario, mi team lead cedió al no poder dar una respuesta clara de sí eran necesarias tantas tareas de optimización; jamás pasó por mi mente preguntar de cuanta data estábamos hablando.
Pasó un tercer Sprint, se suponía que debía solo probar la funcionalidad y no me consumiría tiempo, pero muchas de esas tareas que se movieron surgieron como necesidad y logré reducir la descarga a 1 segundo.
Finalmente logré entregar la funcionalidad, se realizó el release y todos felices porque veíamos que descargaba sin problema y el correo llegaba bastante rápido.
Pero hubo un problema que jamás contemplé, un usuario muy importante en producción que tiene muchísima información no lograba descargar y este es el punto principal que deseo asimilar, debo considerar el volumen de la información e incluso exigir/establecer unos requerimientos claros para probar.
Justo debo volver a establecer esos patrones que creaba solo para mí mismo, en mi equipo y así reducir esos puntos de falla.
De igual forma el de negocio mencionó que prefiere alargar la entrega en vez de entregar algo que no funciona y estoy totalmente de acuerdo; fue una falla técnica de mi parte y que realmente me llena; ya que son problemas en otro nivel y justo busco aprender de eso.
Últimas palabras
Puede parecer tonto el problema, pero llevo años siendo capaz de contemplar cada mínimo detalle de mis funcionalidades, casi llevando a cero los bugs reportados.
En este nuevo trabajo me han surgido bugs, pero suelen ser por falta de conocimiento del negocio, no tanto por una falta de visión técnica. No cabe duda que aprenderé de esto.
