Fui técnico en redes 6 años antes de ser dev

Antes de escribir código como trabajo, pasé seis años como técnico en redes. Cableado estructurado, configuración de switches, VLANs, DNS, firewalls. El trabajo invisible que hace que todo lo demás funcione.

Cuando llegué al desarrollo de software, algunos patrones que otros devs aprenden con el tiempo ya eran obvios para mí.

La red no es transparente

Un error común en código es asumir que las llamadas HTTP son instantáneas o confiables. Quienes vienen directo de cursos de programación tienden a ignorar latencia, timeouts y reintentos hasta que el sistema falla en producción.

Seis años trabajando en la capa que mueve esos paquetes hacen difícil olvidar que cada request cruza switches, routers, firewalls y cables físicos. Eso cambia cómo diseñas timeouts, cómo manejas errores de red y cómo piensas en resiliencia.

DNS primero

Cuando algo no funciona, mi primer instinto sigue siendo verificar DNS. No el código. No los logs de la aplicación. DNS.

Esa costumbre ha acortado más de un debugging session. La mayoría de los “errores de conexión misteriosos” tienen respuesta en una query de DNS o en una regla de firewall.

Saber qué hay entre el cliente y el servidor

Un dev que nunca tocó infraestructura tiende a pensar en su aplicación como una caja aislada. Entrada, proceso, salida. La red es un detalle del deployment.

Trabajar en redes enseña que hay decenas de puntos de falla entre el cliente y la aplicación. Eso afecta cómo documentas dependencias, cómo diseñas health checks y cómo explicas incidentes.

Lo que no te da la formación técnica

Nada de esto viene de cursos de programación. Viene de pasar horas rastreando por qué un servidor no responde y descubrir que era una ACL mal configurada en un switch de distribución.

No es conocimiento glamoroso. Pero es conocimiento que se nota cuando diseñas sistemas que tienen que funcionar en condiciones reales.