Dunning-Kruger: 3 estadios y el mapa de skills

Después de terminar el tutorial de un lenguaje nuevo llegó la sensación de “ya lo entiendo más o menos”. Meses después, con más experiencia acumulada en el mismo lenguaje, la sensación cambió a “sigo lejos”. Los dos momentos suenan contradictorios, pero son la misma curva pasando por dos puntos distintos.

Kruger y Dunning publicaron en 1999 un estudio en la Universidad de Cornell donde documentaron esa distorsión. Quien tiene capacidad baja en un dominio tiende a sobrestimar la propia capacidad; quien tiene capacidad alta tiende a subestimarla. El efecto no es un fenómeno único, es una curva con tres estadios que casi todo dev atraviesa al aprender una tecnología.

Este artículo desarma la curva en sus tres estadios, muestra cómo detectar en cuál estás y propone un mapa de skills de 5 niveles para no quedarte atorado en el segundo. Fue extraído del capítulo sobre sesgos de aprendizaje y carrera de mi libro de psicología para engineers, pero el argumento central se sostiene por sí solo.

Los 3 estadios de la curva

Estadio 1: sobreconfianza del principiante. Terminaste el tutorial de Python, corriste el hello-world, hiciste el ejercicio final del curso. La sensación de “domino Python” aparece porque tu mapa mental del dominio todavía no incluye las áreas que ni siquiera sabes que existen: manejo estructurado de errores, concurrencia real, empaquetado y distribución, diseño de tests, operación en producción, perfilado de memoria. El principiante no ve el hueco porque el hueco es del tamaño de “todo lo que aún no aprendí”.

Estadio 2: el valle del intermedio. A medida que aprendes más, la frontera de lo desconocido se vuelve visible. Cuanto más sabes, más grande se ve la lista de cosas que te faltan. En este estadio muchos devs pierden confianza, se sienten peor que en el estadio 1, y algunos abandonan el aprendizaje porque interpretan la caída como “no soy bueno para esto”. Es el momento donde más gente se cae de la curva.

Estadio 3: subestimación del experto. Con años de experiencia, lo que haces a diario te parece obvio. Un colega de menos experiencia pregunta cómo resuelves cierto problema y tu primera reacción es “eso lo hace cualquiera”. Solo que “cualquiera” no lo hace, y lo que tú llamas obvio para el experto es exactamente el skill que el resto de la industria quiere contratar. El experto subestima porque el proceso interno se le volvió invisible.

Los tres estadios comparten el mismo mecanismo de fondo: la dificultad para calibrar la propia capacidad con precisión. El síndrome del impostor (que también aparece en ese libro) es el mismo problema mirado desde el otro lado.

Por qué el valle del intermedio es el más peligroso

El estadio 1 tiene un techo natural: tarde o temprano el principiante encuentra un problema que su nivel real no resuelve, y la burbuja se pincha. El estadio 3 es económicamente cómodo: quien llegó ahí ya cobra bien, aunque no reconozca su propio valor. El estadio 2 es distinto. No tiene techo automático que lo termine, y quien se queda ahí puede pasar años sintiendo que no avanza cuando en realidad sí avanza pero cada avance amplía la lista de lo que le falta.

La consecuencia práctica es que muchos devs abandonan un dominio en el valle no porque su capacidad haya dejado de crecer sino porque su sensación subjetiva empeora. Cambian a otro lenguaje, se reencuentran con el estadio 1 (la sobreconfianza del principiante regresa), y unos meses después vuelven a caer en el valle del nuevo dominio. La curva se repite; el dev acumula “casi supe” en vez de “sé”.

Lo que se necesita en el estadio 2 no es más motivación ni menos autocrítica. Se necesita una forma de hacer visible lo que ya sabes, para que el crecimiento del “lo que aún no sé” no aplaste la percepción de lo que ya tienes.

El mapa de skills: 5 niveles por ítem

La contramedida concreta que propongo en el libro es mapear las skills del dominio en 5 niveles. No es una escala arbitraria, es una progresión que corresponde a estados cognitivos distintos:

La distinción entre nivel 3 y nivel 4 es la más importante para el estadio 2. Un dev en el valle suele tener muchas skills en nivel 3 (las usó) pero pocas en nivel 4 (las puede explicar). Esa asimetría genera la sensación de “sé hacer pero no sé por qué funciona”, que es el síntoma clásico del valle. Al listarlas explícitamente en una tabla, el problema se vuelve concreto y accionable: no necesitas aprender más features, necesitas profundizar las que ya usas hasta poder explicarlas.

Cómo armar tu mapa en 30 minutos

El ejercicio cabe en una sesión. Elige un dominio técnico donde te sientes en el valle (React, Kubernetes, Postgres, lo que sea) y haz lo siguiente:

1. Busca el índice de un buen libro o la tabla de contenidos de la documentación oficial del dominio. Copia los temas de primer y segundo nivel a una tabla.
2. Para cada tema, marca tu nivel del 1 al 5 sin pensarlo mucho. La primera intuición es la correcta.
3. Cuenta cuántos ítems tienes en cada nivel. Si el nivel 3 es dominante, estás en el valle. Si el nivel 1 y 5 son dominantes, estás en el extremo del principiante o del experto respectivamente.
4. Elige tres ítems en nivel 3 y planea cómo subirlos a nivel 4. La receta suele ser: leer el capítulo del libro que los cubre, escribir un post explicándolos como si le enseñaras a alguien, y responder una pregunta pública sobre el tema en el foro que uses.
5. Vuelve al mapa en 3 meses y actualiza. Ver los ítems que pasaron de 3 a 4 es la evidencia objetiva del avance que en el valle es imposible sentir.

Cuando aplico este ejercicio a mis propios dominios técnicos, no gano capacidad rápido. Gano algo más útil: una forma de ver el progreso mientras ocurre, en vez de esperar a que la sensación subjetiva se acomode. El movimiento entre revisiones es la evidencia; la sensación llega después.

El mapa vs la métrica

Una tentación cuando se arma este mapa es transformarlo en métrica de performance: contar cuántos ítems tienes en cada nivel y usarlo como puntaje de “qué tan senior soy”. No lo hagas. El objetivo del mapa no es medir tu nivel absoluto, es hacer visible el movimiento entre revisiones. Un dev que pasa de 15 ítems en nivel 3 a 20 ítems en nivel 4 en 6 meses avanzó de verdad, aunque el “total” haya bajado (porque descubrió ítems en nivel 1 que antes no sabía que existían).

Comparar tu mapa con el de otro dev tampoco tiene sentido, por la misma razón. Cada dev tiene un mapa de un dominio distinto, con temas seleccionados desde su experiencia. La comparación válida es con tu mapa de 3 meses atrás.

El efecto Dunning-Kruger no se elimina con este ejercicio; ningún ejercicio lo elimina, porque forma parte de cómo funciona la cognición humana. Lo que se puede hacer es reducir la asimetría entre lo que sabes y lo que sientes que sabes, y darle al estadio 2 una salida que no dependa de que la confianza vuelva sola.

Si Plan Mode fue la herramienta para no ejecutar antes de aprobar (ver mi nota sobre Plan Mode), el mapa de skills es la herramienta para no dejar de aprender antes de reconocer lo aprendido. Los dos son formas de ganarle a la propia intuición cuando la intuición no ayuda.

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev