Hay tareas que parecen claras desde el momento en que llegan.
Crear un pipeline. Automatizar un proceso. Desplegar algunos recursos con Terraform.
Ya hiciste algo parecido. Hay código que puedes tomar como referencia y conoces las herramientas. Así que abres el repositorio y empiezas.
A mí también me ha pasado.
El problema es que reconocer una tarea no siempre significa entender lo que necesita.
Se parece, pero cumple otra función
En una ocasión me tocó automatizar un proceso interno.
Había otros procesos que se ejecutaban de una forma parecida, así que seguí el patrón que ya existía. Me pareció una decisión razonable: aprovechar lo que teníamos, mantener consistencia y evitar inventar otra manera de hacer lo mismo.
Durante la revisión apareció algo que yo no había considerado.
Los procesos que había tomado como referencia formaban parte del funcionamiento de la aplicación. La nueva automatización tenía otro propósito y debía mantenerse separada.
Técnicamente se parecían. Arquitectónicamente tenían responsabilidades distintas.
Yo había elegido dónde poner la solución antes de aclarar qué lugar debía ocupar dentro del sistema.
Y eso cambió el enfoque.
El código podía funcionar y aun así estar en el lugar equivocado.
Un ejemplo también trae decisiones
Reutilizar una solución existente puede ahorrarnos mucho trabajo.
Pero ese código llegó a ser así por alguna razón. Tal vez responde a una escala distinta, a restricciones de seguridad, a varios equipos desplegando sobre la misma infraestructura o a problemas que nuestro proyecto todavía no tiene.
Cuando copiamos el código, podemos llevarnos también esas decisiones.
Un pipeline de Terraform puede incluir múltiples ambientes, aprobaciones, matrices y dependencias entre proyectos. Todo eso puede tener sentido donde se construyó. En otro contexto, mantenerlo puede costar más que el problema que intentábamos resolver.
También puede pasar al revés: simplificar algo sin entender qué protección estábamos quitando.
Por eso, cuando tomo un proyecto como referencia, intento entender qué problema resolvía cada parte y cuáles de esas condiciones existen en el nuevo proyecto.
A veces la respuesta termina siendo prácticamente la misma implementación. Pero ahora sé por qué.
A veces hay que retroceder más
Con el tiempo también me ha tocado recibir tareas para arreglar algo y terminar preguntando por qué seguíamos necesitándolo.
El requerimiento parecía concreto: esto falla, hay que corregirlo.
Pero al revisar para qué servía, quién lo usaba y qué había cambiado alrededor, aparecía otra posibilidad: quitarlo.
Habíamos empezado buscando cómo mantener una pieza que ya no necesitaba estar ahí.
Ese tipo de trabajo puede ser difícil de mostrar. No hay una implementación grande ni una nueva herramienta. Tal vez el resultado sea menos código y una responsabilidad menos que operar.
Para mí, también es parte de hacer DevOps en la práctica: entender el sistema lo suficiente como para decidir qué vale la pena seguir manteniendo.
Alinear el enfoque también es trabajo
Después de experiencias así, he intentado hacer explícito el enfoque antes de invertir demasiado en implementarlo.
Qué queremos conseguir. Qué restricciones tenemos. Dónde debería vivir la solución. Qué responsabilidades va a tener y quién se va a hacer cargo de ella.
Muchas veces basta con un mensaje corto y una propuesta concreta. Si hay una decisión que afecta a otros, prefiero que podamos discutirla cuando todavía es fácil cambiarla.
Eso también requiere aprender a trabajar de otra manera.
La persona que necesita revisar el enfoque puede estar ocupada. La respuesta puede tardar días. Y mientras tanto hay que seguir avanzando.
Puedo investigar una duda, validar una suposición, hacer una prueba pequeña o tomar otra tarea. Lo que intento cuidar es cuánto trabajo construyo sobre una decisión que todavía está abierta.
También hay que tener criterio para saber cuándo hace falta esa conversación. Un cambio pequeño, conocido y fácil de revertir normalmente no necesita el mismo nivel de alineación que introducir una nueva dependencia o cambiar cómo desplegamos.
Entender el propósito abre opciones
Cuando solo veo la tarea, mis opciones suelen quedarse dentro de ella.
Si me piden un script, pienso en cómo escribirlo. Si entiendo qué necesitan conseguir con ese script, puedo evaluar otras soluciones: aprovechar algo existente, cambiar el flujo, reducir el alcance o eliminar la necesidad.
Ahí es donde siento que la experiencia empieza a pesar.
Saber usar las herramientas ayuda a ejecutar. Entender el propósito ayuda a elegir qué ejecutar y a explicar las decisiones.
Creo que parte de crecer como ingeniero está en asumir esa responsabilidad. Poder proponer un camino, reconocer lo que todavía no sabemos y buscar contexto antes de comprometer al equipo con una solución.
Todavía tengo que recordármelo algunas veces, sobre todo cuando una tarea se parece mucho a otra que ya resolví.
Porque esa familiaridad ayuda a empezar rápido.
Pero antes de escribir la primera línea, vale la pena comprobar que entendimos qué estamos intentando resolver.