Enamorate del problema, no de la solución
O por qué la tecnología no es un fin en si mismo.
Cada vez me pasa más seguido de encontrarme con ofertas laborales del estilo: “Estamos en un proceso super desafiante de migrar todo el backend de la tecnología X a la Y”, “Vení a trabajar con nosotros! tenemos desarrollos en un montón de tecnologías diferentes” o “Estamos reimplementando nuestro frontEnd en el framework pepito4”. Estas ofertas de trabajo son el reflejo de lo que a los programadores les llama la atención a la hora de buscar una empresa en donde trabajar, la tentación pasa por las herramientas a usar más que por los problemas a resolver, el problema (como siempre) es nuestro.
Nuestra industria es joven y como los adolescentes crece atolondrada, con cambios muy rápidos y como consecuencia lógica, con muchos errores. En este contexto es lógico pensar que tener un set de herramientas amplio en cuanto al dominio de lenguajes, paradigmas, frameworks, bibliotecas, etc. a priori parezca un diferencial tentador para agregar a Linkedin. La contradicción se presenta cuando buscar esta amplitud tecnológica pasa a ser más importante que entender los problemas que estas tecnologías vienen a resolver. O en otras palabras, cuando la tecnología se convierte en un fin en si mismo.
A diferencia de lo que muchos devs piensan, es más importante centrarse en el problema y tener una base de fundamentals de la ingeniería de software que van más allá de la herramienta seleccionada para resolverlo. Y por otro lado es mucho más valioso el poder manejar con criterio y responsabilidad el riesgo de implementar determinada tecnología, que de conocer un montón de lenguajes por haberlos utilizado sin una decisión fundamentada en cada caso.
Otro problema relacionado con esto es tomarle tanto cariño a una tecnología en particular (porque en su momento nos permitió solucionar un problema que antes no podíamos, porque dedicamos mucho tiempo en aprenderla y perfeccionarla o por el motivo que fuere), que ofrecemos resistencia a cambiar a otra que resuelva mejor el mismo problema y lo que empieza a pasar es que de a poco y sin darnos cuenta, vamos perdiendo nuestra pata ingenieril y nos volvemos expertos en defender lo que conocemos y el que pierde es el problema en cuestión. Una frase que popularizó Uri Levine, fundador de Waze resume muy bien todo esto:
“Enamorate del problema, no de su solución”
En contraposición a la innovación tecnológica “desenfrenada” de los programadores, están las organizaciones. Quienes se ven obligadas a manejar la amplitud tecnológica con un nivel de riesgo mucho más medido. Nadie quiere quedarse afuera de tecnologías modernas que podrían mejorar determinados atributos de software (robustez, seguridad, facilidad implementativa, velocidad de procesamiento, mejor aprovechamiento de memoria, etc.) en comparación a otras más antiguas; pero nadie quiere tampoco tener un cementerio de aplicaciones todas desarrolladas en lenguajes o frameworks diferentes que nadie sabe, puede o quiere mantener.
Para evitar todo esto, es importante definir un carrer path agnóstico de la tecnología (por ejemplo el que armamos y difundimos públicamente desde Despegar IT que pueden ver ACA) donde queden claro los fundamentals necesarios que un developer tiene que ir adquiriendo para ir creciendo en su path profesional independientemente de los conocimientos puntuales sobre una herramienta en particular.
Si dejamos de entender a la tecnología como un objetivo en si mismo, nos va a resultar más fácil sacar de la adolescencia a nuestra industria.
