Nota: Esto es solo una opinión personal. Lo que encontrarás aquí no está en ningún tutorial de YouTube ni en los bootcamps más populares. Y honestamente, creo que necesita ser dicho.
Cuando comencé en el mundo del desarrollo de software, estaba perdido. No sabía dónde empezar y mucho menos dónde terminar. ¿Qué tecnologías debería aprender primero? ¿Frontend o backend? ¿Mobile? ¿Cuál de todas las que veo por ahí?
Me di cuenta de algo importante: hay una cantidad desconcertante de herramientas y tecnologías disponibles. Y la mayor parte del tiempo, no sabemos el porqué ni el para qué de cada una.
Entonces hacemos lo que nos dicen: seguimos un tutorial de React, luego otro de Node.js, otro de Docker. Aprendemos un poco de todo, pero no dominamos nada. Al final, acabamos intentando ser magos del desarrollo de software, tragándonos todo lo que vemos sin detenernos a pensar si realmente es necesario.
Y esto provoca que, después de varios años en la industria, muchas veces nos atasquemos. Aprendemos las herramientas superficialmente, solo lo justo para que funcionen. Nunca profundizamos lo suficiente para sentirnos realmente confiados con lo que estamos haciendo.
Me di cuenta de esto bastante tarde, y fue frustrante.
Nos convencemos de que, con conocer lo rudimentario, ya hemos dominado el conocimiento necesario, cuando en realidad solo obedecemos órdenes de un framework o un entorno de desarrollo.
Es más, nunca nos cuestionamos más allá de eso. Obedecemos las sugerencias del IDE, la estructura sugerida del programa, los complementos de integración, los nombres de las variables, etc.
Nos descargamos de responsabilidad con la ilusión de que no es necesario saberlo, ya que, para eso existen herramientas.
El problema real: confianza vs. conocimiento superficial
¿Te ha pasado? Estás usando VS Code, escribes código, y de repente tu IDE te sugiere una función, una variable, una estructura. Y la aceptas sin más. ¿Por qué? Porque no sabes si está bien o mal. Solo sabes que “funciona”.
Y si te preguntas si necesitas entender los fundamentos, en estos tiempos es común escuchar: “¿Para qué quiero saber cómo funciona un compilador si tengo ChatGPT que me escribe el código?”
La verdad es dura. Cuando te quitas el IDE de encima, cuando quitas el autocompletado, cuando necesitas escribir código sin ayuda… ahí es donde se nota la diferencia. Se nota quién entiende lo que está escribiendo y quién está simplemente copiando y pegando.
Por eso quiero contarte la clave para escapar de este ciclo y avanzar de verdad en la industria.
La solución: aprende los fundamentos, no solo las herramientas
El secreto es simple pero poderoso: aprende a pensar dentro de los fundamentos de cada tecnología. No solo uses las herramientas, entiende por qué existen, qué problema resuelven y cómo piensan las personas que las crearon.
Para entender el lenguaje de programación, no es necesario dominarlo todo. Pero sí necesitas entender conceptos como:
- Cómo se ejecuta el código en la computadora (compilado vs. interpretado)
- Qué es el sistema de tipos y por qué importa
- Qué es realmente una variable (spoiler: es más complejo de lo que parece)
- Cómo funciona el compilador o el intérprete
- Qué significa una instancia y cuándo usarla
A esto me refiero con conocer el lenguaje, al menos uno de cada modo de ejecución: interpretado o compilado. Elige uno de cada tipo, y domínalo bien. No necesitas saber todos los lenguajes, solo necesitas entender cómo funcionan realmente.
Y no, no necesitas aprender todos los lenguajes del universo.
La verdad es simple: elige un lenguaje compilado (como Go, Rust o C++) y uno interpretado (como Python o JavaScript). Domínalos a fondo. Luego añade una tecnología para el frontend (React, Vue, o lo que prefieras) y aprende a manejar datos (SQL al mínimo).
Eso es suficiente para empezar. No hace falta convertirse en el experto de todo. Te lo digo por experiencia: después de dominar dos lenguajes, te darás cuenta de que los fundamentos son muy similares. Los conceptos se trasladan.
Lo importante no es acumular tecnologías, sino entender los fundamentos compartidos entre ellas.
Piensa como un arquitecto de software, no como un codificador
El truco está en cambiar el enfoque: en vez de aprender cada herramienta que pasa por delante, aprende a pensar como la persona que creó esa herramienta.
Cuando una tecnología se vuelve popular, es porque resolvió un problema real. Entonces, antes de usar cualquier herramienta, pregúntate:
- ¿Qué problema resuelve esto que estoy usando?
- ¿Existe una solución que ya lo resuelva?
- ¿Por qué fue creada en primer lugar?
- ¿Qué tenía que hacer la persona que la creó que la llevó a construir esto?
Estas preguntas te ayudarán a entender no solo cómo usar la herramienta, sino por qué existe y cómo piensan los desarrolladores que la crearon.
Y ese es el verdadero conocimiento. Ese conocimiento no se lo quita nadie, y es lo que te convierte de un “codificador de tutoriales” a un desarrollador que realmente entiende lo que está haciendo.
El ejemplo práctico: Git
Vamos con un ejemplo claro: Git.
Todos usamos Git. Sabemos que hacemos git add, git commit, git push. Pero, ¿por qué existe Git? ¿Qué problema resuelve Linus Torvalds (su creador) que lo llevó a construirlo?
Git no es solo una herramienta para guardar código. Es una filosofía de trabajo que resuelve el problema del control de versiones distribuido.
Si entiendes el problema que resuelve, te das cuenta de que Git es útil para muchas cosas más allá del código:
- Un escritor podría hacer ramas de capítulos de su libro, probar diferentes finales, hacer merge de lo que funciona.
- Un diseñador podría trabajar en variaciones de un diseño en ramas paralelas.
- Cualquier trabajo creativo se beneficia del concepto de “ramas” y “commits”.
¿Por qué importa esto? Porque cuando entiendes la filosofía detrás de Git, no solo sabes usar los comandos. Entiendes cuándo usar Git, cuándo no, y cómo adaptar su filosofía a problemas completamente diferentes.
Git fue creado para resolver problemas específicos. Si entiendes esos problemas, entiendes Git. Y si entiendes Git, entiendes cómo pensar en el control de versiones de cualquier cosa, no solo código.
En resumen: el problema no es el stack, es el enfoque
Pasamos horas y horas aprendiendo tecnologías. Hacemos cursos de React, luego de Vue, luego vemos que sale Svelte y corremos a aprenderlo también. Y al final, ¿qué sabemos realmente?
Cuando alguien te pregunta “¿Podrías identificar qué patrón de diseño debería usar aquí?”, ¿sabes responderlo?
Si te dicen “Necesitamos escalar a millones de usuarios, ¿qué arquitectura usarías?”, ¿tienes una idea clara?
Probablemente no. Y eso está bien. El problema no es que no sepas la respuesta, el problema es que no sabes cómo pensar el problema.
El punto al que quería llegar
Cuando entiendes los fundamentos —cuando realmente entiendes el porqué y el para qué de cada herramienta— te das cuenta de que no necesitas aprender todo el stack.
Solo necesitas:
- Conocer bien dos lenguajes (uno compilado, uno interpretado)
- Entender los fundamentos (variables, tipos, compiladores, etc.)
- Aprender a pensar como los creadores de las herramientas que usas
- Enfocar el problema, no la tecnología
El resto es cuestión de aplicar los fundamentos.
Cuando realmente entiendes una herramienta, entiendes todas las similares. Porque al final, los conceptos se trasladan.
Y eso es lo que te hace un buen desarrollador. No saber todos los frameworks, sino entender cómo se resuelven los problemas reales.
¿Aprender cada tecnología nueva que sale? Eso es una trampa.
Aprender a pensar como desarrollador? Eso es lo que realmente importa.
💬 Comentarios
Los comentarios se sincronizan con GitHub Issues. Ver todos los comentarios en GitHub