Asumir es el bug más caro que existe

Hay developers que cierran tickets a velocidad de crucero. Y hay developers que construyen producto. Y no, no es lo mismo. La diferencia no está en el lenguaje que dominan. Está en lo que hacen antes de abrir el IDE.

Durante mucho tiempo, la narrativa en tech ha sido la misma: aprende más, certifícate más, practica más. "Domina React. Aprende TypeScript. Súbete a la ola de Rust." El valor de un developer se medía casi exclusivamente por lo que sabía hacer con el código.

Pero hay una habilidad que rara vez aparece en las ofertas de empleo, que no tiene curso en Udemy ni similares y que, sin embargo, marca una diferencia abismal en la calidad del trabajo que produce un equipo: saber qué preguntar antes de escribir la primera línea.

El bug que no salta en ningún test

Imagina a un developer que recibe un ticket, lo lee, entiende lo que pide y lo implementa. El código funciona. El PR pasa la review. El sprint se cierra. Todo correcto.

Tres semanas después, alguien tiene que construir encima de eso. Y no puede. Porque la solución estaba pensada para la tarea, no para el producto.

"Cuando empecé, mi proceso era lineal: ticket, solución, código. Rapidez. Sin molestar a nadie con preguntas... Pensaba que la información estaba en el ticket y que si faltaba algo, ya me lo dirían. Pero nunca hacía preguntas de contexto. Y cuando picas código sin contexto, estás tomando decisiones a ciegas."

Las preguntas que cambian cómo se construye

Hay cuatro preguntas que cualquier developer puede hacerse antes de tocar código. Ninguna requiere saber más de lo que ya sabes y todas cambian lo que produces bajo tus manos.

Antes de cerrar

Manuel no necesitó que le convenciéramos de escribir esto. Solo necesitó que le preguntáramos. Y eso, curiosamente, dice mucho de él y también de lo que cuenta el artículo.

Gracias, Manuel González Santamaría, por compartir lo que aprendiste de la forma más difícil: haciéndolo mal primero.