Cuando construimos sistemas, a menudo pasamos una cantidad sorprendente de tiempo perfeccionando cosas que son nice to have, mientras dejamos de lado dónde vive realmente el impacto.
He visto este patrón repetirse muchas veces en trabajo de infraestructura: pulir dashboards que pocos revisan, sobreingenierizar pipelines que ya funcionan, o debatir decisiones de herramientas mucho después de que dejaron de importar. Se siente productivo — pero normalmente no lo es.
Lanzar este blog fue un pequeño recordatorio personal de ese mismo patrón.
Al inicio, me enfoqué en todo lo que estaba alrededor de la escritura: el framework, el tema, las fuentes, los colores, los detalles de UI, la configuración del deployment, etc. Todas esas cosas vale la pena y es necesario hacerlas bien, pero ninguna era la razón por la que el blog existía en primer lugar.
El objetivo real era simple: escribir y compartir notas prácticas basadas en mi experiencia.
Requirió un esfuerzo consciente dejar de ajustar detalles secundarios y avanzar con algo que fuera “suficientemente bueno”. En el momento en que el sitio estuvo en línea, la importancia percibida de muchas de esas decisiones cayó drásticamente. Lo que quedó fue lo único que realmente importaba: tener un lugar donde la escritura pudiera suceder.
Este trade-off aparece constantemente en trabajo de DevOps y plataformas.
A menudo buscamos la perfección en áreas que son fáciles de controlar, mientras retrasamos el progreso en áreas que generan valor real. La infraestructura nos da oportunidades infinitas para refinar, optimizar y ajustar — pero no todas las mejoras tienen el mismo impacto.
Alguna vez pasé horas puliendo dashboards — agregando gráficas interactivas, filtros personalizados y visualizaciones bonitas. Lo que realmente salvó el día durante un incidente en producción, sin embargo, fue una simple alerta en Slack que configuré en unos minutos. Detectó el problema a tiempo y evitó una escalación. El dashboard “perfecto” se veía impresionante, pero la alerta básica generó el impacto real.
En otra ocasión, estaba diseñando una herramienta de selfservice para ayudar a desarrolladores a desplegar recursos en AWS sin necesidad de tener que aprender Terraform o manejar credenciales segun governance. Imaginé todo lo que la herramienta podría llegar a ser: despliegues multi-entorno, escaneos de seguridad, escalado dinámico — lo que quieras. En papel sonaba genial.
Lo que los desarrolladores realmente necesitaban en ese momento era mucho más simple: una forma directa de desplegar recursos básicos de AWS como buckets de S3 o instancias de RDS. Al intentar construir una solución “a prueba del futuro” y que lo cubriera todo, perdí de vista el problema inmediato. En la práctica, solo necesitábamos una forma de desplegar buckets de S3.
El trabajo difícil suele ser más silencioso:
- decidir qué no optimizar todavía
- aceptar decisiones reversibles
- entregar algo imperfecto pero usable
- crear espacio para el trabajo que de verdad importa
Este blog no existe por una configuración perfecta. Existe porque, en algún punto, se tomó la decisión de dejar de preparar y empezar a publicar.
Esa lección va mucho más allá de los blogs.
La mayoría de las veces, el impacto no viene de sistemas perfectos — viene de decidir dónde dejar de optimizar y avanzar.