El Senior Egoísta

La semana pasada subí al escenario de T3chFest a contar algo que me daba vergüenza. Esto es la versión extendida de esa charla, con las referencias y el contexto que no caben en 50 minutos.

Cuando mandé la propuesta de esta charla en noviembre, pensaba que iba a hablar de mentoring. De cómo los seniors deberían compartir más. Un tema importante, pero tranquilo.

Desde entonces han pasado cosas. Han salido modelos que hacen cosas que hace cuatro meses parecían ciencia ficción. El 84% de los developers ya usa herramientas de IA. La velocidad a la que se genera código no tiene precedente.

Y me di cuenta de que el problema del que quería hablar no era un "estaría bien mejorar esto." Es urgente. Porque la charla no va de IA. Pero la IA es lo que la hace urgente. Porque lo que de verdad importa son las personas. Y lo que pasa cuando las personas dejan de compartir lo que saben justo en el momento en que más falta hace.

Todo empieza con una frase.

"Soy el único que sabe cómo funciona esto."

A lo mejor la has dicho. A lo mejor la has escuchado. Yo la he dicho muchas veces. Con orgullo. Se siente bien. Se siente como que eres importante, como que eres imprescindible.

Pero es una trampa.

La migración que hice solo

Hace unos años lideré una migración crítica: adaptar un sistema que gestionaba pedidos en almacenes para que funcionara también en tiendas. En la práctica, era convertir un software single-tenant en multi-tenant. Cada tienda tenía que ver solo sus pedidos, sus rutas, su inventario. Un cambio profundo en la arquitectura que afectaba a casi todo el sistema.

Lo hice prácticamente solo. No porque nadie pudiera ayudar (tenía un equipo capaz). Pero el sprint cerraba el viernes, era más rápido si lo hacía yo, y "ya explicaré cómo funciona cuando esté terminado." Nunca encontré el momento.

Una mañana, el sistema falló. Las tiendas estaban viendo pedidos de otras tiendas. Un problema de aislamiento de datos (exactamente el tipo de bug donde necesitas entender las decisiones de diseño para saber dónde buscar). Mi equipo no podía diagnosticarlo. No porque fueran malos ingenieros. Porque nadie más que yo sabía cómo se había implementado la separación de tenants. Tuvieron que localizarme para arreglarlo.

Lo que más me fastidió no fue el incidente. Fue que la culpa era mía. No por un bug. Porque había construido un sistema donde solo yo podía apagar el fuego.

Nos pasamos la carrera diseñando sistemas sin puntos únicos de fallo. Réplicas, backups, rollbacks. Y luego nos convertimos exactamente en eso para nuestros equipos: un single point of failure, pero en versión persona.

Lo que más me dolió no fue lo técnico. Mi equipo no solo estaba frustrado con el sistema. Estaban frustrados conmigo. Tenían el talento para resolver aquello, pero yo no les había dado las herramientas.

El egoísmo que no sabes que tienes

Durante años pensé que mi caso era un problema de disciplina. De no documentar, de no hacer pair programming, de tener siempre algo más urgente. Y es verdad, todo eso influye. Pero hay algo más profundo que me costó mucho más entender.

En mi artículo sobre heurísticas invisibles escribí sobre la investigación de Gary Klein con comandantes de bomberos veteranos. Klein les preguntó cómo tomaban decisiones cuando un edificio se quemaba. Todos dijeron: "No tomamos decisiones. Simplemente seguimos el procedimiento."

No era verdad. No por malicia (no eran conscientes de que estaban decidiendo). En realidad reconocían patrones a toda velocidad y actuaban sin deliberar. En el 80% de los casos, lo primero que se les ocurría era lo que ejecutaban. Y funcionaba.

Polanyi lo había descrito: "Sabemos más de lo que podemos decir." Conocimiento tácito. Se adquiere con experiencia, no con instrucción. No se puede transmitir fácilmente porque el propio experto no sabe que lo tiene.

Los ingenieros seniors hacen exactamente lo mismo. Cuando algo falla a las 3 AM, miran unas pocas señales y algo les dice "mira ahí." No empiezan por el código (empiezan por los síntomas). Clasifican antes de investigar. Saben qué ignorar. Miles de horas comprimidas en intuición.

Esto cambia cómo entiendo mi propia historia. Aquella mañana de tiendas viendo pedidos de otras, el problema no era solo que yo no había documentado la migración. El problema es que había heurísticas en mi cabeza (sobre cómo falla un sistema multi-tenant, sobre dónde buscar cuando el aislamiento de datos se rompe, sobre qué mirar primero) que yo ni siquiera sabía articular. No es que no quisiera compartirlas. Es que no sabía que las tenía.

El conocimiento más valioso que un senior tiene es exactamente el que no sabe que tiene. Y si no lo hace visible, se va con él cuando se va.

Es un egoísmo involuntario. Pero el resultado es el mismo.

El gap que se está abriendo

Todo lo anterior existía antes de la IA. Seniors que no compartían conocimiento, bus factors bajos, conocimiento tácito que desaparecía con la rotación. Es un problema viejo.

Lo que la IA cambia es la velocidad a la que se agrava.

Como escribí en El código que nadie entiende ya está en producción, estamos llenando producción de sistemas que ningún humano comprende del todo. La IA permite producir desde el día uno a una velocidad increíble. Pero las heurísticas que permiten operar esos sistemas (diagnosticar, debuggear, tomar decisiones bajo presión) se construían con fricción. Peleándote con un bug durante horas. Viendo cómo alguien con experiencia resolvía algo delante de ti. Tocando código en producción y sintiendo las consecuencias.

La IA absorbe exactamente esas tareas. Es como darle un dron que apaga fuegos pequeños a un bombero novato. Genial. Pero cuando llega el incendio de verdad, nunca ha sentido el calor.

Hay una generación entrando al mercado que produce más que nunca pero con menos modelos mentales. Y otra que tiene los modelos pero no los comparte. Ese espacio entre las dos se está abriendo. Y no es culpa de nadie (es una consecuencia del cambio). Pero alguien tiene que cerrarlo.

La vida media de una línea de código es de unos 3 años. La esperanza de vida de un yogur. Pero el conocimiento que le pasas a una persona se compone. Esa persona se lo pasa a otra. Y cinco años después hay un equipo entero que toma mejores decisiones por algo que compartiste una tarde.

La IA hace que el código sea cada vez más barato. Lo caro es el contexto. Y el contexto solo se transmite entre personas.

Cuatro formas de hacer visible lo invisible

La buena noticia: esto se resuelve entre personas. No con herramientas. Con personas hablando con personas.

En la charla compartí cuatro prácticas. Las cuatro son puentes entre el senior que no sabe que sabe y el junior que no sabe lo que no sabe.

1. Documenta el porqué, no el qué

En un commit, un mensaje, un documento (da igual el formato). Tres preguntas: qué problema resuelve, qué decidí, y qué descarté y por qué.

Los caminos que NO tomaste son las heurísticas invisibles hechas visibles. Es exactamente lo que Klein hacía con los bomberos: extraer las decisiones que el experto no sabía que estaba tomando. No estás escribiendo documentación. Estás escribiendo una carta a la persona que viene después de ti.

Si hubiera documentado por qué implementé la separación de tenants como lo hice (y qué alternativas descarté) mi equipo habría podido diagnosticar aquel fallo sin mí.

2. Debugging en voz alta

Directamente inspirado en el Critical Decision Method de Klein. Cuando alguien con experiencia investiga un problema, que narre su proceso: "Estoy mirando los logs del gateway porque la latencia sugiere que el problema está antes del servicio, no dentro."

Cada frase es una heurística invisible hecha explícita. Funciona en cualquier formato (en persona, por Slack, por llamada). Lo que importa es que el razonamiento quede en algún sitio.

Y hay un bonus inesperado: al narrar tu proceso, descubres cosas de tu propio razonamiento que ni sabías.

3. Preguntas que nadie hace

Una sesión al mes. Sin filtro. "¿Por qué esta tabla tiene 47 columnas?" "¿Por qué este servicio se llama OrderProcessor si valida inventario?"

Cada pregunta sin respuesta es deuda de conocimiento. Y las preguntas más valiosas suelen ser las que parecen más obvias (porque son las que el equipo lleva años evitando).

Si eres junior, tienes un superpoder que no sabes que tienes: la capacidad de preguntar sin asumir que las cosas son como deben ser. No la pierdas. Y si eres senior: tu reacción en el primer segundo cuando alguien pregunta algo "obvio" dicta si volverá a preguntar.

4. El documento del bus

Escribe las tres cosas que harían que te llamaran de vacaciones. Solo tres.

Cuando lo escribes, te asustas de cuánto vivía solo en tu cabeza. Y después sientes alivio. Porque ya no estás solo con ese peso. Tu equipo puede funcionar sin ti. Eso no te hace menos valioso. Te hace libre.

Personas al fin y al cabo

Los bomberos de Klein no eran más inteligentes que los novatos. Tenían una biblioteca de patrones más rica. Y los mejores encontraron formas de pasar esa biblioteca a los nuevos. No por obligación. Porque entendían que su trabajo no terminaba en apagar el fuego. Terminaba cuando los novatos podían apagarlo sin ellos.

El código es un medio, no un fin. Y las personas son el centro.

Y lo que sabemos no es nuestro. Es de todos los que van a venir después.

Pregunta para ti: ¿Cuánto de lo que sabes vive solo en tu cabeza? Si te fueras mañana, ¿tu equipo podría funcionar sin llamarte?