La disciplina del corredor y la del programador
Correr un maratón y construir software son la misma batalla mental.
A las 5:30 de la mañana, cuando suena la alarma y el cuerpo pide 5 minutos más, la decisión ya está tomada. No en ese momento — se tomó la noche anterior, cuando preparé la ropa. Se tomó la semana anterior, cuando definí el plan. Se tomó hace meses, cuando decidí correr un maratón en menos de 4 horas.
La disciplina no es fuerza de voluntad. La disciplina es eliminar la decisión. Cuando tienes que decidir cada mañana si vas a correr o no, eventualmente dirás que no. Cuando ya decidiste y solo ejecutas, la pregunta desaparece.
Los paralelos que nadie ve
Construir software y entrenar para un maratón se parecen más de lo que cualquier programador o corredor admitiría:
- Ambos requieren consistencia sobre intensidad. Correr 30km un día y no correr en una semana te lesiona. Programar 14 horas un sábado y no tocar código en 5 días te atrasa. Lo que importa es la frecuencia, no el pico.
- El progreso es invisible día a día. No ves mejora entre martes y miércoles. Ni entre un commit y el siguiente. Pero en 3 meses, miras atrás y todo cambió.
- El dolor es parte del proceso, no un error. Los músculos duelen. Los bugs frustran. Si esperas un camino sin dolor, nunca empezarás.
- El plan importa más que la motivación. La motivación es gasolina — se agota. El plan es el motor. Un plan de entrenamiento te dice qué hacer cuando no quieres hacer nada. Una arquitectura bien definida te dice qué programar cuando estás perdido.
Lo que el running me enseñó sobre código
Empecé a correr en serio hace un año. Los primeros 5 kilómetros fueron los más difíciles de mi vida — no por la distancia, sino por la vergüenza de ser malo en algo. Estoy acostumbrado a ser competente. En código, en análisis de datos, en mi trabajo. Pero en running, era un principiante absoluto.
Esa humildad se trasladó a mi código. Dejé de asumir que mis primeras soluciones eran las mejores. Empecé a tratar el primer borrador como lo que es: un primer kilómetro. Lento, torpe, necesario. La versión final viene después de iteraciones, no de inspiración.
No existe el código perfecto en el primer intento, igual que no existe el maratón perfecto sin meses de kilómetros imperfectos.
Sub-4h: la meta que organiza todo
Mi objetivo para noviembre de 2026: correr un maratón completo (42.195 km) en menos de 4 horas. Eso implica mantener un ritmo promedio de ~5:40/km durante casi cuatro horas seguidas. No es élite, pero para alguien que hace un año apenas podía correr 5km sin parar, es una transformación radical.
La meta Sub-4h no es solo sobre running. Es un principio organizador. Define mi alimentación, mi sueño, mi manejo del estrés, mi agenda de fin de semana. Cuando todo en tu vida apunta hacia un objetivo claro, las decisiones diarias se simplifican enormemente.
Lo mismo pasa en software. Cuando sabes exactamente qué estás construyendo y por qué, cada decisión técnica se alinea. ¿Usamos esta librería o aquella? Depende — ¿cuál nos acerca más al objetivo? Sin objetivo claro, cada decisión es una discusión filosófica infinita.
El kilómetro 35
Los corredores experimentados hablan del kilómetro 35 como el momento donde todo se rompe. Las piernas dejan de cooperar. La mente inventa razones para parar. El cuerpo dice que ya fue suficiente.
En programación, el "kilómetro 35" es esa fase del proyecto donde ya pasó la emoción inicial, los problemas técnicos se acumulan, y la fecha de entrega se acerca. Es donde la mayoría abandona o entrega algo mediocre.
Los que cruzan la línea de meta — en running y en código — son los que aprendieron a seguir cuando ya no es divertido. No por masoquismo. Por compromiso con una versión de sí mismos que todavía no existe pero que están construyendo, un kilómetro a la vez, un commit a la vez.
Si estás empezando algo y eres terrible — sigue. Ser terrible es el precio de entrada. Lo que viene después lo vale.