La incompetencia visible como estado legítimo
Por qué pedí agua mal y qué tiene que ver con diseño de sistemas
Este es el primer texto de este blog. No es un tutorial ni una guía técnica. Es una anécdota real y una idea que me ha tomado años.
Una aclaración antes de seguir: en ingeniería, “hope” suele ser un antipatrón. “Hope is not a strategy.” Lo he escuchado decenas de veces. Este texto propone algo distinto: no esperanza como plan, sino diseño que no depende de que todo salga bien para continuar funcionando.
Una falla mínima en un sistema real
Mi primer viaje internacional fue gracias a una beca para asistir a KubeCon Europa. Iba a Ámsterdam. Siempre sentí fascinación por Holanda. También iba a ver a una vieja amiga. Todo parecía alinearse.
Excepto yo.
No dominaba el inglés. No entonces. No ahora del todo. Desde la universidad venía pensando —todavía sin nombre— en algo que hoy llamo Hope Oriented Programming. No como una teoría formal, sino como una intuición persistente: muchos sistemas están diseñados para humanos ideales, no para humanos reales.
Durante dos meses estudié inglés con disciplina. Me convencí de que prepararse era suficiente.
El primer fallo ocurrió antes de aterrizar.
En el avión, una azafata me preguntó qué quería beber. Respondí con nerviosismo:
I would like a weiter.
Quería agua. Ella no me entendió. Me preguntó tres veces. Yo no entendía por qué no me entendía… hasta que lo entendí: había pronunciado water de forma incorrecta.
Fue una vergüenza pequeña, pero muy clara.
La azafata comprendió, me dio agua y siguió con su trabajo. El sistema continuó.
El estado importa más que el error
Ese momento no fue importante por la palabra mal dicha, sino por el estado en el que me encontraba.
Había estudiado. Conocía la palabra. Pero fallé en tiempo real y en público.
No era ignorancia total. Era incompetencia visible.
Ese estado es incómodo, frecuente y poco tolerado. Y, sin embargo, es el estado natural del aprendizaje real.
Una definición pensada durante años
Con el tiempo entendí que esa escena resumía una idea que vengo trabajando desde la universidad, en distintos contextos: estudio, trabajo, equipos, viajes, sistemas. La he visto repetirse tanto liderando equipos de ingeniería en una startup como siendo el auxiliar de investigación que proveía los recursos de cómputo del laboratorio a estudiantes en todas las etapas —desde pregrado hasta postdocs— cada uno con sus propias formas de fallar y de aprender.
Después de varios años pensándolo, llegué a esta definición:
Hope Oriented Programming no diseña sistemas esperando que todo salga bien; diseña sistemas que no colapsan cuando inevitablemente sale mal.
No es optimismo. No es motivación. Es diseño para la continuidad.
Sistemas que solo toleran humanos competentes
Muchos sistemas fallan no por errores técnicos, sino por supuestos incorrectos.
He visto pipelines de CI/CD donde un typo en un nombre de variable bloquea el deploy sin mensaje claro. He visto PRs donde el revisor expone el error en un comentario público antes de preguntar si había contexto. He visto onboardings que asumen que el nuevo “ya debería saber” cómo funciona el sistema interno de permisos.
El resultado es predecible: la gente finge seguridad, pregunta en privado o abandona.
Un sistema bien diseñado no exige perfección humana para operar. Tolera errores torpes. Tolera estados intermedios. Tolera fricción.
La azafata no corrigió. No expuso. No colapsó. Adaptó.
Eso no fue amabilidad. Fue resiliencia.
Cuando los sistemas grandes fallan
Hay algo curioso con los sistemas grandes y críticos: no los recordamos por el tiempo que funcionan, sino por el momento exacto en que fallan.
Nadie escribe cuando GitHub lleva meses disponible. Pero todos recuerdan cuando GitHub se cayó.
No porque sea frágil, sino porque es central.
Ahí es donde este tipo de diseño se vuelve visible: no en el uptime perfecto, sino en la caída. En cómo se comunica. En cómo se aprende. En cómo se continúa.
Para roles como SRE esto es evidente: los sistemas no se diseñan porque no vayan a fallar, sino porque van a fallar.
La resiliencia no se demuestra en la estabilidad. Se revela bajo estrés.
Cierre
Hope Oriented Programming no propone eliminar el error ni romantizarlo. Propone integrarlo sin humillación y sin colapso.
La esperanza aquí no es una emoción individual. Es una propiedad emergente del sistema.
Este texto no es un punto de llegada.
Es la primera falla visible de este blog: publicar antes de tener todo resuelto.
Si el sistema funciona, habrá un post 1.
