Perdí una semana por un fallo que debería haber sobrevivido

Una vez perdí buena parte del trabajo de una semana por un único fallo. No porque el fallo en sí fuera alguna catástrofe extraña: fue una interrupción ordinaria y anodina, de esas que ocurren todo el tiempo. Perdí la semana porque no había guardado nada por el camino. Así que una interrupción que ocurrió a unos minutos del final tiró por la borda días de progreso acumulado, y no había forma de recuperar nada. Sencillamente se había esfumado, y había sido esfumable todo el tiempo sin que yo me diera cuenta.

Lo doloroso, visto en retrospectiva, es lo completamente evitable que era. El fallo no destruyó mi trabajo. Lo que lo destruyó fue que yo no hubiera hecho mi trabajo capaz de sobrevivir.

El optimismo silencioso de dar por hecho que terminará

Había construido mis procesos de larga duración como si siempre fueran a ejecutarse limpiamente de principio a fin, sin interrupciones, cada vez. Sin guardar ningún estado intermedio. Sin forma de recuperarse a mitad de camino. Solo arrancarlo, dejarlo correr y dar por hecho que llegaría hasta el final. Si me hubieras preguntado directamente si esa suposición era segura, habría dicho que no. Pero nunca me lo había preguntado, así que seguí construyendo sobre ella de todos modos.

Este es un tipo de optimismo omnipresente y casi invisible: dar por hecho, en silencio, que el camino feliz es el único camino. Diseñas para el mundo en el que todo sale bien, porque ese es el mundo que estás imaginando mientras construyes. Y luego lo lanzas al mundo real, que tiene muchos otros caminos, la mayoría de ellos menos agradables.

Cualquier cosa que se ejecute el tiempo suficiente será interrumpida

He aquí la verdad que me había negado a contemplar en mis planes. Cualquier proceso que se ejecute durante el tiempo suficiente acabará, tarde o temprano, siendo interrumpido. Un fallo. Un corte de corriente. Una máquina que se queda sin memoria. Un error de mi parte. Un reinicio que no podía esperar. La causa concreta no importa, y hay más causas de las que puedes enumerar.

A corto plazo, la interrupción es un riesgo. En un horizonte lo bastante largo, deja de ser un riesgo y se convierte en una certeza. No es cuestión de si algo de larga duración acaba siendo interrumpido, sino solo de cuándo y con qué frecuencia. Y una vez que lo ves así, diseñar como si no fuera a ocurrir queda al descubierto por lo que es: planear, deliberadamente, equivocarte sobre algo que tiene garantizado ocurrir.

El coste lo fija lo que guardaste, no el fallo

Esta es la idea que reorganizó cómo pensaba sobre todo ello. El daño de una interrupción está determinado casi por completo por cuán recuperable era tu trabajo, no por cuán grave fue la interrupción. El fallo rara vez es la variable que importa. Lo que importa es lo que hiciste de antemano.

Exactamente el mismo fallo, golpeando en exactamente el mismo momento, te cuesta cinco minutos si habías guardado tu progreso hace poco, o cinco días si no habías guardado nada en absoluto. La interrupción es idéntica en ambos casos. La consecuencia es radicalmente distinta, y la diferencia quedó determinada por completo por una decisión que tomaste antes, mucho antes de que llegara el fallo. El fallo no decide cuánto pierdes. Lo decides tú, por adelantado, al decidir cuánto estabas dispuesto a hacer recuperable.

Hacer checkpoints es aritmética, no paranoia

Una vez que lo planteé así, los argumentos para guardar el estado intermedio con regularidad dejaron de parecer una cautela excesiva y empezaron a parecer pura aritmética. La interrupción es segura con el tiempo. El coste cuando ocurre está acotado por cuánto hace que guardaste por última vez. Así que guardar con frecuencia no es más que un seguro barato contra un evento garantizado, con una prima que puedes fijar tan baja como quieras simplemente guardando un poco más a menudo.

Negarse a hacerlo no es valentía, ni concentración, ni avanzar rápido. Es solo mala aritmética: rechazar una protección barata contra algo que ocurrirá con seguridad, a cambio de una pequeña comodidad ahora. Me había estado felicitando por no perder tiempo en redes de seguridad, mientras corría en silencio un riesgo enorme y sin asegurar contra un evento que ni siquiera estaba en duda.

Diseña para reanudar, no solo para reiniciar

Hay, sin embargo, un nivel más allá del guardado periódico, y es el que más importó. El arreglo más profundo consiste en construir el trabajo de larga duración de modo que una interrupción reanude desde donde se detuvo, en lugar de empezar de nuevo desde el principio.

Esta distinción lo es todo cuando las interrupciones son frecuentes. Un proceso que reinicia desde cero cada vez que lo derriban puede, en un entorno lo bastante malo, no terminar nunca: cada interrupción borra todo, y si llegan con la frecuencia suficiente en relación con el tiempo de ejecución, no avanzas nada por mucho que te esfuerces. Un proceso que reanuda, en cambio, siempre avanza. Puede ser derribado una y otra vez y aun así, tarde o temprano, llegar, porque cada interrupción cuesta solo lo poco que hubo desde el último guardado. Reiniciar es frágil de una forma que se acumula; reanudar es robusto de una forma que se acumula en la dirección contraria.

El mismo principio, casi en todas partes

Esto se generaliza mucho más allá de cualquier cómputo de larga duración. Se aplica a casi cualquier trabajo cuyo valor se acumula con el tiempo y se pierde si no se preserva de forma deliberada. El patrón es idéntico: el progreso se va acumulando, llega una interrupción, y todo lo que no se hizo duradero desaparece.

Así que la pregunta que aprendí a hacerme, sobre cualquier cosa que lleve un rato y que importe, ya no es la cómoda —“¿y si esto se interrumpe?”—, sostenida con distancia como una hipótesis. Es la versión contundente, la de dar-por-hecho-que-ocurrirá: “cuando esto se interrumpa, ¿cuánto perderé?”. Esa pregunta, hecha pronto, cambia lo que construyes. La primera pregunta te deja esperar. La segunda te obliga a prepararte.

La lección más profunda: la interrupción es un evento programado

A lo que todo se reduce es a que dejé de diseñar para el mundo en el que todo sale bien, y empecé a diseñar para el mundo en el que las cosas salen mal de forma rutinaria, porque el segundo es el mundo que realmente existe, y el primero nunca fue más que una suposición agradable que yo había sustituido en silencio por la realidad.

La resiliencia, llegué a entender, no es pesimismo. Es exactitud. La interrupción no es una hipótesis remota que descartar con optimismo. Es, en efecto, un evento programado: lo único que pasa es que no te dicen la fecha. Construir como si fuera a llegar no es sombrío ni temeroso. Es solo ser honesto sobre el único mundo en el que hay para construir. Perdí una semana aprendiendo que el fallo nunca fue el problema. El problema era que había construido algo sin forma alguna de sobrevivir a ser interrumpido, en un mundo donde ser interrumpido está garantizado.

— Sin señales, sin rendimientos, esto no es asesoramiento de inversión.