Empezar de cero es una de las ideas más seductoras en software. Un repositorio vacío no tiene deuda técnica, decisiones heredadas ni errores que todavía no entendemos. También nos permite imaginar que esta vez tomaremos todas las decisiones correctas.

Hace poco participé en una iniciativa para reemplazar un sistema que arrastraba varios problemas. Construir una versión nueva era emocionante y técnicamente tentador. La pregunta que cambió nuestra manera de evaluar la iniciativa fue bastante menos espectacular: ¿qué problema resolvería un sistema nuevo que no pudiéramos resolver mejorando el actual?

Dar un paso al costado costó. Había mucho por diseñar y la posibilidad de hacerlo desde cero resultaba atractiva para cualquier programador. El deseo de estrenar una arquitectura tenía que quedar subordinado a resolver los problemas que nos hacían querer escapar de la existente.

Ese también fue un sacrificio. La milla extra consistía en comprender lo que ya teníamos, tolerar su complejidad y renunciar al trabajo más visible. Escribir más código habría sido emocionante. Hacer el trabajo útil exigía algo distinto.

Palabras como overachiever y outlier ponen la atención en el exceso o en un resultado excepcional. A mí me interesa otra medida: convertirme en alguien que busca mejorar, acepta el costo cuando el objetivo lo merece y vuelve al trabajo antes de que aparezca una recompensa.

Los referentes no vienen en un paquete

Mi lista de referentes mezcla a Linus Torvalds, Rafael Nadal, Dale Carnegie, Eric Ries y Guillermo Rauch. No admiro todo lo que hicieron ni pretendo adoptar una personalidad completa.

De Torvalds me interesa el pragmatismo. De Nadal, la humildad y el trabajo cotidiano. Carnegie me recuerda que tener razón sirve de poco si el ego impide alcanzar el objetivo. Ries ofrece una forma de contrastar las ideas con evidencia. Rauch representa una ambición tecnológica que no se limita a mejorar un poco lo que ya existe.

Algunas de sus ideas participan en mis decisiones como preguntas que aparecen cuando una opción es demasiado cómoda, atractiva o centrada en mí. Admirar una conducta no me obliga a defender a la persona entera. Así puedo aprender de referentes distintos sin fabricar héroes ni delegar en ellos mi criterio.

El pragmatismo también puede exigir más trabajo

En el proyecto reciente, la reconstrucción completa parecía la decisión ambiciosa. Mejorar el sistema existente podía confundirse con conformismo. Al mirar el problema con más cuidado, esa impresión empezó a cambiar.

Trabajar sobre lo que ya estaba construido exigía entender decisiones ajenas, diagnosticar problemas reales y separar las limitaciones de la arquitectura de aquellas que nosotros mismos habíamos acumulado al operarla. Un sistema nuevo nos habría permitido evitar temporalmente varias de esas preguntas. También podía repetirlas con nombres más modernos.

Allí encuentro algo de Torvalds, Ries y Carnegie. El pragmatismo obliga a mirar el resultado antes que el atractivo de la solución. La experimentación ayuda a reunir evidencia antes de hacer una apuesta costosa. Dejar el ego fuera permite admitir que una idea emocionante quizás no es la que el proyecto necesita ahora.

La arquitectura nueva quedó como una posibilidad futura que tendría que ganarse su lugar con una razón concreta para existir.

Dar la milla extra no siempre produce más. En esta ocasión significaba investigar más, comprender mejor y aceptar que el resultado podía ser menos código nuevo. La excelencia estaba en la calidad de la decisión.

Pagar antes de ver el resultado

Mi relación con Linux empezó en la universidad, antes de mi primer empleo como programador. Instalé Debian en una época en la que todavía no tenía Internet en casa. Sabía que estaba dejando un entorno conocido y que cualquier problema podía volverse incómodo.

Esa incomodidad era parte de la decisión. Mi intención no era instalar otro Windows con una apariencia distinta, sino aprender a usar la terminal en un entorno que me obligara a practicar.

El primer obstáculo fue bastante básico: las páginas de man estaban en inglés y mi nivel todavía no alcanzaba para entenderlas bien. Tuve que investigar desde la universidad, descubrir que existían las páginas del manual en español, descargar el paquete y llevarlo a casa en un pendrive. Para aprender a usar las herramientas primero tuve que aprender a conseguir la documentación que podía leer.

Más de un año después llegué a la entrevista para mi primer empleo como programador. Allí me contaron que utilizaban Debian y Ubuntu en sus servidores. Conseguí el puesto y, en ese aspecto, no hubo fricción: llevaba más de un año peleando con Debian por mi cuenta.

No podía saber que esa decisión aparecería en una entrevista. La tomé porque Linux me parecía importante para el profesional que quería llegar a ser.

El primer resultado de aquel esfuerzo llegó mucho antes de la entrevista: me había convertido en alguien capaz de trabajar con Debian. El empleo hizo visible esa capacidad y le dio un uso que yo no podía haber anticipado. La recompensa externa tardó; la transformación ya estaba ocurriendo mientras llevaba paquetes en un pendrive.

La parte del trabajo que nadie fotografía

En Nadal miro menos el partido importante que su disposición a volver al trabajo diario, incluso después de haber demostrado suficiente para no necesitar demostrar nada más.

En programación, esa actitud aparece cuando una corrección rápida elimina el error visible, pero todavía no explica su causa. Seguir investigando puede implicar más trabajo hoy. También puede evitar que el mismo problema regrese con otra forma, en otro módulo o durante una madrugada menos conveniente.

Allí se juega una parte de la identidad profesional que quiero construir. Puedo conformarme con que el error desaparezca o seguir hasta entender por qué apareció. La segunda opción no garantiza reconocimiento y, muchas veces, nadie verá las horas adicionales. Aun así, cambia la clase de programador que enfrenta el siguiente problema.

La tenacidad necesita condiciones que nos permitan regresar al problema, y una de ellas es la atención. En mi caso, decidí mantenerme fuera de las redes sociales que más me distraían. Conservo una cuenta de X que sigue principalmente a personas relacionadas con tecnología. Es la manera que encontré de decidir mejor qué ideas ocupan mi tiempo.

Proteger la atención no produce un resultado llamativo al final del día. Permite regresar suficientes veces al mismo problema como para comprenderlo.

Ambición con las herramientas de hoy

La experiencia con el sistema existente no me volvió contrario a las apuestas grandes. Guillermo Rauch me resulta interesante porque su visión sobre IA busca reducir la distancia entre imaginar software y construirlo. Cuando experimentar cuesta menos, algunas ideas merecen otra evaluación, pero elegir bien se vuelve más importante: que un agente produzca más código no demuestra que resuelva el problema correcto.

La pregunta sobre el sistema nuevo sigue funcionando incluso cuando construir se vuelve más barato: ¿qué capacidad queremos ganar y por qué no podemos obtenerla de una forma más sencilla?

Elegir el costo

No necesito recordar la biografía completa de cada referente mientras trabajo. Me basta asociar el estándar que admiro con el costo que estoy dispuesto a aceptar. Un archivo pequeño puede hacerlo explícito:

# REFERENTES.md

Persona:
Qué estándar me muestra:
Qué quiero mejorar:
Qué costo estoy dispuesto a aceptar:
Qué haré aunque el resultado tarde:

Torvalds puede aparecer cuando estoy admirando la arquitectura más que el problema. Carnegie, cuando una revisión de código empieza a tratarse de quién tiene razón. Nadal, cuando el trabajo importante se vuelve repetitivo. Rauch, cuando sigo calculando el alcance con los límites de herramientas que ya cambiaron.

No hace falta empezar con una lista larga. Una persona, una mejora y un costo son suficientes para la próxima semana.

Dar la milla extra en cada dirección convertiría lo extraordinario en una exigencia imposible. La dificultad no vuelve valioso un objetivo. Cuando el objetivo merece el costo, la identidad se construye al pagarlo y volver al trabajo, incluso si el resultado todavía no tiene fecha.

¿Qué quieres ser capaz de hacer dentro de un año, y qué costo aceptarías hoy para empezar a convertirte en esa persona?

Referencias