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
Un sistema que reconstruí parecía un problema de aplicación: la herramienta era antigua y había que sustituirla.
El problema real era organizativo. Cada cambio de regla en el producto exigía un despliegue de ingeniería, así que un equipo entero dependía, en la práctica, del tiempo de ingeniería.
Ese replanteamiento cambió la solución por completo. No necesitábamos una aplicación mejor. Necesitábamos un modelo de datos que permitiera a gente sin perfil técnico cambiar las reglas de forma segura.
La mejor solución técnica suele empezar replanteando el problema.
Arquitectura
Diseña para las restricciones que de verdad importan.
En la práctica
Diseñé ese sistema con composición y atributos flexibles, desacoplando las definiciones de reglas del modelo de datos central.
Los cambios en una definición no invalidaban datos existentes ni el histórico, y no exigían migraciones de esquema.
La restricción para la que optimizaba no era el rendimiento ni la elegancia arquitectónica. Era mucho más simple:
¿Con qué frecuencia esta decisión obliga a un despliegue coordinado?
La arquitectura, al final, es tomar decisiones de compromiso. Prefiero sistemas lo bastante simples para entenderlos, lo bastante pragmáticos para construirlos y lo bastante flexibles para que evolucionen.
La complejidad tiene que ganarse su sitio.
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 sido una reescritura. No lo fue.
Lo migré a una arquitectura serverless manteniendo compatibilidad total hacia atrás, sin downtime y sin un lanzamiento coordinado.
Una reescritura habría sido más limpia de diseñar, y mucho más cara si nos equivocábamos.
A veces la solución técnicamente elegante no es la mejor decisión de producto.
La versión elegante de un sistema vale poco si el negocio tiene que detenerse mientras la construyes.
Una buena ingeniería significa entender el equilibrio entre calidad técnica, valor de producto, velocidad de entrega y capacidad de evolucionar después.
Producción
El sistema real empieza cuando llegan los usuarios.
En la práctica
Una plataforma que solía caerse durante las campañas de ventas la migramos de un servidor a la nube.
Tras la migración, la plataforma absorbió picos de tráfico de 10× sin degradarse.
La migración posterior de esa misma plataforma a serverless se diseñó en torno a cero downtime y compatibilidad total hacia atrás, porque para entonces ya sabía 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é obtenemos a cambio como producto o empresa. Y especialmente, qué estamos pidiendo al usuario para conseguirlo.
Porque pedir información, tiempo o esfuerzo al usuario también tiene un coste.
Si queremos que alguien nos dé algo, tenemos que ofrecer algo a cambio.
El usuario no tiene ninguna razón para completar un proceso, aportar información o utilizar una funcionalidad si no entiende qué obtiene a cambio.
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.
