Acerca de
Open to work — Abierto a roles de ingeniería senior y liderazgo técnico — totalmente remoto, internacional.
Ingeniero de software con quince años de experiencia en producción. Escribo sobre código limpio, arquitectura limpia, refactoring, testing y sistemas legacy — las disciplinas que determinan si un sistema sigue siendo fácil de cambiar dos años después de su lanzamiento.
Llevo quince años construyendo software en entornos donde la primera versión nunca es la última. Sistemas backend, servicios distribuidos, bases de código legacy migradas a microservicios — el hilo común es que todo necesita cambiar eventualmente, y si puede hacerlo depende casi por completo de decisiones tomadas mucho antes.
El código limpio y la arquitectura limpia no son cuestión de estética ni de seguir reglas. Son sobre reducir el coste del cambio. Un sistema bien estructurado es aquel en el que el siguiente ingeniero — o tu yo futuro — puede entender qué está pasando, hacer una modificación y confiar en que nada inesperado se rompe. El refactoring es como se mantiene viva esa propiedad con el tiempo. El testing es como se hace de forma segura. De eso trata lo que escribo aquí.
Me interesa especialmente la distancia entre cómo se enseñan estas disciplinas y cómo se aplican en la práctica. Abstracciones que aumentan la indirección sin reducir la complejidad. Suites de tests que pasan pero no detectan regresiones reales. Migraciones a microservicios que distribuyen los problemas de un monolito en lugar de resolverlos. Código limpio que solo se mantiene limpio hasta el segundo sprint.
De qué trata esto
Un lugar para escritura de ingeniería que toma en serio las restricciones del mundo real. El objetivo no es predicar el código limpio ni vender una metodología — es examinar qué significan realmente estas disciplinas bajo presión: cuándo refactorizar y cuándo dejarlo, qué testear y qué no, y cómo es la arquitectura limpia cuando el deadline es real.