La pregunta que más mejoró mis decisiones técnicas

Me pasó varias veces, al tener que resolver o refactorizar algo, de sentarme a pensar cuál era la mejor forma de encararlo.

Analizaba alternativas, buscaba argumentos y dedicaba bastante tiempo a investigar cómo implementarlo.

Y sí, muchas veces funcionó.

Pero siempre sentí que me faltaban cinco para el peso.

Con el tiempo, la experiencia, y buenos compañeros, surgió una pregunta que me parece que me dió un plus.

Una sola.

“¿Qué problema estamos intentando resolver?”

Y me dejó completamente descolocado, porque era cómo “y sí, obvio”.

Porque tenía clarísima la solución.

Pero no tenía tan claro el problema.

Y pienso cuántas veces eso nos pasa, a mayor o menor escala, en nuestro día a día.

No solamente escribiendo código, sino también diseñando arquitecturas, refactorizando módulos, aprendiendo tecnologías nuevas. Incluso tomando decisiones de carrera.

Muchas veces nos enamoramos de una solución antes de entender realmente el problema.

Queremos usar un patrón porque parece elegante.

Queremos implementar microservicios porque funcionan en empresas grandes.

Buscamos aprender una herramienta porque todo el mundo habla de ella, o hasta refactorizar un módulo porque “el código está feo”.

Pero pocas veces nos detenemos a preguntarnos si eso es realmente lo que necesitamos.

A partir de esa pregunta, me fui dando cuenta de que muchos errores técnicos no ocurren porque elegimos una mala solución.

Ocurren porque resolvemos el problema equivocado.

He visto equipos discutir durante semanas qué tecnología usar para resolver un problema de escala que todavía no existía.

También he visto desarrolladores dedicar días enteros a refactorizar componentes que nadie volvía a tocar.

Y más de una vez vi personas pasar meses aprendiendo herramientas avanzadas cuando todavía tenían dificultades para leer código ajeno o debuggear una aplicación en producción.

La solución puede ser excelente. Pero si el problema está mal entendido, el resultado sigue siendo malo.

Creo que una parte importante del criterio técnico empieza a construirse cuando dejamos de obsesionarnos con encontrar respuestas rápidas y empezamos a dedicar más tiempo a entender qué está pasando realmente.

Porque la diferencia entre un desarrollador que simplemente implementa tareas y uno que aporta valor suele estar ahí. En la calidad de las preguntas que hace.

Hoy sigo cometiendo errores, sigo proponiendo soluciones que después descarto, sigo entusiasmándome con ideas que terminan no teniendo sentido.

Pero hay una pregunta que intento hacerme cada vez más seguido:

“¿Qué problema estoy intentando resolver?”

Porque muchas veces la decisión correcta aparece bastante antes de encontrar la respuesta.

Aparece cuando finalmente entendemos la pregunta.

¿Qué pregunta sentís que más te ayudó a crecer profesionalmente?