¿Cómo ser mejor desarrollador? ¿Cómo subir de nivel? ¿Cómo llegar a senior (o lead, o principal, o lo que sea? Cuántas veces hemos oído, o nos hemos planteado, estas preguntas.

La mayor parte de las veces, buscar cómo mejorar en lo que hacemos (como desarrolladores de software, como emprendedores o, simplemente como profesionales) nos lleva a seguir apilando más y más capas de aprendizaje, abstracciones, tecnologías y técnicas. 

Esto tiene todo el sentido del mundo, como knowledge workers es parte del juego, pero, ¿y si volviéramos a los básicos, a los orígenes de todo y nos hiciésemos las “primeras preguntas” cuestionando las bases de lo que hacemos?

A veces hay que volver a los básicos, retornar a la raíz y dejar atrás todo para encontrar los principios de lo que hacemos. 

Especialmente en estos tiempos en los que la inteligencia artificial sobrevuela todo lo que hacemos, resulta, si cabe, aún más primordial plantearnos ¿qué es lo que hacemos? y aún más, ¿qué es lo que hace especial lo que hacemos? ¿Qué significa “ser buenos” en lo que hacemos?

Mucha gente piensa que el trabajo de un desarrollador de software es “hacer código”, si eres de los que piensan así tengo malas noticias, igual ya estás fuera del mercado y todavía no te lo han dicho, y no, no soy de los que piensan que la IA nos va a quitar el trabajo así de la noche a la mañana en plan “rebelión de las máquinas”, para eso tendríamos que ser muy buenos diciéndole a la IA lo que queremos que haga, y viendo lo regular que se nos da, como especie y como industria, explicar lo que queremos que haga un sistema, creo que una parte importante de nuestro trabajo está bien a salvo. A lo que me refiero es a que ser desarrollador de software es “algo más” que escribir código. 

Pero volvamos a lo de las “primeras preguntas” ¿Qué es un desarrollador de software?

Si se lo preguntamos al oráculo de estos tiempos modernos (si, me refiero a ChatGPT), nos responde lo siguiente:

“Un desarrollador de software es un profesional que se dedica a crear, diseñar, mantener y probar programas informáticos o aplicaciones. Su trabajo implica entender las necesidades del usuario o cliente y luego utilizar lenguajes de programación, herramientas y técnicas específicas para escribir código y construir soluciones de software funcionales y eficientes.”

No anda desencaminado el cacharro, vayamos por partes.

“Un profesional que se dedica a crear, diseñar, mantener y probar programas informáticos o aplicaciones”

Correcto. Esta parte la tenemos todos clara me parece, de hecho así es como nos formamos, creamos proyectos, diseñamos soluciones, algoritmos, etc.

Para mi la parte crucial viene en la segunda parte de la respuesta.

“Su trabajo implica entender las necesidades del usuario o cliente y luego utilizar lenguajes de programación, herramientas y técnicas específicas para escribir código y construir soluciones de software funcionales y eficientes.”

Date cuenta de cómo está estructurada la frase. 

Primero “entender las necesidades del usuario o cliente” y luego, sólo luego, después de lo primero (no menos importante, pero si “luego”) “utilizar lenguajes de programación, herramientas y técnicas específicas para escribir código y construir soluciones de software funcionales y eficientes.”. Interesante. 

---

Creo que con este simple ejercicio hemos llegado a algo básico, primero es entender qué hacemos, porqué lo hacemos, para quién y con qué finalidad y luego pasamos a las herramientas.

Reflexionemos un minuto sobre este orden de los factores, porque puede que en este caso el orden de los mismo si que pueda alterar el producto final.

¿Cuánto tiempo pasas al día “utilizando lenguajes de programación, herramientas y técnicas” y cuánto tiempo “entendiendo las necesidades del usuario o cliente”?

¿Cuántas veces un proyecto fracasa por los lenguajes de programación, por las herramientas o las técnicas y cuántas por no haber dedicado el tiempo a entender las necesidades del usuario?

Puedo oír a algunos al final de la sala murmurando que eso es trabajo de otros, del product owner, de “los de diseño”, del jefe, o de quién sea, nosotros somos sólo desarrolladores. Igual llevan parte de razón, pero, ¿somos buenos desarrolladores si nos quedamos sólo en la primera parte de la respuesta?

En mi opinión no podemos llegar a ser buenos desarrolladores si sólo nos centramos en una de las dos caras de la moneda, tan importante es el foco en la excelencia técnica como el foco en las interacciones con personas y el product thinking, puede que para muchos esto sea evidente, pero creo que tenemos que enfocarnos en aplicarlo en nuestro día a día si de verdad aspiramos a producir trabajo que merezca la pena.