Llevo más años pescando que programando de forma seria, y durante mucho tiempo consideré esas dos actividades completamente separadas: una para desconectar, otra para trabajar. Con el tiempo, sobre todo desde que empecé a construir una app pensada para pescadores, he notado que se parecen más de lo que esperaba, y que una me ha enseñado cosas útiles para la otra sin que fuera esa la intención.

La paciencia no es una virtud abstracta, es una técnica

En pesca a mosca o en coup con boya, buena parte del resultado depende de esperar el momento correcto sin forzarlo: cambiar de mosca demasiado rápido, o recebar de más por impaciencia, suele empeorar la jornada en lugar de mejorarla. Programando pasa algo parecido con los cambios apresurados: la tentación de "arreglarlo ya" sin entender bien el problema lleva, casi siempre, a un arreglo peor que si se hubiera esperado un poco más a observar qué estaba pasando de verdad.

Esa espera no es pasividad. Es observación activa: mirar cómo se comporta el agua, cómo reacciona un pez a una presentación concreta, de la misma forma que se observa un log de errores antes de tocar código a ciegas.

El carpfishing y la preparación previa

El carpfishing exige preparar mucho antes de lanzar: elegir el bajo de línea adecuado, calcular la distancia, decidir el cebado con tiempo. Casi todo el trabajo relevante pasa antes de que la caña esté montada del todo. Al programar, especialmente en cambios que tocan datos sensibles o partes centrales de una app, me pasa algo parecido: la parte de preparación —entender el problema, revisar qué puede salir mal, decidir el alcance del cambio— pesa tanto o más que escribir el propio código.

Ignorar esa preparación en pesca se traduce en un enganche mal montado que se rompe en el peor momento. Ignorarla en programación se traduce en una regresión que aparece justo cuando menos conviene.

Pescar depredador pequeño desde la orilla y adaptarse rápido

La pesca de depredador pequeño desde la orilla —con spinning ligero, cambiando de señuelo según la respuesta del agua— exige adaptarse con rapidez cuando algo no funciona, sin aferrarse a un plan que ya ha demostrado no dar resultado esa jornada. En proyectos de software me ha pasado exactamente lo mismo: aferrarme a un enfoque de diseño porque "ya he invertido tiempo en él", aunque la evidencia esté señalando que conviene cambiar de estrategia, es un error que he cometido más de una vez, tanto con la caña como con el teclado.

Ejemplo práctico: cómo nació la idea de la app

La idea de construir una app de mapa para pescadores no salió de un análisis de mercado, salió de una frustración muy concreta: no tener una forma fiable de recordar con precisión un punto probado meses atrás sin arriesgarme a que esa información quedara expuesta si alguna vez compartía algo relacionado. Esa frustración personal, nacida directamente de salir a pescar con regularidad, es la que ha guiado casi todas las decisiones de diseño del proyecto, empezando por poner la privacidad como eje central en lugar de como añadido.

Sin esa experiencia previa como pescador, probablemente habría diseñado una app de mapas genérica con peces de icono, sin entender por qué la privacidad de un punto importa tanto como importa en la práctica.

La pesca al coup y la depuración paso a paso

La pesca al coup con boya es, de las modalidades que practico, la que más se parece a depurar un error de software línea a línea. Se ajusta la plomada, se observa cómo se comporta la boya, se corrige un poco, se vuelve a observar. Ningún ajuste se hace a lo grande de golpe; cada cambio es pequeño y se evalúa antes del siguiente. Cuando depuro un error difícil de reproducir, aplico exactamente esa misma disciplina: cambiar una sola variable cada vez y observar el resultado, en lugar de modificar varias cosas a la vez y quedarme sin saber cuál de ellas resolvió, o empeoró, el problema.

Esa comparación no es una metáfora forzada para dar color al texto: es literalmente el mismo proceso mental, aplicado a materiales distintos. La primera vez que noté el paralelismo fue, de hecho, a mitad de una sesión de coup, pensando en un bug que llevaba días sin resolver.

Lo que la programación le ha devuelto a la pesca

No es una relación de un solo sentido. Programar me ha hecho más metódico también fuera del código: llevar un registro más claro de qué probé en cada salida, qué condiciones había y qué resultado tuvo, en lugar de fiarme de la memoria. Es la misma lógica de documentar limitaciones y resultados que aplico en proyectos de software, trasladada a un cuaderno de pesca bastante menos formal.

Conclusión

No quiero forzar el paralelismo más de lo que da. Pescar sigue siendo, ante todo, una forma de desconectar, y convertirlo en una metáfora constante de gestión de proyectos le quitaría justo lo que lo hace valioso como descanso. Las dos actividades se alimentan mutuamente sin necesidad de estar todo el tiempo pensando en la una mientras se hace la otra.

Mezclar pesca y programación no ha sido un plan deliberado, ha sido una consecuencia natural de dedicar tiempo real a ambas cosas durante años. La paciencia del agua dulce y la disciplina del código se han terminado pareciendo más de lo que esperaba, y ese cruce es, sin buscarlo, el origen real del proyecto que sigo construyendo hoy.