Sobre mí

Antes de escribir nada intento entender qué problema hay realmente detrás de lo que se pide. Muchas veces la petición inicial y el problema de fondo no son lo mismo, y descubrirlo al final sale caro.

Me interesa el producto entero, no solo mi parte. Saber para quién es, qué tiene que resolver y cómo llega hasta el usuario cambia decisiones técnicas que, mirando solo el código, parecerían indiferentes.

Con el cliente prefiero hablar claro y pronto. Explicar en qué punto está algo, avisar cuando una fecha no va a salir y decir que no sé algo cuando no lo sé. La confianza se construye así, no prometiendo de más.

Trabajo en trozos pequeños que se puedan revisar y probar por separado. Prefiero entregar algo funcionando y ampliarlo que enseñar un proyecto entero cuando ya no hay margen para cambiarlo.

Me adapto al proceso que tenga el equipo. Si el proyecto se lleva con Scrum, entro en las ceremonias y en el ritmo de sprints sin problema; si es algo más ligero, tampoco lo complico. Lo importante es que todo el mundo sepa en qué punto está cada cosa.

Cuando hay presión intento que se note lo menos posible en el trato: priorizar, avisar del riesgo y seguir. Y aprender rápido es parte del trabajo, no un extra: casi siempre hay algo del proyecto que no conozco todavía.

Documento las decisiones que no son obvias y dejo el código legible para quien venga después, que muchas veces soy yo mismo tres meses más tarde.