Hola — soy Liliana.Hago ingeniería de software, lidero equipos de ingeniería y tomo el café que mantiene ambas cosas en marcha.

Soy ingeniera de software y líder de ingeniería. Mi trabajo abarca toda la forma de un sistema: arquitectura, backend, frontend y los asuntos de producción que van en medio — porque una funcionalidad no está terminada hasta que se comporta bien donde están los usuarios.

Llevo años construyendo para la web en toda la pila: interfaces, sistemas de backend, APIs, productos SaaS, medios y tecnología publicitaria, y la infraestructura de producción que los mantiene en marcha. Ese rango va desde HTML semántico y layouts de correo hasta plataformas operativas internas, reproductores de video, publicidad interactiva y juegos de navegador.

Mis ecosistemas principales son JavaScript/TypeScript y PHP. Hoy me siento más en casa con Vue y Laravel — pero son preferencias, no límites. Elijo (y aprendo) tecnología según el problema, porque el problema es quien decide.

He llevado aplicaciones en producción a través de las generaciones mayores de PHP — desde código de la era 5.x hasta versiones con soporte actual — y migrado sistemas construidos con frameworks viejos hacia otros modernos. Ese trabajo me sigue enseñando la misma lección: la deuda técnica es normal; ignorarla indefinidamente, no. El software en producción no siempre puede detenerse mientras todo se reescribe, así que la modernización funciona mejor en pasos verificados e incrementales que dejan el sistema más fácil de mantener de lo que lo encontraste.

Tengo inclinación por las soluciones prácticas y mantenibles. Me gusta la arquitectura aburrida que resuelve el problema, las pruebas que hacen seguro el cambio y la refactorización en pasos verificables. Cuando un sistema tiene historia — casos especiales, decisiones viejas, clientes dependiendo de sus rarezas — trato esa historia como información, no como obstáculo.

Por eso también me siento cómoda trabajando con sistemas existentes, no solamente con proyectos desde cero. Leer con cuidado el código de otra persona, entender por qué es como es y mejorarlo sin romper lo que funciona: eso es un oficio, y es la mayor parte del trabajo real de software.

Una cosa más sobre cómo trabajo: cuando me contratas, hablas directamente con la persona que hace la ingeniería. Sin gerentes de cuenta, sin capas de traducción entre tu problema de negocio y el código. Y me hago responsable de lo que construyo — quiero entender el problema detrás del ticket, no solo cerrarlo.