Soy programador autodidacta y este es el consejo que me habría ahorrado 2 años

Si hoy pudiese volver a 2022, me sentaría conmigo mismo y me diría una sola frase: deja de ver tutoriales. La respuesta siempre ha estado en otro sitio.

No tengo título de ingeniería informática. No he pisado un bootcamp. Todo lo que sé de programación lo aprendí por mi cuenta, a base de romper cosas, arreglarlas y volver a romperlas. Gestiono más de 10 proyectos simultáneos — desde este mismo sitio web hasta automatizaciones con agentes de IA que corren en una Raspberry Pi 5 en mi salón. Y si hay algo que me habría ahorrado al menos dos años de frustración, es esto: los tutoriales no son tu amigo.

Suena contradictorio, lo sé. Cuando empecé, yo también vivía pegado a YouTube. Creía que ver a alguien escribir código frente a una pantalla me convertiría en programador. Spoiler: no funciona así.

El infierno de los tutoriales — y cómo salí de él

Hay un término que circula por foros como Reddit y que describe exactamente lo que yo viví: "tutorial hell". Es esa sensación de acabar un tutorial tras otro, sentir que entiendes todo mientras lo ves... y quedarte completamente en blanco cuando abres un editor vacío.

Me pasó docenas de veces. Seguía un tutorial de 45 minutos sobre Flask, hacía exactamente lo mismo que el instructor, y al terminar no era capaz de escribir una ruta por mi cuenta sin volver a Google. El problema no era Flask. El problema era que nunca estaba pensando. Solo copiaba.

El punto de inflexión llegó cuando empecé a leer la documentación oficial de las herramientas que usaba. Al principio fue duro. La documentación de Python, por ejemplo, no está escrita para principiantes. Pero una vez que le coges el ritmo, te das cuenta de algo que ningún tutorial te da: entendés el porqué, no solo el cómo.

Este mismo consejo lo compartió un ingeniero de software autodidacta en Reddit y fue recogido por Genbeta: si quieres avanzar de verdad, anteponé la documentación oficial a cualquier tutorial. No es un atajo, pero es el único camino que te lleva a resolver problemas por tu cuenta.

Por qué los tutoriales te están frenando (aunque no lo notes)

No voy a decir que los tutoriales sean basura. Tienen su momento: cuando necesitás ver cómo se configura una herramienta nueva en 5 minutos, un buen video puede ahorrarte horas. Pero como estrategia principal de aprendizaje, son un desastre. Y tengo tres razones concretas, basadas en mi propia experiencia:

1. Cualquiera puede publicar un tutorial. Y cualquiera lo hace. He visto tutoriales de Docker escritos por gente que claramente estaba aprendiendo Docker mientras lo escribía. El resultado: comandos obsoletos, prácticas de seguridad inexistentes, y una falsa sensación de haber aprendido algo. La documentación oficial, en cambio, la escribe el equipo que construyó la herramienta.

2. Te enseñan a copiar, no a pensar. Un tutorial te muestra "hacé esto, luego esto, luego esto". Pero en el mundo real, los problemas no vienen con un índice de pasos. Cuando monté el sistema de cross-linking automático de este sitio, ningún tutorial me decía cómo extraer keywords de 180 artículos y encontrar relaciones semánticas entre ellos. Tuve que leer el código fuente de la librería de TF-IDF y entender cómo funcionaba por dentro.

3. Google ya no te lleva a las mejores fuentes. El SEO ha contaminado las búsquedas. Como señala el artículo de Xataka, los motores de búsqueda premian contenidos optimizados para posicionar, no para enseñar bien. Si buscás "cómo hacer deploy de FastAPI", los primeros 5 resultados probablemente sean posts de marketing de plataformas cloud, no documentación técnica.

Lo que hago yo ahora — y que ojalá hubiese hecho desde el día 1

Después de años de prueba y error, tengo un método que me funciona. No es elegante, pero es brutalmente efectivo:

Primero, la documentación oficial. Siempre. Antes de buscar en Google, antes de abrir YouTube, abro docs.python.org, caddyserver.com/docs, o la referencia de la librería que esté usando. Los primeros 10 minutos duelen. Los siguientes 10 empiezan a tener sentido. A partir del tercer día, ya no querés volver a los tutoriales.

Segundo, leé el código fuente. Cuando la documentación se queda corta — y se queda corta más veces de las que admiten — no hay sustituto para leer el código. Cuando mi Raspberry Pi 5 dejó de responder por Caddy después de una actualización, ni Google ni ChatGPT me dieron la respuesta. La encontré leyendo el código fuente del módulo de Caddy que gestiona los matchers de reverse proxy. Resultó ser un cambio en la sintaxis de @bad_bots que la documentación todavía no reflejaba.

Tercero, construí cosas que necesités de verdad. No clones el proyecto de un tutorial. No hagas una "app del tiempo" por décima vez. Construí algo que resuelva un problema tuyo: un script que organice tus descargas, un dashboard para tus finanzas, un bot de Telegram que te avise cuando tu web se cae. Yo construí La Frontera IA entera — desde el sistema de crons automatizados hasta el pipeline de publicación — porque necesitaba un sitio que funcionase solo mientras yo dormía. Y cada bug que resolví (los href vacíos en el index, los slugs nulos en el JSON, los 403 de Caddy) me enseñó más que 100 tutoriales.

Cuarto, usá la IA como mentor, no como muleta. Tengo un SSD NVMe en el que corro agentes de IA para automatizar tareas. Pero no le pido a la IA que me escriba el código. Le pido que me explique por qué mi código falla, que me señale la línea concreta del error, que me muestre alternativas. Es la diferencia entre que te den un pez y que te enseñen a pescar.

El momento en que todo hizo clic

Recuerdo perfectamente el día que entendí que había cruzado la línea. Estaba depurando un bug en el index.html de este sitio: el hero de la homepage se cargaba sin imagen y los links apuntaban a URLs vacías. El problema estaba en el script de regeneración del index, que generaba template literals de JavaScript con variables sin interpolar. Ni Google ni Stack Overflow tenían la respuesta. Pero yo ya había leído suficiente documentación del DOM y de Python como para saber exactamente dónde buscar. Tardé 20 minutos en encontrar la causa raíz y 5 en arreglarla. Hacía dos años, ese mismo bug me habría tenido tres días bloqueado.

Esa es la diferencia. No es que la documentación sea mágica. Es que te entrena para entender sistemas, no para repetir recetas.

No es para todos los momentos, y eso también hay que decirlo

Voy a ser justo: hay situaciones donde un buen tutorial es imbatible. Si necesitás configurar Cloudflare Tunnel en 10 minutos antes de una reunión, el video de 3 minutos de un canal pequeño te salva. Lo que digo no es "nunca veas tutoriales". Lo que digo es: no aprendas a programar viendo tutoriales. Cuando tu objetivo es entender, documentación. Cuando tu objetivo es despachar una tarea concreta, un tutorial rápido puede valer.

El problema es que la mayoría de autodidactas — y yo fui el peor — confunden "despachar tareas" con "aprender". Y así pasan años saltando de tutorial en tutorial sin ser capaces de escribir 50 líneas por su cuenta.

Si estás empezando ahora, no cometas mi error. La documentación da miedo al principio, pero todo lo bueno da miedo al principio. En tres meses te estarás riendo de los tutoriales de 45 minutos que prometen enseñarte "todo sobre React".