La mayoría de los developers estudia demasiado y piensa demasiado poco

La parálisis por análisis

Hace algunos años yo pensaba que crecer como developer era bastante simple, aunque llevaba tiempo, por supuesto.

La fórmula parecía obvia: Más cursos. Más libros. Más tutoriales. Más tecnologías. Más horas de estudio. Estudiar, estudiar, estudiar. Y durante mucho tiempo actué en consecuencia.

Cada vez que sentía que me faltaba algo, estudiaba más. Si no entendía una tecnología, buscaba otro curso. Si aparecía una herramienta nueva, la agregaba a la lista.

Me pasaba que, si veía que alguien sabía más que yo, asumía que necesitaba aprender más cosas. Y claro, siendo junior, en un equipo rodeado de gente con más experiencia, era un bucle bastante desgastante porque en todo momento descubría cosas que no sabía y nunca parecían alcanzarme las horas del día para estudiar.

Mirando hacia atrás, muchas veces ni siquiera estudiaba porque me apasionara aprender.

Estudiaba porque sentía que todavía no era suficiente, porque siempre había alguien que parecía saber más, porque siempre aparecía una tecnología nueva, porque tenía miedo de quedarme atrás.

Y creo que muchos juniors viven exactamente esa sensación.

Dentro de todo ese comportamiento cíclico, con el tiempo empecé a sentirme agotado. Y cuando pude frenar un poco para pensar, me di cuenta de algo que no esperaba: conocía cada vez más conceptos, pero eso no siempre se traducía en mejores decisiones en la diaria.

La trampa silenciosa del aprendizaje infinito

Creo que muchos desarrolladores caemos en una especie de ciclo que parece productivo desde afuera. Por lo menos, a mí me pasó y veo algunos que también llevan el mismo ritmo.

Aprendemos una tecnología (más o menos, como para sentir que la manejamos). Después seguimos con otra, y luego una tercera.

A la par, guardamos artículos que vamos leyendo, comprando cursos y, en definitiva, terminamos dedicando una enorme cantidad de tiempo a incorporar información.

El problema es que aprender cosas nuevas produce una sensación inmediata de progreso, pero pensar profundamente no. Son actividades muy distintas y su diferenciación e importancia son enormes.

prender qué hace una herramienta es relativamente rápido. Entender cuándo usarla, cuándo evitarla y qué problemas introduce suele llevar muchísimo más tiempoA. Y si, eso también es parte de la experiencia que te da el propio crecimiento, el tiempo es inevitable.

Estamos constantemente aprendiendo cosas nuevas y sentimos que estamos creciendo. Pero no siempre es así. A veces simplemente estamos consumiendo información.

Saber más no siempre significa entender mejor

e la mano con esto que mencionaba en el párrafo anterior, algo que me costó bastante entender, fue creer que un desarrollador senior creció y avanza más porque sabe más tecnologías.

Primer error: saber más herramientas o tecnologías, inevitablemente, hace que tengas menos tiempo para especializarte bien en una.

Segundo, y más importante: hay cosas del día a día que no se aprenden en cursos, libros ni nada que pueda estudiarse. Y es lógico, la vida misma es así. Muchas veces se aprende de errores propios y ajenos, se aprende de ver a los que más saben, de escuchar discusiones incómodas.

Como te conté, yo era muy de estudiar.

¡Y qué paradoja que, algunas de las personas más fuertes técnicamente que conocí, no eran las que más conceptos acumulaban! Los que mejor rendían, eran quienes mejor entendían las consecuencias de sus decisiones.

Podían explicar:

• por qué algo estaba diseñado de determinada manera
• qué trade-offs existían
• qué problema resolvía una solución
• qué riesgos aparecían más adelante

Y esa capacidad rara vez se desarrolla consumiendo contenido a toda velocidad. Normalmente aparece cuando uno se obliga a frenar y pensar.

Pensar es incómodo

Y creo que ahí está el verdadero problema. Pensar de verdad consume energía. Mucha.

Es bastante más cómodo terminar otro curso sobre Spring que preguntarse por qué una arquitectura se volvió difícil de mantener. Claro, es un hito. Terminás el curso y podés tener un resultado tangible.

Es más cómodo aprender un framework nuevo que entender por qué una feature aparentemente simple terminó generando cinco bugs en producción.

En líneas generales, es más cómodo incorporar información que cuestionarla. Por eso muchas veces terminamos estudiando cuando en realidad deberíamos estar reflexionando.

La pregunta que cambió mi forma de aprender

Con el tiempo, y la experiencia, empecé a cambiar la pregunta que me hacía después de cada tema nuevo que estudiaba.

En vez de preguntarme: “¿Qué aprendí?” pasé a preguntarme: “¿Qué entendí?”.

Y aunque parecen preguntas parecidas, para mí terminan generando resultados completamente distintos.

Aprender algo nuevo es relativamente fácil, lo difícil es entender las consecuencias de lo que acabás de aprender. O sea, aprenderlo realmente.

Por ejemplo. Supongamos que estudiás Spring Security.

La pregunta clásica suele ser: “¿Cómo funciona?”

Pero las preguntas que realmente te hacen crecer suelen ser otras:

• ¿Qué problema vino a resolver?
• ¿Qué pasaría si no existiera?
• ¿Qué complejidad me está ocultando?
• ¿En qué situaciones podría no usarlo?

O imaginemos que estás aprendiendo sobre microservicios.

La mayoría de los cursos te enseñan cómo implementarlos, pero pocas veces te obligan a preguntarte:

• ¿Qué problema de mi sistema justifica esta complejidad?
• ¿Qué gano realmente?
• ¿Qué pierdo?
• ¿Qué nuevos problemas estoy introduciendo?

Y creo que ahí está una de las diferencias más grandes que fui observando con el tiempo.

Muchos desarroladores estudian buscando respuestas. No obstante, los que más crecen, suelen desarrollar mejores preguntas.

Aprender que existe un patrón de diseño es fácil. Entender cuándo conviene usarlo es otra historia.

Aprender qué hace un framework es relativamente sencillo. Entender qué complejidad está ocultando requiere bastante más trabajo.

Y muchas veces el crecimiento real aparece justamente ahí.

No cuando incorporamos información nueva, sino cuando logramos darle sentido a la que ya tenemos.

Quizás el problema no sea que te falta estudiar

Sé que esto puede sonar extraño en una profesión obsesionada con aprender constantemente. Ni hablar de la velocidad con la que cambia todo en tiempos de inteligencia artificial.

Y ojo, que no digo que no tenés que estudiar, claro que es muy importante y te va a dar muchísimas herramientas para avanzar.

Lo que digo es que, muchas veces, el problema no es la falta de información, sino la falta de procesamiento.

No necesitamos otro tutorial. Necesitamos conectar mejor las ideas que ya tenemos. Relacionarlas, cuestionarlas, aplicarlas, entender por qué funcionan.

Acumular conocimiento puede hacerte sentir ocupado. Ahora, entender profundamente suele ser lo que realmente acelera una carrera.

Y probablemente por eso algunos desarrolladores avanzan muchísimo más rápido que otros sin necesariamente estudiar más horas.

No porque aprendan más. Sino porque dedican más tiempo a entender lo que ya aprendieron.