Cómo trabajo

Para qué sirve esta página

Esta página no es una biografía. Es cómo tomo decisiones, que es lo que necesitas saber para decidir si trabajar conmigo.

¿Dónde he trabajado?

Cinco años repartidos entre una plataforma industrial en producción —pipelines asíncronos, modelos predictivos integrados en el backend, optimización de consultas y refactor del motor de métricas— y antes proyectos con Plone y React, maquetación y animación desde Figma, Next.js, y Angular con personalización de ERPs.

Lo que me pedían a mí y no le pedían a otros del equipo era siempre lo mismo: las métricas, el refactor del motor que las calcula, y meter la lógica de negocio dentro. Ahí es donde soy más útil, y por eso es lo primero que ofrezco.

¿Cómo decido si algo necesita un modelo de inteligencia artificial?

Con una escalera, y no me salto peldaños: heurística, búsqueda vectorial, modelo entrenado. Solo subo cuando el escalón anterior demuestra quedarse corto, no cuando el siguiente suena mejor.

La razón es práctica. Un modelo entrenado no sirve de nada el día que no hay datos, que es exactamente el día en que arranca cualquier producto. Una heurística de reglas con pesos puestos por criterio funciona desde el primer momento, se puede explicar a quien la usa —"te avisamos de esta reserva porque es un cliente nuevo que reservó con tres semanas"— y va generando las etiquetas que el modelo futuro necesitará.

En mis propios proyectos eso está codificado: hay una puerta que comprueba si hay datos suficientes y se niega a entrenar por debajo del umbral, devolviendo la heurística en su lugar. Hoy, en uno de ellos, esa puerta dice que no. Y es la respuesta correcta.

¿Qué hago antes de escribir un arreglo?

Audito, y pido explícitamente que se busquen fallos en lugar de confirmarlos.

Lo he hecho con mis tres proyectos y en los tres salió algo que no esperaba. En el servicio conversacional, once de doce ataques cruzados rebotaron y uno no: un token heredado dejaba ver los títulos de conversación de todos los clientes. En la plataforma de reservas, un grupo grande que ocupaba varias mesas solo registraba la primera, así que la misma mesa se vendía dos veces sin que ninguna restricción pudiera verlo. En el motor de recetas, la regla de "cero consultas dentro del cálculo" se incumplía en tres sitios, y la documentación afirmaba que se cumplía.

En los tres casos había tests, pasaban todos, y el fallo vivía justo en el hueco. Por eso ahora los tests que escribo primero son los de propiedad, no los de resultado: en lugar de comprobar que algo concreto funciona, comprueban que una regla se cumple en todas partes, y que la siga cumpliendo una función nueva que nadie ha escrito todavía.

Una suite de tests en verde mide lo que mide. La pregunta útil no es cuántos tests hay, sino qué caminos no toca ninguno.

¿Y antes de dar por bueno un arreglo?

Escribo el test antes que la corrección y compruebo que falla. Un arreglo sin un test que antes fallara no demuestra nada: demuestra que el código hace algo, no que hace lo que faltaba.

Es lento y es aburrido, y es la diferencia entre entregar algo que funciona y entregar algo de lo que puedes decir por qué funciona.

¿Qué hago mejor y qué hago peor?

Mejor: motores de cálculo sobre volúmenes grandes, consultas lentas, capas conversacionales sobre datos propios, y meter reglas de negocio complicadas dentro de un sistema de métricas sin que se conviertan en un montón de condicionales sueltos.

Peor: gestión de contenidos y encargos de frontend sin lógica detrás. No es que no sepa hacerlo: es que hay quien lo hace mejor y más barato, y yo no aporto nada ahí.

Y donde me atasco, que es más honesto decirlo: con especificaciones ambiguas. Cuando una funcionalidad hacía A, ahora tiene que hacer A y B, y las dos cosas se contradicen. Por eso trabajo mejor con alguien técnico al otro lado que ya ha traducido el problema, y por eso el diagnóstico es siempre el primer paso de cualquier encargo: si algo no encaja, prefiero verlo antes de empezar que a mitad.

¿Dónde estoy?

En les Terres de l'Ebre, al sur de Cataluña. Trabajo en remoto y estoy acostumbrado a hacerlo.