Atascarse es el objetivo

Aprendí a programar en los años en que atascarse era la única opción. Una build que no compilaba y un mensaje de error que no apuntaba a ningún sitio útil. Un concepto que se negaba a encajar por muchas veces que releyera la misma página. No es que estuviera solo con ello. Había toda una escalera para desatascarse: releer la documentación, más despacio. Bajar de la estantería el libro gastado. Rebuscar en un proyecto antiguo que había resuelto algo parecido. Preguntar al compañero de la mesa de al lado, y si el muro sobrevivía a todo eso, redactar el problema con cuidado y publicarlo en un foro, y luego esperar, a veces días, a que respondiera un desconocido con las cicatrices de haber pasado por lo mismo.

Ahora escribo código todos los días con dos modelos al lado, y toda la escalera se ha desplomado en un solo peldaño. Pego el error y la respuesta llega antes de que haya terminado de formar mi propia hipótesis. Eso es aceleración real, y acepto el trato encantado. Pero pasé más de una década subiendo la vieja escalera a mano, y puedo sentir con bastante precisión qué es lo que deja de ocurrir en ese momento. Algo se ponía en marcha en mi cabeza entre peldaño y peldaño, y ahora no llega a tener la oportunidad de arrancar. He señalado ese algo en ensayos anteriores, siempre de pasada. Merece que lo miremos de frente.

Qué hacían las horas de atasco

Estar atascado nunca fue tiempo muerto. Era el estado en el que mi imagen de la máquina se corregía más rápido.

Esto es lo que pasa dentro de un bug que no tiene sentido. Tienes en la cabeza una imagen de cómo funciona el sistema, y el sistema acaba de hacer algo que tu imagen dice que es imposible. Así que haces experimentos. Formulas una hipótesis, la pruebas, la ves fallar, la revisas. Cada conjetura fallida descarta una forma más en que la máquina podría funcionar. Para cuando encuentras el arreglo, el arreglo casi es lo de menos. Lo que hiciste en realidad fue encontrar el punto exacto en el que tu imagen estaba equivocada, y volver a dibujarla.

Incluso dentro del mejor bug, buena parte del tiempo se va en dar vueltas, en reescribir, en comprobar otra vez lo obvio. El aprendizaje vive en los momentos en que una conjetura se encuentra con la máquina y muere. Pero esos momentos no llegan si no te has quedado en la sala durante todo lo demás.

Por eso todavía recuerdo, años después, el bug que se comió una semana, y no consigo acordarme de una sola funcionalidad que saliera adelante sin tropiezos. La funcionalidad que salió sin tropiezos nunca tocó mi imagen del sistema. El bug la redibujó.

Los conceptos que se niegan a encajar funcionan igual. Les das vueltas, pruebas un enfoque, lo ves venirse abajo, pruebas otro. Cuando la idea por fin aterriza, aterriza sobre una estructura que construyeron tus intentos fallidos, y por eso se queda. La lectura, la documentación y la revisión también corrigen una imagen, y me apoyo en las tres. Pero una corrección solo se sostiene allí donde un intento le ha hecho sitio. La explicación que recibes antes de haber peleado con el problema resbala. La misma explicación después de veinte minutos de conjeturas fallidas aterriza, y se queda.

La vieja escalera era lenta, y la lentitud no era todo desperdicio. Para preguntar al compañero o al foro, primero tenías que comprimir el problema en una pregunta que otra persona pudiera responder, y la compresión por sí sola resolvía la mitad. Cualquiera que haya terminado alguna vez una descripción cuidadosa y la haya borrado sin publicarla, con la respuesta de pronto en la mano, conoce el efecto. El libro tampoco te entregaba nunca la respuesta a secas; te obligaba a leer el capítulo que la rodeaba, y en ese capítulo es donde se evitaban los tres bugs siguientes. Y mientras esperabas una respuesta, tus propios experimentos seguían en marcha, porque esperar con las manos vacías era insoportable. Había ayuda en cada peldaño. Solo que llegaba lo bastante despacio como para que siguieras pensando mientras tanto.

La desaparición es silenciosa

Ahora mete un modelo en el bucle. La build se rompe, pegas el error, llega el arreglo, sigues adelante. Medido en resultados, esto es estrictamente mejor, y no voy a fingir lo contrario. El problema es el aspecto que tiene el trato desde dentro. Nada en ese momento lo delata. El diff es idéntico al que habrías escrito tras tres horas de pelea. El historial de commits de alguien que entiende el sistema y el de alguien que ha externalizado todos los muros son exactamente iguales, justo hasta el día en que dejan de serlo.

Porque el código nunca fue el producto de esas tres horas. El producto era la imagen corregida, y el código era su recibo. Toma el atajo y sigues llevándote el recibo, mientras la imagen sigue equivocada de una forma que ninguna suite de tests va a sacar a la luz. El que nunca se atasca mientras aprende no va por un camino más rápido hacia el mismo destino. Va por un camino rápido hacia otro distinto, con soltura para producir software del que tiene una imagen endeble, y esa endeblez solo se nota el día en que la IA que tiene al lado se equivoca y nada en su interior lo sabe.

La versión nostálgica se equivoca

Buena parte de aquello en lo que me atascaba no me enseñó nada que valiera las horas. La caza del punto y coma que faltaba. La build que se rompía por un accidente del entorno que nadie podría haber previsto. El flag sin documentar, el conflicto de versiones, la tarde perdida con una herramienta que sencillamente era mala. Esos muros me enseñaron algo de folclore de herramientas, y el folclore de herramientas es exactamente la carga que las máquinas transportan ahora mejor de lo que yo lo hice nunca. Disolver esa clase de muro al instante es para lo que están las herramientas.

Las horas de atasco que me construyeron eran de otra clase, y distinguir las dos clases es todo este ensayo. Eran las horas en las que el obstáculo era mi propia imagen equivocada. El sistema seguía sus propias reglas, mi idea de esas reglas no, y la pelea era el proceso de descubrirlo. Una clase era un impuesto. La otra era matrícula.

Se pueden distinguir antes de que llegue la respuesta, no solo después. Pregúntate si el muro está dentro del problema o al lado. Un conflicto de versiones está al lado del problema: resolverlo no cambia nada de cómo vas a escribir el siguiente programa. Una función que devuelve un valor que tu imagen dice que es imposible está dentro: resolverlo cambia lo que sabes. En caso de duda, trata el muro como si estuviera dentro durante veinte minutos y observa si tu comprensión se mueve.

Elegir dónde atascarte

Así que la habilidad ha cambiado de forma. Antes era resistencia, porque atascarse era obligatorio en todas partes. Ahora es opcional en todas partes, lo cual lo convierte en un presupuesto, y la habilidad es saber repartirlo.

El mío lo gasto de forma deliberada. Cuando el trabajo de retrieval que hago para dominios legales y de salud se comporta mal de una manera que me sorprende, entro a mano, porque la sorpresa significa que mi imagen del sistema está equivocada, y esa es la clase de atasco que compensa. Aunque la sorpresa es una señal que hay que ganarse. Solo salta allí donde existe una imagen detallada que la realidad pueda contradecir, y por eso la prueba para principiantes de más arriba pregunta por el muro, no por la sensación. Cuando un agente en el que he delegado tropieza en un sitio que yo podría haber previsto, dejo que las herramientas lo absorban, porque a esa fricción ya no le queda nada que enseñarme. El pipeline de delegación que construí existe precisamente para poder soltar los muros de los que ya lo he aprendido todo. Los que no, los sigo escalando yo, a propósito, más despacio de lo que podría.

Delega sin culpa. El desarrollador que siente una vaga vergüenza cada vez que el modelo lo desbloquea tiene el marco equivocado, como si la virtud viviera en la fricción misma. Nunca vivió ahí. La fricción nunca fue más que el medio para llegar a la imagen. Gástala donde tu imagen todavía sea endeble.

Y gastarla no es sentimentalismo, es economía. A medida que generar código se abarata, el trabajo que conserva su precio es distinguir el resultado correcto del incorrecto, y ese criterio se construye con imágenes corregidas. El hábito, además, se transfiere. Cada bug que obliga a poner una hipótesis a prueba contra un sistema en marcha es una repetición del mismo gesto que más tarde caza una sugerencia equivocada en código que no has visto nunca. Llega una afirmación segura de sí misma, y algo en ti sabe que hay que comprobarla.

Si estás aprendiendo ahora

Atáscate a propósito, y atáscate en pequeño. Elige problemas de un tamaño tal que atascarse signifique veinte minutos de pensar de verdad, no un fin de semana perdido. Lo que quieres es contacto frecuente con tu propia imagen equivocada, en piezas lo bastante pequeñas como para poder atravesarlas.

Inténtalo tú primero, siempre. Escribe tu versión rota, formula tu conjetura sobre el bug, y luego trae a la IA, y tráela como el tutor que revisa tu intento, no como el chófer que te lleva de largo por delante del problema. Pregúntale dónde falló tu razonamiento, no solo cuál es la respuesta. Discute con ella. La corrección del tutor aterriza precisamente porque tu intento construyó el sitio donde encaja. Sáltate el intento y las mismas frases no enseñan nada.

Después, ponte a prueba. Apaga la IA y reconstruye la cosa, y mientras la reconstruyes, di por qué está ahí cada parte, como si tuvieras a un compañero al lado preguntando. La reconstrucción a secas se puede fingir de memoria, repitiendo las teclas que viste pulsar. El porqué no. Si las dos cosas sobreviven, las horas de atasco hicieron su trabajo y la comprensión es tuya. Si no, tienes en la mano el recibo de un aprendizaje que nunca ocurrió, y es mejor descubrirlo ahora, en algo pequeño, que dentro de un sistema que lleva tu nombre.

Las máquinas te van a ofrecer una salida de cada muro durante el resto de tu carrera, y la mayoría de las veces deberías aceptarla. Muchos muros son ruido, y despejar ruido es para lo que están las herramientas. Los muros adecuados son donde se construye tu imagen de la máquina. Aprende a distinguirlos, rechaza la salida justo en esos y deja que el muro haga su trabajo. Atascarse en los muros adecuados es el objetivo.