Cómo trabajo
Del problema a producción.
La buena ingeniería de software no consiste solo en escribir código que funcione. Para mí empieza por entender el problema, tomar decisiones técnicas deliberadas, construir la solución adecuada y quedarme el tiempo suficiente para ver qué pasa en producción.
Como Staff Software Engineer y Tech Lead, trabajo en todo ese recorrido: desde las primeras preguntas sobre un problema hasta la arquitectura, la implementación, el producto y, finalmente, producción.
Problema
Entender el problema antes de elegir la solución.
En la práctica
Una aplicación crítica para la empresa necesitaba actualizar continuamente información a medida que evolucionaba el producto. Sin embargo, introducir y modificar esos datos se había vuelto cada vez más complejo para los equipos que debían mantenerlos.
El problema no estaba solo en una aplicación que se había quedado antigua. Su modelo de datos y su evolución no habían acompañado los cambios del producto, haciendo que tareas que deberían ser sencillas requiriesen cada vez más intervención técnica.
Durante años, esa complejidad hizo que IT terminase haciéndose cargo de una tarea que correspondía a otros equipos. Aprovechamos un cambio importante en el producto para replantear el sistema: rediseñamos el modelo de datos para hacerlo más adaptable y permitimos que los propios equipos pudieran mantener la información sin depender de IT.
La mejor solución técnica suele empezar por entender dónde está realmente el problema.
Arquitectura
Diseña para las restricciones que de verdad importan.
En la práctica
El sistema tenía que poder adaptarse a cambios frecuentes en el producto sin que cada cambio obligase a modificar la estructura de la aplicación.
Rediseñé el modelo de datos para separar las definiciones del producto de la estructura central del sistema, utilizando una composición más flexible que permitía añadir o modificar elementos sin romper los datos existentes ni el histórico.
Esto también cambió quién podía trabajar con el sistema. Los equipos de desarrollo podían mantener directamente la información, sin que cada actualización dependiera de una intervención de IT.
La pregunta importante no era cuánto podía optimizar la arquitectura, sino cuánto podía simplificar el cambio.
La arquitectura no debe optimizar para el sistema que tenemos hoy, sino para la forma en que sabemos que va a cambiar.
Código
Mantente lo bastante cerca del código para liderar de verdad.
No necesito escribir cada línea de un sistema para liderar su ingeniería. Pero sí necesito entender la implementación lo bastante bien como para cuestionar decisiones, investigar problemas difíciles y aportar código cuando el problema lo exige.
En la práctica
Los estándares de ingeniería que introduje —TypeScript estricto, calidad de código con SonarQube, seguridad con Aikido, requisitos de testing, revisiones estructuradas y despliegues automatizados— salieron de problemas reales que encontré construyendo, no de una lista de buenas prácticas.
Se adoptaron en toda la organización porque cada uno resolvía algo que el equipo ya había sufrido.
El liderazgo técnico no ocurre por encima del código. Ocurre junto a él.
Producto
Construye lo que importa, no lo que mejor queda en un diagrama.
En la práctica
Modernizar el backend de una tienda podría haber significado reescribirlo desde cero. No lo fue.
Lo migré progresivamente a una arquitectura serverless, manteniendo la compatibilidad con el sistema existente, sin downtime y sin exigir un lanzamiento coordinado.
La alternativa era técnicamente atractiva: un sistema nuevo, más limpio y diseñado desde cero. Pero también implicaba asumir todo el riesgo de cambiar de una vez un sistema que el negocio necesitaba seguir utilizando. Una reescritura habría sido más limpia de diseñar, y mucho más cara si nos equivocábamos.
La decisión fue priorizar la evolución sobre la sustitución: mejorar la arquitectura sin convertir la modernización en un proyecto que tuviera que esperar a estar terminado para empezar a aportar valor.
La versión elegante de un sistema vale poco si el negocio tiene que detenerse mientras la construyes.
Una buena ingeniería no consiste en maximizar la calidad técnica de una solución aislada. Consiste en encontrar el equilibrio entre calidad, valor de producto, velocidad de entrega y capacidad de evolucionar después.
No siempre hay que construir el sistema ideal. Hay que construir el siguiente paso correcto.
Producción
El sistema real empieza cuando llegan los usuarios.
En la práctica
Una aplicación que solía caerse durante las campañas de ventas la migramos a una nueva plataforma cloud.
El cambio eliminó el problema de capacidad: la aplicación pasó a absorber picos de tráfico de hasta 10× sin degradarse.
Años después, tuvimos que modernizar la aplicación. La rediseñamos para funcionar sobre una arquitectura serverless, reduciendo tanto los costes de infraestructura como el esfuerzo necesario para mantenerla.
La experiencia de la primera migración también cambió cómo abordamos la segunda: esta vez diseñamos el cambio alrededor de cero downtime y compatibilidad total hacia atrás, porque ya sabíamos dónde estaba el riesgo real.
Lo arriesgado de una migración casi nunca es el sistema nuevo. Es la transición.
Producción te da información que el desarrollo no puede darte: tráfico real, fallos reales, costes reales y comportamiento real de los usuarios.
Por eso considero la infraestructura, la observabilidad, la entrega y la evolución continua parte de la ingeniería, no algo que pasa después de terminar el código.
El valor
El valor no está en que a alguien le guste una idea. Está en lo que resuelve.
Una idea puede parecer buena. Una funcionalidad puede tener sentido sobre el papel. Pero si no aporta algo al usuario o al negocio, construirla es simplemente invertir tiempo en algo que no importa.
Antes de desarrollar algo, intento responder dos preguntas:
- —¿Qué valor obtiene el usuario?
- —¿Qué valor obtenemos nosotros?
Si no podemos responderlas con claridad, probablemente todavía no tenemos una funcionalidad que construir.
En la práctica
Muchas de las decisiones más importantes no consisten en decidir cómo implementar una funcionalidad, sino en decidir si merece la pena implementarla.
Cuando aparece una nueva propuesta, intento entender qué problema resuelve, para quién y qué valor aporta como producto o como empresa.
A veces sabemos qué queremos conseguir y pensamos en una funcionalidad como medio para conseguirlo. En ese caso, hay que preguntarse qué estamos pidiendo al usuario para obtenerlo: información, tiempo, atención o esfuerzo. Y qué obtiene él a cambio.
Otras veces partimos de la dirección contraria: creemos que una funcionalidad puede ser útil para los usuarios. Entonces la pregunta es distinta: ¿qué problema resuelve realmente? ¿Cuántos usuarios tienen ese problema? ¿Y es lo suficientemente importante como para justificar el coste de construirla, mantenerla y hacer que la utilicen?
En ambos casos, la pregunta es la misma: ¿qué valor aporta?
Por eso hay funcionalidades que no se implementan. No porque sean técnicamente difíciles, ni porque la idea sea mala, sino porque todavía no hemos encontrado una propuesta de valor suficientemente clara.
Construir menos también puede ser una decisión de producto.
El bucle
La ingeniería es un ciclo.
No los veo como etapas aisladas ni como un proceso lineal. Producción cambia cómo entendemos el problema. Los nuevos requisitos cuestionan la arquitectura. El código revela suposiciones. Los usuarios cambian lo que creíamos que el producto necesitaba.
Y el ciclo vuelve a empezar.
Liderazgo técnico
Ser Tech Lead no significa tener todas las respuestas. Significa ayudar al equipo a tomar mejores decisiones técnicas.
A veces es diseñar una arquitectura. Otras, cuestionar una suposición, simplificar una solución sobrediseñada, investigar un problema difícil, escribir una pieza de código crítica o ayudar a otro ingeniero a encontrar un enfoque mejor.
El rol cambia según el problema. La responsabilidad, no:
Mantener la tecnología avanzando en la dirección correcta mientras ayudas a que el equipo tenga éxito.
Quiero seguir cerca de la tecnología mientras asumo una responsabilidad más amplia sobre los sistemas y productos que construimos.
01
Suficiente distancia para ver el sistema completo.
02
Suficiente cercanía para entender el código.
03
Suficiente responsabilidad para que me importe lo que pasa en producción.
Contacto
¿Hablamos?
Abierto a conversaciones sobre arquitectura, plataformas y equipos. La forma más rápida de contactarme es LinkedIn.
