Lo que el golf me enseñó sobre escribir código
Jugué al golf desde los 10 hasta los 17 años. El Covid lo paró. Pero lo que aprendí en el campo lleva años apareciendo en el editor, en las reuniones y en cómo
Santiago Gómez
Lo que el golf me enseñó sobre escribir código
Empecé a jugar al golf con 10 años. Estuve compitiendo hasta los 17, cuando llegó el Covid y de repente el campo dejó de existir. Practiqué en casa lo que pude, con lo que tenía, pero no es lo mismo. Cuando todo volvió a abrir, lo retomé pero ya de otra manera, más como hobby que como competición. El swing sigue ahí, grabado en el músculo después de tantos años.
La mayoría de la gente que me conoce del mundo tech no sabe esto. Y cuando se lo cuento, la primera reacción suele ser sorpresa. El golf y la programación parecen mundos opuestos: uno es lento, silencioso, al aire libre. El otro es rápido, intenso, frente a una pantalla.
Pero llevan años enseñándome las mismas cosas.
El swing perfecto no existe. El tuyo sí.
Cuando empiezas a aprender golf, lo primero que haces es buscar el swing correcto. Ves vídeos de Rory McIlroy, de Tiger, de Scottie Scheffler. Intentas copiar la posición de las manos, el giro de cadera, el ángulo del codo en el backswing. Y el resultado es un desastre, porque estás intentando ejecutar un movimiento que no es tuyo.
Con el código pasa igual. Empiezas leyendo el código de otros, copiando patrones, intentando escribir como los seniors del equipo. Y produces algo que funciona pero que no entiendes del todo, porque no lo construiste desde tu lógica sino desde la de otro.
En golf hay un concepto que se llama swing DNA. La idea de que cada persona, por su físico, su flexibilidad y su coordinación, tiene un swing natural distinto al de cualquier otro jugador. El trabajo del entrenador no es darte un swing nuevo sino encontrar el tuyo y refinarlo.
En programación tardé más en entender eso. Que mi forma de estructurar un problema, de nombrar variables, de organizar un módulo, es mía. Intentar escribir exactamente como otro developer no me hace mejor, me hace una copia peor.
La parálisis del análisis
Hay un momento en golf que todos los jugadores conocen y ninguno quiere hablar de él. Estás en el green, tienes un putt de unas 13 yardas, y de repente ya no sabes cómo se agarra un putter. Analizas demasiado. El grip, la postura, la línea, el viento, la hierba. Y cuando por fin golpeas, el golpe es horrible porque tu cabeza se metió donde no debía.
En programación se llama parálisis por análisis. Llevas dos horas mirando un problema, has leído cinco artículos sobre la mejor arquitectura, tienes cuatro pestañas abiertas con diferentes aproximaciones, y no has escrito una sola línea.
Lo que aprendí en el campo fue que la solución no es pensar menos sino confiar más en el trabajo previo. Si has entrenado el putt, tu cuerpo sabe hacerlo. Si has practicado resolver ese tipo de problema, tu mente sabe cómo atacarlo. El análisis es para antes del campo, no para el momento del golpe.
Ahora cuando me atasco en un problema técnico, me pregunto si estoy pensando o si estoy evitando. Casi siempre es lo segundo.
El hoyo que arruinas en el hoyo anterior
Una de las cosas más difíciles del golf no es técnica. Es mental. Si haces un doble bogey en el hoyo 7, ese hoyo tiene el poder de destruirte los siguientes tres si lo dejas. Llegas al 8 todavía pensando en el error anterior, haces otro bogey, y para el 9 ya estás jugando con el freno puesto.
Los mejores jugadores tienen una habilidad que se llama amnesia competitiva. No es que no recuerden el error, es que eligen conscientemente dejarlo en ese hoyo y llegar al siguiente con la mente limpia.
En desarrollo lo veo constantemente. Un bug que tardaste dos días en resolver te persigue durante semanas. Una decisión de arquitectura que salió mal sigue coloreando cómo atacas el siguiente problema. Y ese peso hace que tomes peores decisiones porque estás cargando algo que ya no existe.
El código que rompiste ya está arreglado. El siguiente problema merece tu atención completa.
El score no te dice todo
En golf hay una métrica que se llama strokes gained. En lugar de solo contar cuántos golpes hiciste, mide cuánto mejor o peor estás rindiendo respecto a un benchmark en cada parte del juego. Puedes tener el mismo score que la semana pasada y haber mejorado mucho en approach pero empeorado en putting. El score final esconde la historia real.
Esto me cambió cómo pienso en el trabajo. Las métricas visibles, velocidad de entrega, features lanzadas, commits por semana, son el score final. Te dicen si ganaste o perdiste pero no te dicen por qué ni dónde mejorar.
Desde que retomé el golf con seriedad soy más cuidadoso con qué mido. No solo si la feature salió sino cuánto tardé en entender el problema, cuántas veces cambié de dirección, dónde me atranqué. Eso es lo que te dice dónde entrenar.
La ventaja que nadie te cuenta
Aquí hay algo que no se habla suficiente: haber jugado golf a nivel serio te da una ventaja real en entornos profesionales de tech, y no precisamente por el handicap.
El golf es el deporte favorito de los negocios por algo. Una ronda de 18 hoyos son cuatro horas caminando con alguien, sin distracciones, sin teléfono, tomando decisiones bajo presión y viendo cómo reacciona cuando las cosas van mal. No hay entrevista de trabajo ni reunión de ventas que te diga tanto de una persona como una ronda de golf.
Y hay algo más específico: los developers que jugamos al golf tendemos a ser mejores gestionando la incertidumbre. En golf nunca controlas todo. El viento, el lie de la bola, el estado del green. Aprendes a tomar la mejor decisión posible con información incompleta y a ejecutarla con convicción aunque no estés seguro del resultado. Que es exactamente lo que hace falta cuando estás diseñando una arquitectura sin todos los requisitos claros o lanzando un producto sin saber si va a funcionar.
Jugar solo vs jugar en ronda
Entrenar en el campo de prácticas solo es necesario pero no suficiente. La ronda de competición te exige cosas que el entrenamiento no puede simular. La presión de otros jugadores mirando, la decisión de intentar llegar al green desde 210 yardas con agua por delante cuando llevas tres hoyos seguidos bien.
En desarrollo, el code review es esa ronda. Puedes escribir código magnífico en local, con tus convenciones, sin nadie mirando. Pero cuando alguien más lo lee, cuando tienes que defenderlo o explicarlo, es cuando descubres si realmente lo entiendes o solo creías entenderlo.
No tengo muchos compañeros de trabajo que jueguen al golf. Pero cuando explico un problema técnico difícil, a veces lo hago con metáforas del campo. Y funciona, porque hablan de lo mismo: gestión de la incertidumbre, toma de decisiones bajo presión, y la diferencia entre saber algo y poder ejecutarlo cuando importa.
El Covid me quitó el golf competitivo antes de saber lo que tenía. Pero los años de campo, los torneos, los entrenamientos, se quedaron. Y resulta que sirven para más cosas de las que pensaba.
Nos leemos.
Santi
