- Durante el proceso de rastrear un bug en una librería de código abierto, surgió el problema de que el depurador no funcionaba
- Aunque el código se ejecutaba, los puntos de interrupción eran ignorados, así que se intentó encontrar el problema por otros medios
- Se hicieron intentos de diagnóstico indirectos, como agregar salida de logs, pero no se obtuvo la comprensión deseada
- Al final, una vez corregido el error de configuración del depurador, fue posible observar en detalle el comportamiento del programa y así resolver el bug
- A partir de la experiencia de haberse concentrado tanto en resolver el problema que se pasó por alto el defecto de la propia herramienta, se enfatiza que un desarrollador debe arreglar primero sus herramientas para resolver problemas con eficiencia
Problema surgido durante el diagnóstico de un bug
- Mientras se buscaba un bug en una librería de código abierto que se mantiene, el depurador empezó a ignorar los puntos de interrupción
- Era seguro que el código había ejecutado esa línea, pero el programa terminaba sin detenerse
- Por estar tan concentrado en resolver el problema, se ignoró el fallo del depurador y se probaron otros enfoques
- Se intentó diagnosticar el problema con cambios en el código y agregando logs, pero no se obtuvo información útil
Corregir el depurador y resolver el problema
- Se decidió resolver el problema del depurador, y quedó corregido con un cambio de configuración de una sola línea
- Después de la corrección, fue posible observar con detalle el comportamiento del programa
- Con esa información, se logró resolver el bug con éxito
Aprendizaje y lección
- Se reconoce la situación paradójica en la que el entusiasmo por corregir un bug terminó haciendo que se pasara por alto el problema de la herramienta
- Se comprobó que, si la herramienta no funciona correctamente, la eficiencia para resolver problemas cae
- Lo que necesita un desarrollador es el hábito de revisar y arreglar primero las herramientas antes que el problema
- Con la frase "Fix your tools", el texto cierra con un mensaje que recuerda a todos los programadores la importancia de sus herramientas
1 comentarios
Comentarios de Hacker News
Llevo 30 años de carrera y hoy en día las herramientas de desarrollo están demasiado rotas
Escribo código con Clio en Linux, y desde hace años los bugs se han ido poniendo cada vez peor
Ahora simplemente lo dejo pasar con un “si no funciona, pues no funciona”. La vida es corta y no me sobra tiempo para arreglar también el código de otros
Cuando intentas arreglar un problema, al final terminas cayendo en "yak shaving"
Cuando intentas resolver un problema menor, se van encadenando tareas detalladas una tras otra
El video relacionado se puede ver aquí
A veces ordenar las herramientas y librerías hace que la productividad explote, y otras veces simplemente empujar con hardcoding es más rápido
La IA ayuda a pulir las herramientas, pero al mismo tiempo amplía el alcance y al final terminas dedicando el mismo tiempo a administrarlas
Al final, es un problema de procrastinación emocional. No quieres pensar en la estructura completa y repites solo pequeños ajustes, o al revés, pospones el diseño general y solo te pones a pulir herramientas específicas
En realidad, también es un proceso de lidiar con fricción e incomodidad necesarias
Pero siempre hay que revisar si esa incomodidad realmente es necesaria
Invertir 10 o 15 minutos en automatizar o acortar una tarea repetitiva al final es como comprar tiempo para el futuro
Al final, la deuda técnica en algún momento hay que pagarla, así que conviene adquirir el hábito de ir pagándola poco a poco
La ingeniería al final es una continuidad del proceso de afilar el hacha
Me gusta el enfoque de Kent Beck: “primero haz que el cambio sea fácil, y luego haz el cambio fácil”
Mejorar el código fue mucho más satisfactorio que simplemente agregar una función
Como la IA no considera raro repetir el mismo código varias veces, no termina estructurando ni reutilizando bien
En la práctica, es más realista volver a afilarla cuando se va desafilando a mitad del trabajo
“¡Ahora estoy demasiado ocupado para afilar el hacha!”, dicen, y siguen trabajando de forma ineficiente
Me impactó la frase: “las ganas de arreglar el bug en realidad ocultaban el hecho de que primero había que arreglar la herramienta”
Kenneth Stanley también aborda este fenómeno en 『Why Greatness Cannot Be Planned』
Es un gran consejo. Yo también intento ponerlo en práctica todos los días
Pero el consejo que viene después, “ya deja de arreglar herramientas y arregla el problema de verdad”, no lo sigo tan bien
A mí también me pasa mucho esto
Arreglar una pequeña fricción te ahorra tiempo después, pero existe la trampa de quedarte toqueteando solo las herramientas sin parar
Lo verdaderamente difícil es identificar el momento en que dices “con esto basta” y seguir adelante
Las herramientas son algo que multiplica el efecto del esfuerzo
Pero es difícil encontrar el equilibrio entre el "yak shaving" y el trabajo manual innecesario
Si planeas usar la misma herramienta a largo plazo, incluso una mejora del 1% tiene un gran efecto acumulado, así que quizá haya que inclinarse más hacia el "yak shaving" de lo que uno pensaría
La mayor lección es que las herramientas todo en uno casi siempre son malas
Probé herramientas no-code como Make, Airtable y n8n para un pipeline de contenido, pero a partir de cierta escala todas se rompen
Al final, hacer llamadas a la API directamente con scripts en Python fue mucho más estable
La verdadera solución no fue arreglar herramientas complejas, sino reemplazarlas por herramientas simples y transparentes
Ver directamente el flujo del código con un debugger es muy útil
Se puede entender de forma mucho más intuitiva que con análisis estático
Si sigues cambiando variables o breakpoints, es fácil perder de vista la esencia del problema
El debugger debería usarse solo como herramienta para comprobar hipótesis. Si no, uno cae en la ‘ilusión de estar avanzando’
Si te gustan textos como este, me dan ganas de bromear diciendo que jamás instales Emacs