Cuando empiezas en programación, es muy fácil pensar que crecer consiste únicamente en aprender más tecnología.
Que si aprender un nuevo framework, hacer otro curso, probar la nueva IA de turno, memorizar patrones… y, en definitiva, consumir contenido de programación y desarrollo constantemente.
Es un comportamiento que lo conozco bien porque durante bastante tiempo yo también pensaba así.
Tenía en mi cabeza la errónea idea de que la diferencia entre un programador junior y uno senior estaba, principalmente, en la cantidad de conocimientos técnicos que acumulabas con los años y los estudios.
Y bueno, aunque evidentemente la parte técnica importa muchísimo (aún hoy en día con la IA) con el tiempo me empecé a dar cuenta de que había algo mucho más determinante en mi crecimiento profesional.
Y si, puedo decir sin miedo que la habilidad que más me ayudó a crecer no fue programar.
Fue aprender a comunicar.
Creo que ya te he hablado alguna vez de esto, pero permítame que insista.
Sí, así es, fue comunicarme.
Y no me refiero a dar conferencias, ni a convertirte en una persona extremadamente sociable, ni siquiera a hablar bien en público.
Me refiero a algo mucho más cotidiano y mucho más importante dentro de un equipo de desarrollo: aprender a hacer buenas preguntas, aprender a explicar problemas correctamente y aprender a entender realmente a las personas con las que trabajas.
Porque hay algo que muchas veces no vemos cuando estamos empezando: programar es una profesión mucho más social de lo que parece.
Durante mucho tiempo tuve la idea de que un buen desarrollador era alguien capaz de resolver cualquier problema por sí solo.
Cuanto menos dependieras de otros, mejor programador eras.
Cuanto más tiempo aguantabas bloqueado intentando sacar algo adelante sin pedir ayuda, más mérito tenía.
Pero la realidad de los proyectos profesionales es bastante diferente.
El problema empieza fuera del código
Con los años me he dado cuenta de que los mejores desarrolladores que he conocido no eran necesariamente los que más tecnologías sabían ni los que escribían código más complejo.
Eran los que sabían comunicarse mejor.
Personas que hacían preguntas constantemente.
Que validaban ideas antes de implementar.
Que sabían reconocer rápidamente cuando algo no lo entendían del todo.
Y, sobre todo, personas capaces de traducir problemas técnicos complejos en conversaciones simples y entendibles para el resto del equipo.
Porque en proyectos reales, muchas veces el problema no es la programación en sí, viene de otro lado:
Viene de haber entendido mal el requisito, de no haber detectado un malentendido a tiempo, de no haber preguntado suficiente contexto, de no haber comunicado una limitación técnica importante o de sabido explicar por qué cierta decisión podía convertirse en un problema dentro de unos meses.
Cuándo me di cuenta de esto
Todo esto que te estoy contando no es algo que te pueda enseñar un framework.
Por ejemplo, en mi carrera profesional, hubo un momento donde empecé a notar un cambio bastante grande en mi manera de trabajar y es que dejé de obsesionarme tanto con demostrar constantemente que sabía hacer las cosas y empecé a preocuparme mucho más por entender bien el problema que tenía delante.
Parece una diferencia pequeña, pero cambia completamente la manera en la que aprendes.
Porque cuando empiezas a hacer buenas preguntas, aprendes más rápido.
Cuando entiendes bien el contexto, tomas mejores decisiones técnicas.
Y cuando eres capaz de comunicar dudas pronto, evitas muchísimos errores que después son caros de corregir.
Creo que muchos programadores junior viven con miedo a pedir ayuda porque sienten que eso demuestra falta de nivel. Como si un buen desarrollador tuviera que resolver todo solo y rápidamente.
Pero la realidad es que en equipos profesionales ocurre justo al revés.
Las empresas suelen valorar muchísimo más a una persona que sabe colaborar bien, comunicar bloqueos y trabajar en equipo, que a alguien técnicamente brillante pero incapaz de compartir contexto o alinearse con los demás.
Y esto conecta con algo que me costó bastante entender al principio: comunicar no consiste solamente en hablar bien.
Consiste, sobre todo, en escuchar bien.
Aprende a escuchar antes de hablar
Sí, así es, para aprender a comunicar primero tienes que aprender a escuchar a otros desarrolladores, al equipo de producto, al cliente o, simplemente, es cuchar qué problema se intenta resolver realmente antes de pensar directamente en la solución técnica.
Porque muchas veces nos enamoramos demasiado rápido de la implementación y dedicamos muy poco tiempo a entender el problema de verdad.
Y aquí ocurre algo curioso.
Cuanto más senior se vuelve alguien, menos obsesionado está normalmente con las tecnologías concretas y más importancia le da al contexto, a las decisiones y a los trade-offs.
Por eso muchas veces los seniors parecen más lentos.
Porque antes de escribir código intentan entender correctamente qué merece la pena construir y cuál es la mejor manera de hacerlo en ese contexto concreto.
Y sinceramente, creo que esa mentalidad marca muchísimo más la diferencia profesional que saberse de memoria un framework nuevo cada seis meses.
Si tuviera que darle un consejo a alguien que está empezando, probablemente sería este:
No centres todo tu crecimiento únicamente en aprender tecnologías.
Aprende también a comunicar ideas.
A explicar problemas.
A pedir ayuda sin sentir vergüenza.
A escuchar antes de implementar.
Y a entender realmente el problema antes de pensar en la solución.
Porque muchas veces la diferencia entre un programador junior y uno senior no está solamente en el código que escribe.
Está en cómo piensa, cómo se comunica y cómo trabaja con las personas que tiene alrededor.
Y, curiosamente, esa terminó siendo la habilidad que más hizo crecer mi carrera como desarrollador.
Nos leemos el próximo domingo.
Julián.
Publicado originalmente en CERO a SENIOR.