Aprender a mentorizar sin haberlo aprendido

Cuando me tocó mentorizar a alguien por primera vez, lo primero que pensé fue algo que no esperaba: esto me suena.

No el proceso. El recién llegado. Ese gesto de asentir más de la cuenta para que no se note que no has entendido del todo, esa prudencia excesiva al tocar algo que ya funciona por miedo a romperlo, esa energía que compensa el vértigo. Me vino a la cabeza algo que llevaba años sin hacerme pensar: yo también había sido esa persona.

El sitio donde aprendí a tener miedo

Mi primer entorno profesional no era precisamente uno diseñado para crecer.

Era una empresa con historia, surgida del boom de las .com, con sus bases bien asentadas y pocas ganas de moverlas. El jefe técnico de entonces valoraba el código complejo y difícil de leer como señal de profundidad. Lo sencillo le parecía poco serio. Así que lo que aprendí al principio fue a no entender nada, a no tocar nada y a sentir que el trabajo solo no era suficiente para crecer. Después llegaba a casa y estudiaba. En un sector donde todo evoluciona de golpe, no había otra.

No lo cuento como queja. Lo cuento porque cuando ese recién llegado se sentó delante de mí, reconocí en él ese mismo peso que yo había cargado al principio. Y me hice una pregunta que no supe responder del todo bien: ¿en qué momento dejé de ser él?

Él

Acababa de terminar el grado superior. Se notaba que tenía miedo a las tareas que le pudiera dar, pero las ganas que traía eran más grandes que el miedo, aunque él no lo sabía todavía.

Lo primero que hice mal antes de hacerlo bien fue casi caer en el error más habitual: darle las tareas más aburridas y sencillas para que no rompiera nada. Es lo que se suele hacer con quien llega nuevo. Es también lo peor que puedes hacer.

Cuando le asignas solo lo trivial a alguien que viene con ilusión, no lo estás protegiendo. Lo estás aburriendo. Le estás dando a entender que no confías en él, que su papel aquí es rellenar huecos. Le quitas la ilusión antes de que tenga tiempo de transformarla en algo útil.

Cómo estructuré los primeros días

Los primeros días son los más importantes. No para enseñar código, sino para enseñar a pensar.

Le pedí que dedicara esa primera etapa a conocer el negocio en el que trabajábamos. Que entendiera qué problema resolvíamos, para quién y por qué alguien pagaría por eso. Luego le pedí que estudiara el lenguaje que usaríamos juntos, no para dominarlo, sino para dejar de tenerle miedo. Y por último, que hiciera un mini clon del producto: que analizara qué funcionalidades tendría, cómo fluirían los datos por dentro, qué piezas necesitaría y cómo se conectarían. Todo sin escribir una línea de código.

Eso último le costó. Estaba acostumbrado a que le dijeran qué hacer y ponerse a teclear. Pero saber qué estás construyendo antes de construirlo no es un lujo, es la diferencia entre ensamblar piezas y diseñar algo. Un desarrollador que no entiende el sistema que toca no puede tomar buenas decisiones. Le puedes enseñar sintaxis en días, pero el carácter analítico se cultiva desde el principio o se cultiva tarde.

Tres lecciones que le doy a todos

No son mías. Las fui aprendiendo a base de necesitarlas y no tenerlas. Se las doy a todos los que empiezan.

La primera es preguntar.

Lo primero que le digo a cualquiera que entra nuevo es: no me molestas. Mi objetivo no es que sigas necesitándome — es que llegue el día en que tenga que ser yo quien acuda a ti, porque tus aprendizajes y tu forma de hacer las cosas me aporten algo que yo todavía no he visto. Agradezco cada pregunta, independientemente de lo tonta que crea que es. Cada pregunta es una duda resuelta, un aprendizaje mío sobre cómo piensa, y a veces una corrección que yo necesitaba. Si alguien se bloquea y no pregunta, no está siendo discreto. Está perdiendo el tiempo de los dos.

Y esto no vale solo para el equipo. La misma dinámica tiene que aplicarla con el cliente: preguntar, preguntar y preguntar hasta entender muy bien qué quiere y cómo lo quiere. El desarrollador que asume en vez de preguntar construye cosas que nadie pidió.

La segunda es leer.

Este trabajo va de leer y comprender. La documentación oficial de las herramientas que usas, los artículos técnicos que explican el porqué además del cómo, los textos que son densos y que te cuesta pero que te dejan algo. Es muy fácil pasar el día leyendo artículos cortos que te dan la respuesta sin el razonamiento. Te dan la solución pero no el criterio. Y el criterio es lo que necesitas cuando la solución estándar no encaja.

La tercera es documentar.

El cerebro tiene el mismo problema que la RAM: es volátil. Gastamos energía real en retener ideas que podrían estar escritas en diez segundos. Le digo siempre lo mismo: escribe, lo que sea, donde quieras, aunque sea de forma vaga. Ya lo irás perfeccionando. Lo importante es que salga de la cabeza y quede en algún sitio.

El efecto secundario de documentar es que cuando le preguntas cómo lleva una tarea, qué dudas tiene o cómo plantea resolver algo, él tiene notas a las que recurrir. No improvisa. Piensa en voz alta con sus propios registros como apoyo. Eso cambia completamente la calidad de esas conversaciones.

Nuestro trabajo no es escribir código

Esto es lo más difícil de transmitir al principio porque contradice la idea que casi todo el mundo trae cuando empieza.

Escribir código lo puede hacer cualquiera. Ahora también la IA. Lo que no se puede automatizar fácilmente es la metodología: saber qué preguntar antes de empezar, cómo procesar la información que te llega incompleta, qué decisiones tomar cuando hay tres opciones y todas tienen costes, cómo comunicar lo técnico a quien no es técnico. Eso es lo que hace valioso a un desarrollador con el tiempo. Y eso se puede desarrollar desde el primer día, si se le da la oportunidad.

El junior que nunca perdí

Hay algo que me resulta curioso cada vez que mentorizo a alguien.

Invariablemente, con el tiempo, la persona que estás formando empieza a verte como un punto de referencia. Te admira de una forma que casi siempre te parece desproporcionada. Y yo raramente lo he sentido como algo del todo merecido, porque llevo dentro al mismo junior que se fascina con el trabajo de los demás.

Sigo leyendo sobre tecnologías nuevas con la misma energía con la que lo hacía a los 13. Sigo explorando repositorios de GitHub y preguntándome cómo habrán resuelto tal problema. Sigo viendo vídeos densos y técnicos, y también esos que simplemente te muestran una propiedad de CSS que no conocías.

Perder eso es la ruina del progreso. Tendemos a infravalorar al recién llegado, a pensar que no puede con nada, olvidando que nosotros también hemos sido esa persona. Y cometemos el error de asumir que la experiencia equivale a dejar de maravillarse. No tiene por qué.

Si tuviera que decirte dos cosas que me han acompañado desde antes de que esto fuera mi carrera, serían estas: papel y boli, y preguntar. Todo lo demás ha cambiado. Eso no.