He visto a desarrolladores pasar meses con cursos, tutoriales y documentación, y seguir sin sentirse listos para construir algo real. También he visto a desarrolladores con la mitad del "tiempo de estudio" lanzar apps a producción que realmente funcionan. La diferencia no es talento. Es método.
Los que construyen aprenden más rápido que los que estudian. Construir fuerza una relación distinta con el conocimiento: tomas las decisiones en vez de mirar cómo las toma otro.
La trampa del tutorial
Los tutoriales se sienten productivos. Sigues los pasos, todo funciona, entiendes cada paso. Pero hay un costo oculto: estás aprendiendo las decisiones del instructor, no tomando las tuyas.
- Ves a alguien configurar auth
- Copias el código paso a paso
- Funciona (porque fue diseñado para funcionar)
- Siguiente tutorial
- Cuando enfrentas auth en un proyecto real: no sabes por dónde empezar
- Decides que necesitas auth en tu proyecto
- Investigas opciones (sessions vs JWT vs OAuth)
- Escoges una y la implementas
- Te encuentras 3 bugs que no esperabas
- Los arreglas. Ahora sí entiendes auth.
La diferencia crítica: cuando construyes, te metes en la zona pantanosa — esa parte entre "entiendo el concepto" y "funciona en producción". Ahí es donde ocurre el aprendizaje real.
La investigación es clara: activo le gana a pasivo
Hay ciencia rigurosa detrás de esto. Un metaanálisis de 225 estudios publicado en PNAS por Freeman et al. encontró que los estudiantes en entornos de aprendizaje activo obtuvieron un 6% más en exámenes y fueron 1.5x menos propensos a reprobar en comparación con las clases pasivas tradicionales.
La confirmación más reciente es un ensayo aleatorizado de 2024 con estudiantes de medicina. La evidencia sigue acumulándose — la participación práctica le gana a la absorción pasiva, y los tutoriales se sienten productivos sin serlo.
El premio Nobel Richard Feynman formalizó este insight en lo que hoy se conoce como la Técnica Feynman: si no puedes explicar algo de forma simple, no lo entiendes realmente. Enseñar te fuerza a cerrar la brecha entre "lo entiendo" y "puedo explicarlo".
Por qué los side projects aceleran tu carrera
Los side projects hacen más que enseñarte. Crean un portafolio visible de buen criterio: prueba de que sabes tomar decisiones, no solo seguir instrucciones.
Cuando publicas un proyecto, muestras lo que una lista de tecnologías no puede. Escogiste una base de datos, un framework, una forma de desplegar — y te hiciste cargo de esas decisiones. Sopesaste trade-offs reales y te comprometiste con uno, que es buena parte de lo que de verdad es la ingeniería senior. Y terminaste, algo que la mayoría de desarrolladores nunca hace.
Lo que los hiring managers realmente buscan
Después de entrevistar a más de 100 ingenieros, el patrón es claro: los candidatos más fuertes no son los que tienen más certificaciones. Son los que pueden explicar por qué tomaron decisiones técnicas específicas en sus proyectos.
"Usé Prisma en vez de SQL crudo porque el equipo era pequeño y moverse rápido importaba más que optimizar queries" me dice más que "tengo 5 años de experiencia en bases de datos".
Un proyecto lanzado con decisiones reales le gana a un CV con tecnologías listadas.
El efecto compuesto de construir en público
Hay un efecto compuesto que la mayoría no ve. Cuando construyes y compartes públicamente:
- Aprendes la cosa al construirla.
- La solidificas al escribir sobre ella.
- Quienes leen tu post te dan feedback.
- Sus preguntas exponen huecos que aún no puedes responder.
- Llenas esos huecos en el siguiente proyecto, y el ciclo se repite.
Cada proyecto hace mejor al siguiente, técnicamente y en cómo piensas sobre los problemas. Desarrollas una intuición que ningún tutorial puede enseñar.
Cómo empezar
El perfeccionismo frena más proyectos que la falta de habilidad. El antídoto:
-
Escoge un problema que realmente tengas. No un "proyecto de práctica" — algo que vayas a usar. La motivación para terminar es 10x mayor cuando eres tu propio usuario.
-
Mantén la primera versión en un fin de semana, no un mes. Lanza el MVP vergonzoso; siempre puedes iterar.
-
Escribe una cosa sobre ello — un post, un hilo, un README con las decisiones reales. Enseñar es el multiplicador.
-
Ponlo en línea, en algún lugar real.
- Fin de semana 1
Construye la feature core. Hazle deploy.
Un proyecto en localhost es un borrador; una URL lo vuelve real.
- Fin de semana 2
Arregla las tres cosas que más te molestan.
Ahora eres tu propio usuario: la lista se escribe sola.
- Fin de semana 3
Escribe sobre lo que aprendiste.
Enseñar es el multiplicador.
- Después
Repite con la siguiente idea.
El conocimiento que no se googlea
Hay un tipo de conocimiento de ingeniería que no existe en ninguna documentación. Vive en la brecha entre "sé cómo funciona X" y "sé qué pasa cuando X se encuentra con Y en producción".
No puedes llegar a ese conocimiento leyendo. Solo puedes construirlo. Michael Polanyi lo llamó conocimiento tácito — el tipo de saber que solo se adquiere a través de la experiencia, no de la instrucción.
"Lo que no puedo crear, no lo entiendo." — Richard Feynman (escrito en su pizarra al momento de su muerte, 1988)
Así que escoge eso que llevas tiempo queriendo estudiar y construye una versión mala este fin de semana. Vas a aprender más de sus bugs que del curso que nunca terminas.
Lectura adicional:
- Active learning increases student performance in STEM, Freeman et al., PNAS
- La Técnica Feynman, Farnam Street
- Building Beyond the Job: Dev Side Projects in 2025, DEV Community
- New Research Shows Learning Is More Effective When Active, Carnegie Mellon
Conversación
Los comentarios viven en GitHub Discussions — inicia sesión con GitHub para responder.