Contratación y equipo: la curva de aprendizaje real

La frase no vas a encontrar gente que sepa Elm es verdadera y casi siempre irrelevante, y entender por qué es lo primero requiere separar dos preguntas que la frase funde en una. La primera es cuántas personas conocen hoy el lenguaje, y la respuesta es pocas. La segunda es cuánto tarda una persona competente en ser productiva en él, y la respuesta cambia por completo la conclusión que se sigue de la primera. En tecnologías grandes esas dos preguntas se responden juntas porque el tiempo de aprendizaje es tan largo que la experiencia previa es un activo decisivo: contratar a alguien que ya conoce un ecosistema con años de acumulación, sus convenciones tácitas, sus herramientas y sus trampas históricas, ahorra meses que no se pueden comprimir. En un lenguaje que cabe en una tarde y que no ha crecido en años, ese ahorro es de días, y un activo que vale días no puede sostener una decisión estratégica. La objeción de contratación no es falsa: está mal calibrada, porque aplica a un lenguaje pequeño y estable una intuición formada en lenguajes grandes y móviles.

Los tres tramos de la curva

-- El lenguaje entero, en la practica, cabe en este inventario
-- definicion de funcion y firma
-- if then else y case of
-- registros y su actualizacion
-- type alias y type con variantes
-- let in
-- listas, tuplas y un punado de operadores
-- modulos con lista de exportacion

-- Y esto es lo que no hay que aprender porque no existe:
-- clases, herencia, interfaces, sobrecarga, macros, decoradores,
-- bucles, excepciones, valores nulos, conversiones forzadas

El primer tramo es la sintaxis y el vocabulario del lenguaje, y dura días. No es una exageración retórica sino una consecuencia del tamaño: Elm tiene definiciones de función, expresiones condicionales, coincidencia de patrones, registros, tipos personalizados, alias, un puñado de operadores y poco más. No tiene clases, ni herencia, ni interfaces, ni genéricos con restricciones, ni sobrecarga, ni macros, ni decoradores, ni bucles, ni excepciones. Y no tiene, sobre todo, la acumulación histórica de varias formas de hacer lo mismo que en otros lenguajes obliga a distinguir lo idiomático de lo obsoleto. Una persona con experiencia lee el lenguaje entero en una sesión larga y escribe código correcto al segundo día, con el compilador corrigiéndola de forma explícita y didáctica.

El segundo tramo es la arquitectura, y dura semanas. Aquí no se aprende, se desaprende, y por eso cuesta más de lo que la simplicidad de las piezas sugiere. Quien viene de un modelo de componentes con estado propio trae automatismos profundos: guardar información en el nodo que la usa, disparar un efecto como consecuencia inmediata de una interacción, pensar la pantalla como un árbol de objetos vivos. En Elm no hay nada de eso, y la dificultad no está en entender el bucle, que se explica en diez minutos, sino en dejar de buscar el sitio donde poner el estado local. La señal de que este tramo se ha superado es concreta: la persona deja de preguntar cómo se hace un componente y empieza a preguntar dónde vive ese dato.

El tercer tramo es el modelado con tipos, y no se agota en meses. Es la diferencia entre representar un formulario como un registro con campos opcionales y un booleano de carga, y representarlo como un tipo con las variantes que el proceso admite de verdad. Ese salto no lo enseña el compilador porque ambas versiones compilan, y es exactamente donde se produce la diferencia visible entre alguien con seis semanas y alguien con dos años.

Vale la pena insistir en que estos tres tramos no se recorren en serie sino solapados, y que su coste no es proporcional a su dificultad aparente. El primero se percibe como el obstáculo porque es lo primero que se encuentra y lo único que tiene nombre reconocible; se supera casi sin darse cuenta. El segundo se percibe como frustración y suele expresarse como una queja sobre el lenguaje —esto es demasiado verboso, faltan atajos— cuando en realidad es el síntoma de estar buscando una construcción que no existe. El tercero rara vez se percibe, porque quien está en él ya produce código que funciona y nadie le señala que podría no admitir estados imposibles. De ahí una consecuencia práctica para la incorporación: los dos primeros tramos se resuelven con documentación y compilador, pero el tercero solo se transmite en revisiones de código donde alguien con criterio propone el tipo mejor y explica qué deja de poder ocurrir.

-- Tramo tres, version de la semana dos: compila y admite estados imposibles
type alias Model =
    { cargando : Bool, datos : Maybe Datos, error : Maybe String }


-- Tramo tres, version madura: los estados imposibles no se pueden escribir
type Estado
    = Inactivo
    | Cargando
    | Cargado Datos
    | Fallido Error

El mercado se invierte: no se contrata, se enseña

De lo anterior se sigue una consecuencia que suena provocadora y es simplemente aritmética. Si el conocimiento específico del lenguaje se adquiere en días, entonces exigirlo como requisito de entrada reduce el conjunto de candidatos en varios órdenes de magnitud a cambio de ahorrar un tiempo trivial. Es una de las peores relaciones entre coste y beneficio que puede tener un criterio de selección. Los equipos que trabajan con Elm desde hace años y publican sobre ello coinciden en la misma práctica: contratan personas con buen criterio de programación y sin experiencia previa en el lenguaje, y las incorporan en un plazo que se mide en semanas, no en trimestres.

Lo que sí cambia es qué se busca en la selección. Deja de importar el catálogo de tecnologías del historial y pasan a importar dos señales. La primera es la disposición a desaprender, que se detecta preguntando por una ocasión en que la persona cambió de opinión sobre una práctica que defendía. La segunda es el gusto por modelar el problema antes de escribir la solución, que se detecta pidiendo que diseñe los tipos de un dominio pequeño antes de implementar nada. Ambas señales predicen el rendimiento en Elm mucho mejor que cualquier lista de herramientas conocidas.

Hay además un efecto de selección que conviene nombrar sin idealizarlo. Un anuncio que menciona Elm filtra a los candidatos por curiosidad técnica antes de la primera conversación, y ese filtro suele producir un conjunto más pequeño y de mejor ajuste. El efecto es real y está bien documentado por equipos que lo han usado deliberadamente, pero tiene un límite obvio: funciona mejor cuanto más atractivo sea el resto de la oferta, y no compensa por sí solo condiciones malas.

La incorporación, con esa curva en la cabeza, se diseña de otra manera. La primera semana no consiste en leer la base de código sino en escribir tres programas pequeños y completos, porque el tramo uno se agota escribiendo y no leyendo. La segunda y la tercera consisten en tareas reales pero acotadas dentro del proyecto, elegidas para que atraviesen el bucle entero: un mensaje nuevo, una rama de update, un campo del modelo y una vista que lo muestre. A partir de ahí, lo único que acelera de verdad es la revisión de código con foco en los tipos, no en el estilo. Un equipo que sigue ese orden mide autonomía en semanas; uno que empieza pidiendo que la persona nueva lea diez mil líneas antes de tocar nada mide lo mismo en trimestres, y después atribuye la lentitud al lenguaje.

El riesgo que sí existe

Queda por nombrar una asimetría de la que casi nunca se habla y que afecta a la retención más que a la contratación. Trabajar con una tecnología minoritaria produce dos efectos opuestos sobre las personas del equipo. Por un lado, quien disfruta de la disciplina que impone suele quedarse más tiempo, porque encuentra difícil volver a un entorno donde las garantías dependen de la vigilancia. Por otro, hay quien percibe que su tiempo invertido no se traduce en una línea del historial profesional que otras empresas valoren, y esa percepción es un motivo de salida real que no se resuelve con argumentos técnicos. La mitigación honesta consiste en dos cosas: dejar claro que lo que se aprende —modelado con tipos algebraicos, diseño de estados, separación de efectos— es transferible a cualquier lenguaje moderno, y no fingir que el mercado laboral pide Elm cuando no lo pide.

Descartado el riesgo falso, queda el verdadero, y es serio. No es que no haya candidatos: es que el conocimiento se concentra. En un equipo de veinte personas donde cuatro escriben Elm y las dieciséis restantes no, esas cuatro se vuelven el único camino para cualquier cambio en la interfaz, la revisión de código se estrecha, las vacaciones se notan y una salida duele. El fenómeno no lo causa el lenguaje sino la adopción parcial sin plan de difusión, y se agrava porque la baja fricción de aprendizaje hace que nadie sienta urgencia por extenderlo hasta que ya es tarde.

Las mitigaciones son conocidas y baratas si se aplican pronto. Formar en pares desde el primer día en lugar de reservar el código a quien ya lo domina. Mantener el proyecto sin construcciones ingeniosas, que en Elm es fácil porque el lenguaje no las ofrece. Escribir la documentación de arquitectura pensando en quien llega, no en quien ya está. Y establecer un objetivo explícito de cuántas personas deben poder tocar la interfaz sin ayuda, revisándolo cada trimestre como se revisa cualquier otro riesgo operativo.

Hay un matiz que juega a favor y que conviene tener presente al evaluar el riesgo de salida. Cuando alguien deja un equipo que trabaja con una tecnología grande, se lleva consigo un conocimiento tácito considerable: qué librerías se eligieron y por qué, qué trampas tiene cada una, qué partes del código siguen una convención antigua y cuáles la nueva, qué hay que evitar tocar. En un proyecto de Elm bien mantenido ese conocimiento tácito es mucho menor, porque el lenguaje no admite convenciones divergentes, el estado está en un solo sitio, los tipos documentan las transiciones y las dependencias son pocas y explícitas. La persona que se va sigue siendo una pérdida, pero se lleva menos consigo, y esa diferencia es exactamente la que hace que el riesgo de concentración sea gestionable en lugar de existencial.

-- Lo que sustituye al conocimiento tacito: el tipo dice el proceso entero
type Suscripcion
    = Prueba { expira : Instante }
    | Activa { renueva : Instante, plan : Plan }
    | Vencida { desde : Instante }
    | Cancelada { motivo : Motivo }

-- Quien llega no necesita preguntar que estados existen ni que datos
-- lleva cada uno: estan escritos, y el compilador obliga a tratarlos todos

flowchart LR
A[Dia uno] --> B[Sintaxis del lenguaje]
B --> C[Semana dos: bucle y arquitectura]
C --> D[Mes tres: modelado con tipos]
D --> E[Autonomia plena]
F[Riesgo falso: no hay candidatos] --> G[Se disuelve al medir el tramo uno]
H[Riesgo real: conocimiento concentrado] --> I[Formacion en pares y difusion]
style B fill:#a6e3a1,color:#11111b
style D fill:#cba6f7,color:#11111b
style G fill:#89b4fa,color:#11111b
style H fill:#f38ba8,color:#11111b