La semana pasada estuve grabando unos vídeos para el LVL2 de la academia de Automatistas rescatando un aprendizaje del «Santy-programador» del pasado.
Uno que no tenía Make.
Uno que no tenía routers tan bonitos.
Uno que, básicamente, se pegaba con el código hasta que algo explotaba.
O, realmente, con todo lo que pasaba antes para que ese código no explotara.
Fueron un par de lecciones hablando del pseudocódigo como la forma mínima más eficiente de documentar nuestras automatizaciones; y de los distintos tipos de diagramas que nos pueden ayudar a pensar mejor nuestros procesos.
Pero, más allá de eso, la idea que rescato para hoy conecta el tema del pseudocódigo con un tema más profundo: la diferencia entre «hacer automatizaciones» y «saber automatizar» de verdad no está en pensar en el sí… sino en saber diseñar el NO.
Me explico.
Cuando empezamos a automatizar, pensamos en lo que se conoce como happy path: lo que conoces, lo que haces, lo que «sale bien».
Usuario paga → se crea suscripción → todo correcto → fin.
Perfecto. Pero la realidad nunca es perfecta. Y pensar en ello le cuesta bastante a nuestro cerebro (por temas que no voy a contarte para no alargarme mucho).
El caso es que, cuando yo pienso en un proceso que quiero automatizar, sale algo así:
Esto es una nota literal de un proceso que automaticé hace varios años en una academia de danza que trabajaba con MemberPress, Typeform, Stripe y WordPress (entre otras) y que se encargaba de gestionar la baja de una suscripción. Una pequeña pieza de todo el sistema que estábamos montando.
En pseudocódigo se veía limpio:
- Busco la transacción.
- Si la encuentro, sigo.
- Si no, aviso.
- Busco el token.
- Si lo encuentro, sigo.
- Si no, aviso.
- Busco la suscripción en Stripe.
- Si quantity > 1, resto.
- Si quantity = 1, cancelo.
- Si no aparece, aviso.
Fíjate en el patrón.
Yo no resolvía todos los problemas del “no”. No sabía por qué podría no aparecer una suscripción.
No sabía si era un fallo humano, de datos, de sincronización.
Pero sí me anticipaba a que podía ocurrir. Para evitar que Make salte por los aires y te lleguen esos mails que te dan un vuelco al corazón de «🛑 Encountered error in…»
COSORRO.
Por regla general, una automatización no falla «porque sí». Falla porque tú no habías contemplado ese camino. Y ojo: no se trata de obsesionarse con la perfección. Siempre digo que si una automatización no falla es porque no se usa o no le hemos dado el suficiente tiempo
Pero una cosa es aceptar que fallará… y otra muy distinta es ignorar deliberadamente los puntos ciegos.
Saber automatizar no es tirar pelotitas dentro de Make hasta que todo conecta. Es diseñar algoritmos donde cada bifurcación tiene sentido.
Creo que ahí es donde sí subimos el nivel de nuestras automatizaciones.
Y, como casi siempre, eso no lo da la herramienta. Lo da nuestra forma de pensar.
Hasta la siguiente, automatista🫡
Santy.