Lo que entrenar para una media maratón me enseñó sobre ingeniería

La línea de salida que nadie ve

Me inscribí en mi primera media maratón pensando que sería algo divertido para un fin de semana. Algo para tachar de una lista. Lo que no esperaba era cuánto iba a reflejar el entrenamiento los mismos desafíos que enfrento cada día como Tech Lead construyendo sistemas en producción.

Llevo más de un año con entrenamiento híbrido (gimnasio tres días a la semana combinado con progresiones de carrera de 10K a 21K). Y alrededor del cuarto mes empecé a notar que casi todos los principios que me hicieron mejor corredor también me hicieron mejor ingeniero. No de una forma bonita, de póster motivacional. De una forma real y práctica, de esas que cambian cómo planifico los sprints.

Vamos por partes.

Sobrecarga progresiva = complejidad incremental

En el entrenamiento, la sobrecarga progresiva significa que no pasas de correr 5K a 21K en una semana. Aumentas un 10 % de volumen por semana. Te ganas el siguiente nivel.

En ingeniería, es el mismo principio detrás de la entrega incremental. No pasas de un monolito a microservicios en un sprint. Extraes un bounded context, validas que funciona y luego extraes el siguiente. Cada vez que he visto a un equipo intentar una migración “big bang”, terminó en lágrimas. Todas y cada una de las veces.

El cuerpo se adapta al estrés de forma gradual. También lo hace un codebase. También lo hace un equipo.

Cuando incorporo a nuevos ingenieros, les doy tareas progresivamente más difíciles, no porque sea un guardián del acceso, sino porque el contexto se construye sobre el contexto. Necesitas entender el modelo de datos antes de tocar el pipeline de eventos. La sobrecarga progresiva no es solo un principio de entrenamiento. Es un principio de liderazgo.

Días de descanso = prevenir el burnout

Aquí hay algo que la cultura del gimnasio entiende mal y la cultura tech todavía peor: descansar no es pereza. El descanso es donde ocurre la adaptación.

Tus músculos no crecen durante el entrenamiento. Crecen durante la recuperación. Tus mejores ideas de ingeniería no llegan durante una sesión de código de 12 horas. Llegan en la ducha a la mañana siguiente, después de que tu cerebro ha tenido tiempo de procesar.

Respeto los días de descanso en mi plan de entrenamiento con la misma disciplina con la que exijo un ritmo sostenible a mis equipos. Nada de sprints heroicos. Nada de “aguantemos el fin de semana”. He visto lo que pasa cuando te saltas los días de descanso en el entrenamiento: te lesionas. He visto lo que pasa cuando los equipos se saltan el descanso: obtienes rotación, bugs y gente que deja de importarle.

Idea clave: Si tu equipo trabaja horas extra de forma constante, no tienes un problema de capacidad. Tienes un problema de planificación.

El plan de entrenamiento = el plan del sprint

Un buen plan de entrenamiento tiene:

• Periodización: ciclos de acumulación y de descarga
• Especificidad: entrenamientos que apuntan a las exigencias reales de la carrera
• Hitos medibles: pruebas contrarreloj, marcadores de distancia
• Flexibilidad: ajustes según cómo responde el cuerpo

Reemplaza “entrenamientos” por “tareas” y “carrera” por “release” y tienes una sólida filosofía de planificación de sprints. Los mejores planes de sprint que he llevado tenían todos estos elementos. Los peores eran rígidos, poco realistas e ignoraban el feedback del equipo.

Antes planificaba los sprints como planifica un principiante su entrenamiento: meter tanto como sea posible en cada semana. Ahora planifico como un corredor con experiencia: dejo espacio para lo inesperado, incluyo la recuperación y siempre sé cuál es el entrenamiento prioritario de esa semana.

La constancia le gana a la intensidad

Esto me cambió todo.

Correr 5K cuatro veces por semana te hará más rápido que correr 15K una vez por semana y desplomarte. Desplegar a diario cambios pequeños y bien probados te llevará más lejos que releases masivos cada dos semanas.

En el entrenamiento, la constancia construye tu base aeróbica. En ingeniería, la constancia construye confianza en el deploy. Los equipos que lidero y que entregan poco y a menudo tienen menos incidentes, tiempos de recuperación más rápidos y (esta es la parte contraintuitiva) más producción total que los equipos que agrupan todo en grandes releases.

Lo mismo aplica al aprendizaje. Leer 30 minutos de documentación cada día supera a una maratón de fin de semana. Escribir un PR pequeño al día supera a un monstruo de 2000 líneas un viernes por la tarde.

El muro del km 18 = el muro del mes 6

Todo corredor de fondo conoce “el muro”. En una media maratón, suele aparecer alrededor del kilómetro 18. Tu glucógeno se agotó, tus piernas gritan y tu cerebro busca cualquier excusa para parar.

En los proyectos largos hay un muro parecido. Alrededor del mes 5 o 6, la emoción inicial se acabó. Los problemas arquitectónicos difíciles ya están resueltos, pero ahora estás lidiando con integraciones, casos límite y el tipo de trabajo que nadie celebra. La moral del equipo baja. La gente empieza a cuestionar decisiones tomadas en el mes 1.

Cómo manejas el muro en el entrenamiento:

• Lo esperabas. Es parte del plan.
• Tienes una estrategia de nutrición. Geles, hidratación, ajustes de ritmo.
• Te concentras en el siguiente kilómetro, no en la meta.

Cómo manejo el muro en los proyectos:

• Aviso al equipo con anticipación. “Los meses 5-6 serán duros. Es normal.”
• Divido el trabajo restante en hitos visibles y completables.
• Celebro las pequeñas victorias en público. ¿Entregamos el servicio de notificaciones? Eso es una victoria. Dilo en voz alta.

El juego mental es real. En ambos terrenos.

Seguimiento de métricas: ritmo/FC = observabilidad/monitoreo

Al correr, registro ritmo, frecuencia cardíaca, cadencia y variabilidad de la frecuencia cardíaca. No porque esté obsesionado con los números, sino porque sin datos solo estoy adivinando si mejoro o si estoy sobreentrenando.

En producción, medimos latencia, tasas de error, throughput y saturación. Por la misma razón.

Esto es lo que ambos me han enseñado sobre las métricas:

• Las métricas de vanidad son peligrosas. El total de kilómetros corridos no te dice si te estás volviendo más rápido. El total de deploys no te dice si estás entregando valor.
• Las tendencias importan más que las fotos instantáneas. Una mala carrera no significa nada. Un pico en la tasa de errores no significa nada. ¿Pero una tendencia a la baja de tres semanas en ambas? Presta atención.
• Necesitas líneas base. Mi frecuencia cardíaca en reposo es de 52 lpm. Si salta a 60, algo anda mal, aunque 60 sea “normal” para otra persona. Lo mismo con tu latencia p99. Conoce TU normalidad.

// Tu observabilidad debería contar una historia, no solo mostrar números
// Mal: alertar cuando errors > 100
// Bien: alertar cuando error_rate se desvíe > 2σ de la línea base de 7 días

alert:
  name: error_rate_anomaly
  condition: |
    abs(current_error_rate - avg_error_rate_7d) > 2 * stddev_error_rate_7d
  severity: warning

Prevención de lesiones = gestión de la deuda técnica

Los corredores que se saltan el trabajo de movilidad, ignoran los dolores leves y nunca descargan terminan lesionándose. No es cuestión de si, sino de cuándo.

Los ingenieros que se saltan el refactoring, ignoran los code smells y nunca pagan la deuda técnica terminan enfrentando un incidente de producción causado por el descuido acumulado. La misma certeza.

El paralelismo es casi demasiado limpio:

• Estirar y usar el foam roller = sesiones regulares de refactoring
• Ignorar el dolor de rodilla = ignorar los tests inestables (flaky)
• Correr con una fractura por estrés = entregar sobre bugs críticos conocidos
• Buenas zapatillas = buenas herramientas e infraestructura

Programo “semanas de descarga” para mis equipos: sprints en los que reducimos deliberadamente el trabajo de funcionalidades y nos enfocamos en herramientas, cobertura de tests, actualización de dependencias y refactoring. No es productividad perdida. Es prevención de lesiones.

El juego mental

Lo más difícil de correr 21K no es lo físico. El día de la carrera, tu cuerpo está listo. Lo difícil es la voz en tu cabeza en el kilómetro 15 diciéndote “podrías simplemente caminar”.

Lo más difícil de liderar un proyecto largo no es lo técnico. Tu equipo tiene suficiente habilidad. Lo difícil es mantener la convicción cuando los stakeholders están ansiosos, cuando la competencia lanzó algo llamativo, cuando el atajo fácil está ahí mismo.

En ambos casos, la respuesta es la misma: confía en el entrenamiento. Confía en el proceso que construiste. Confía en el plan. Confía en que la constancia se acumula. Y cuando se ponga difícil (y se va a poner difícil), recuerda que te preparaste para este momento específicamente.

Cruzar la línea de meta

Terminé mi primera media maratón en 1:52. No es de élite. No es un récord. Pero terminé. Y terminé porque respeté el proceso, escuché a mi cuerpo, me mantuve constante y no abandoné en el kilómetro 18.

Todo proyecto exitoso que he liderado siguió el mismo patrón. Nada glamoroso. Nada revolucionario. Solo esfuerzo constante, evaluación honesta, recuperación planificada y la disciplina de seguir adelante cuando dejó de ser divertido.

La línea de meta, ya sea de una carrera o de un release, es solo el resultado visible de meses de trabajo invisible. ¿Y ese trabajo invisible? Ahí es donde ocurre la verdadera ingeniería.

Átate los cordones. Entrega en pequeño. Mantente constante. El muro viene, y estás listo para él.