fbpx

No te hagas trampas (parte 2)

Hablemos de errores y lecciones.

El lunes terminaba la última sesión del Desafío Automatista… y hablamos de fallos garrafales que yo he ido cometiendo desde que metí la cabeza en la automatización.

Normalizar el fallo me parece una de las mejores maneras de quitar el miedo a trastear cuando alguien está empezando.

A automatizar se aprende fallando, jugando y probando. No existe el botón mágico 🤷🏻‍♂️ que te devuelve 3h de tiempo libre al día.

¡Ojalá!

Por eso a veces pienso que los tutoriales perfectos en procesos complejos pueden llegar a frustrar cuando, al intentar aprender, intentas replicarlos y no salen a la primera.

Esa fue la principal razón por la que decidí hacer el Desafío con sesiones en directo.

(Aunque luego tiene otras cosas del otro lado y por eso ahora me pillas pensando si las próximas ediciones deberían seguir el mismo formato, pasar a grabado, hacer un mixto… o no existir. Seguiremos informando)

El asunto. Que me despisto.

En esa lista de cagadas cometidas aparecían, de uno u otro modo, las 4 lecciones que aprendí programando y de las que te empecé a hablar la semana pasada.

Sí. Porque una cosa es tener las lecciones… y otra cosa muy distinta que puedas seguir cayendo en los mismos fallos 👇🏻👇🏻

Te recuerdo la lista y paso a contarte las 2 + 1 que me dejé en el tintero:

  1. Tu memoria es más frágil de lo que crees
  2. Hazlo simple (y recicla)
  3. Eso no va a funcionar a la primera
  4. No eres tan especial

Eso no va a funcionar a la primera

Estoy convencido de que la probabilidad de hacer que una automatización funcione a la primera es extremadamente baja.

Podemos intentar aumentar esa probabilidad usando las 2 lecciones anteriores (documentarlo todo y reutilizar conocimientos pasados) y aún así no nos escapamos a que eso falle.

Y no está mal. Simplemente hay que tenerlo en cuenta.

Es más, te diría que la probabilidad de que la automatización falle es inversamente proporcional al número de pruebas que hemos hecho antes de decir “perfecto, esto está listo”.

Aquí el consejo es claro y triple:

  1. Haz pruebas parciales de las principales partes de tu proceso automatizado (MAke, por ejemplo, te permite arrancar un módulo independiente para ver cómo se comporta).
  2. Móntate un “patio de juegos” antes de jugar en primera división. Utiliza cuentas secundarias para hacer experimentos, crea copias de los documentos para probar los primeros intentos, etc
  3. Haz copias de seguridad ante posibles desastres.

Si saltas sabiendo que puede romperse la cuerda… o añades una segunda cuerda o empiezas saltando desde menos altura.

(O las dos).

No eres tan especial

También podría haber llamado a esto como “no intentes inventar la rueda” o bautizarlo como el efecto “Da vinci”.

A veces, cuando vamos a automatizar un proceso, nos creemos únicos: pensamos que nuestro caso es extremadamente particular y complejo, que a nadie jamás se le ha ocurrido algo así y que nos espera una travesía en el desierto porque “eso no se puede hacer, qué pena”.

Antes de ponerte a automatizar dedícale un buen rato a pensar y a buscar alternativas.

La capacidad de saber buscar bien (googlear, si nos ponemos modernos) creo que está infravalorada. Y es oro puro realmente.

Cuando empiezas a buscar bien pueden pasar varias cosas:

  1. Que, como era de esperar, alguien ya ha pasado por ese mal trago antes y ha sido capaz de solucionarlo y explicar cómo hacerlo. Esto te lo vas a encontrar en foros, plataformas de dudas o incluso en la propia documentación de la herramienta que nos empeñamos en no mirar (como las instrucciones del microondas, sí.)
  2. Que existe otra herramienta con la que puedes hacerlo muchíiiiiisimo más sencillo y está pensada especialmente para ello, sin que tú tengas que inventar la rueda haciéndolo a medida. Aquí te toca valorar el coste de migración pero, por lo general, meterte a automatizar un proceso que ya ha implementado, paquetizado y probado un equipo entero de desarrollo… suele ser mala idea.
  3. (Esta es preciosa) Al “explicarle” a Google tu problema te vas dando cuenta, sin querer, que el planteamiento no era válido y que tenías otra forma de hacerlo que sí sabes resolver.

Ese momento eureka suele ser porque o bien no hemos pensado lo suficiente antes de entrar en faena… o no hemos aplicado tampoco el consejo final 😇

(extra) Déjalo reposar un rato

Sí, el tuit que le vi a Dani el otro día es otra de esas soft skill infravaloradas que solo aprendes con la experiencia:

Cuando algo se atasca… ¡déjalo reposar! Seguir metiéndole horas y estrujando las neuronas hasta el infinito casi nunca es la mejor opción.

Párate, sal a dar un paseo, deja que te dé el aire o incluso consúltalo con la almohada.

No sabes la cantidad de veces que he resuelto problemas complejos “en sueños” y me he despertado con la solución perfecta.

(Spoiler: cuando pienses que, estando mentalmente agotado has llegado a la solución, revisa el principio del correo. Mañana puede aparecer un fallo que no habías pensado porque no te quedaban neuronas 🧠🧠🧠)

Es más.

Como me comentaba Antonio Sánchez, otro suscriptor de la newsletter, cuando empiezas a trabajar esa capacidad para detectar a tiempo que estás en un punto de bloqueo… rentabilizas muchísimo mejor tu trabajo.

Pues al final parece que sí me había servido de algo lo de aprender a programar, mira tú…

Oye, ¿tienes tú alguna lección de vida que pueda aplicarse a la automatización?

Compártelo por Twitter y comentamos.

Te leo con atención hasta el próximo jueves

(Bueno, y después también te seguiré leyendo con atención)

Saludos!👋🏻

Santy

PD: hoy no había ninguna posdata, pero me gusta reservar el espacio.

¿Tu primera vez por aquí?

Cada jueves envío un e-mail con un consejo accionable para mejorar tu relación con el tiempo y que puedas dedicárselo a lo que realmente importa.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Acepto la política de privacidad *