Aprende a programar con freeCodeCamp y lánzate al desarrollo

Si llevas un tiempo curioseando el mundillo del código, seguro que te has dado cuenta de que hay tanta formación gratuita que es fácil bloquearse. Plataformas, cursos sueltos, vídeos, newsletters, bootcamps… y tú solo quieres una ruta clara para aprender a programar sin arruinarte ni perder meses dando palos de ciego.

En este contexto, freeCodeCamp es casi un oasis: una organización benéfica que ofrece un plan completo para aprender a programar gratis, con proyectos prácticos, comunidad global, certificaciones y muchos recursos en español. Y, ojo, además de aprender a picar código, su filosofía está muy orientada a algo muy concreto: ayudarte a conseguir tu primer trabajo como desarrollador o a dar un giro profesional sólido hacia el desarrollo de software.

Qué es exactamente freeCodeCamp y por qué es diferente

freeCodeCamp no es una academia online más: es una organización benéfica 501(c)(3) sin ánimo de lucro, sostenida por donaciones (su NIF federal en EE. UU. es 82-0779546). Su misión es clara y directa: ayudar a cualquier persona, viva donde viva, a aprender a programar sin pagar un céntimo.

Para lograrlo, han montado un ecosistema brutal: miles de vídeos, artículos y lecciones interactivas que puedes hacer desde el navegador, sin instalar nada raro. Todo el contenido es público y gratuito, y además hay más de mil grupos de estudio repartidos por todo el mundo, donde la gente se junta para aprender y apoyarse mutuamente.

El dinero de quienes donan se destina a mantener servidores, servicios y al pequeño equipo remunerado que coordina el proyecto. Nadie te obliga a pagar nada, pero si freeCodeCamp te ayuda a conseguir tus objetivos profesionales, siempre puedes devolver el favor con una donación deducible de impuestos.

Algo muy importante, sobre todo si el inglés no es tu fuerte: el portal principal y muchos cursos ya están disponibles en español. Puedes hacer el currículo desde la web de freeCodeCamp en español y seguir rutas completas de Front-End, Back-End, Python, análisis de datos, IA y mucho más, sin salir de tu idioma.

Cómo funciona freeCodeCamp: aprender programando desde el primer día

La idea de freeCodeCamp es muy sencilla: aprender haciendo proyectos, no solo viendo teoría. En lugar de un montón de vídeos pasivos, te propone un currículo estructurado en certificaciones y módulos, donde cada lección va acompañada de ejercicios prácticos que tienes que resolver escribiendo código en un editor integrado.

Cada certificación se compone de decenas de retos guiados y varios proyectos finales. En los retos, te explican un concepto (por ejemplo, cómo maquetar una página con HTML y CSS o cómo hacer una petición HTTP con JavaScript) y justo debajo tienes el editor con el código de ejemplo y las instrucciones. Tu misión es modificar ese código hasta que pase los tests automáticos y puedas avanzar.

En los proyectos finales, ya no tienes el paso a paso. Te dan una lista de requisitos (“tu app debe tener tal formulario, tal funcionalidad, tal endpoint…”) y tú tienes que montar la solución completa desde cero. Por ejemplo, puedes acabar construyendo una pequeña página sobre gatitos con diseño responsive o una API REST con Node y Express que guarde datos en una base de datos.

Si en algún momento te atascas, casi seguro que no estás solo con el problema: freeCodeCamp tiene un foro muy activo y comunidades en Discord donde la misma duda ya habrá salido mil veces. Buscas el error, lees lo que han hecho otros y sigues adelante. Esta dinámica de “atasco-búsqueda-solución” es, de hecho, una parte clave de aprender a programar de verdad.

Para la gente que utiliza lectores de pantalla u otras ayudas técnicas, el entorno de freeCodeCamp es bastante accesible. El editor funciona razonablemente bien con la mayoría de lectores, y los textos se presentan en formatos simples y legibles. Como truco práctico, recomiendan copiar el código del ejercicio a tu editor favorito, trabajar allí y luego pegarlo de vuelta para ejecutar y validar, lo que ayuda a evitar algunos problemas puntuales de accesibilidad si la ventana del navegador no muestra todo el editor.

Qué puedes aprender: del Front-End a la computación científica

El currículo de freeCodeCamp está pensado para que, si lo completas con calma, salgas con un perfil muy sólido de desarrollador web y científico de datos junior. No se limita a un lenguaje de moda: se centra en las tecnologías que más se usan en empresas reales y que llevan décadas demostrando su utilidad.

En la parte de Desarrollo Front-End, aprenderás HTML, CSS y JavaScript a fondo. No solo la sintaxis, sino cómo construir interfaces reales, maquetar con diseño responsive, entender cómo funciona el DOM, manejar eventos y trabajar con frameworks y librerías que se apoyan en estas bases.

En Back-End, el enfoque pasa por tecnologías muy consolidadas: SQL para bases de datos relacionales, Git para control de versiones, Linux y servidores web. Aprendes a levantar servicios, gestionar rutas, conectar aplicaciones con bases de datos y desplegar tu código en entornos similares a los que usan las empresas.

También hay una rama muy potente de computación científica con Python. A través de sus cursos en Python, te introduces en el análisis de datos, el cálculo científico y el machine learning utilizando las librerías más comunes del ecosistema (NumPy, pandas, scikit-learn, etc.). Todo ello, de nuevo, con enfoque práctico y proyectos reales.

Un detalle clave: estas tecnologías no son modas pasajeras. HTML, CSS, JavaScript, SQL, Linux, Python… llevan más de dos décadas en producción y lo seguirán estando. Aprenderlas te da una base que te vale para casi cualquier tipo de trabajo técnico al que quieras aspirar.

El libro-guía de Quincy Larson: aprender a programar y vivir de ello

Detrás de freeCodeCamp está Quincy Larson, un exprofesor de inglés que, en sus treintaytantos, decidió que quería aprender a programar sin formación previa en informática y conseguir un trabajo como desarrollador. En un año lo logró, sin gastarse dinero en cursos caros, tirando de recursos gratuitos, muchos paseos nocturnos dándole vueltas a la cabeza y una buena dosis de cabezonería.

Todo lo que aprendió en ese proceso -y en los años posteriores trabajando como ingeniero de software y dirigiendo freeCodeCamp- lo ha volcado en un libro completo disponible de forma gratuita en la web: “How to Learn to Code and Get a Developer Job”. El libro está íntegro en un artículo larguísimo y también en formato audiolibro (episodio 100 del podcast de freeCodeCamp).

En lugar de vender esa guía a través de una gran editorial (llegó a tener una oferta sobre la mesa), Quincy decidió publicarla gratis, abierta para todo el mundo. Su razonamiento es sencillo: la información quiere ser libre, y lo que a él le hubiera encantado tener al empezar era justo lo que ahora ha plasmado en ese contenido.

El libro arranca con un prefacio muy honesto: está pensado para cualquiera que se plantee una carrera en desarrollo de software. Da igual si eres joven sin experiencia laboral, si tienes familia y poco tiempo, si vives lejos de los grandes polos tecnológicos o si arrastras obstáculos como edadismo, racismo, sexismo, problemas de salud, estatus migratorio o incluso un historial delictivo. No te va a engañar: habrá gente para la que el camino sea más duro, pero intenta darte consejos prácticos adaptados a realidades diversas.

Un punto en el que insiste mucho es que aprender a programar es sobre todo un reto de motivación, no de talento innato. La mayoría de quienes lo intentan se frustran, lo dejan… y algunos vuelven unos días después. Esa capacidad de volver, de insistir, de tolerar el bombardeo constante de errores, es lo que acaba marcando la diferencia.

Capítulo 1: cómo desarrollar tus habilidades de programación

La primera parte del libro se centra en cómo aprender a programar de la manera más eficiente posible. Quincy arranca contando su propia historia: un profesor de inglés que quería reducir el papeleo de sus compañeros y termina descubriendo, casi sin darse cuenta, que estaba empezando a automatizar tareas con macros de Excel y herramientas como AutoHotKey.

A partir de ahí, describe una etapa que muchos viven: el famoso “infierno de los tutoriales”. Empiezas un tutorial de Ruby, te atascas en un error que no aparece en la guía, saltas a uno de Python, luego a un libro de JavaScript… y al final has leído cien páginas de mil sitios sin terminar nada ni construir proyectos propios.

Su salida de ese bucle vino vía comunidad: un hackerspace local en Santa Bárbara, lleno de soldadores, Arduinos, tiras LED y gente trasteando con código por puro placer. Allí conoce a Steve, un desarrollador enamorado de Python, que le da un consejo muy simple pero demoledor: “Siempre ten un proyecto. Aprende lo que necesites por el camino para sacarlo adelante.”

De ese empujón sale su primer proyecto “serio”: una página de documentación en HTML5, con una tabla de contenidos en una barra lateral y contenido semántico. No es nada que vaya a revolucionar el sector, pero lo importante es que es la primera vez que termina algo, que lo presenta en público y que recibe feedback, correcciones, apoyo y cierta sensación de pertenencia a una comunidad técnica.

A partir de ahí, el capítulo se mete en harina: aprender a programar es duro porque las herramientas siguen siendo relativamente primitivas, el proceso es muy ambiguo y la retroalimentación es un aluvión de errores. La gracia de tools como GPT-4 o Copilot es que nos acercan a una programación más declarativa (“quiero que hagas esto”) pero, de momento, si quieres ser desarrollador profesional, no te libras de entender cómo funciona la base.

Para manejar esa ambigüedad, el libro recomienda tres cosas muy concretas: aceptar que perderte es parte del camino, aprender a buscar y a leer documentación como un loco, y acostumbrarte a recibir feedback negativo constante sin venirse abajo. Aquí introduce técnicas como la “depuración con patito de goma”: explicarle el problema en voz alta a un objeto inanimado (un pato de goma, un cactus, el gato…) suele desbloquearte más de lo que parece.

Capítulo 1 (II): qué aprender exactamente y por dónde empezar

Una vez asumes que el aprendizaje va a ser caótico, llega la gran pregunta: ¿qué lenguaje y qué stack elijo? Quincy es muy claro: el lenguaje concreto da un poco igual a largo plazo, pero para arrancar, si tu objetivo es trabajar en desarrollo web, empezar con HTML, CSS y JavaScript es lo más lógico.

JavaScript, dice, es la “navaja suiza” del desarrollo. Puedes usarlo en el navegador, en el servidor con Node.js, en aplicaciones de escritorio, móviles, IoT… y hay una demanda inmensa de gente que lo maneje bien. Aprenderlo bien te abre puertas tanto al Front-End como al Back-End.

Junto a eso, recomienda encarecidamente dominar Linux y Git. Linux porque la mayoría de los servidores del mundo corren alguna distribución de este sistema operativo, y como desarrollador vas a pasarte media vida en una terminal. Git porque es la herramienta estándar para control de versiones y trabajo en equipo sobre una misma base de código.

En el lado de datos, insiste en aprender SQL y bases de datos relacionales antes de volverte loco con NoSQL. Comprender bien el modelo relacional y cómo estructurar consultas te da una base potente para cualquier cosa que hagas después. Sobre servidores, propone empezar con Node.js y Express.js para el Back-End, lo justo para entender rutas, middleware, APIs y cómo conectar todo esto con tus frontales en HTML, CSS y JS.

La lista de herramientas clave en las que, según él, deberías centrar el 90% de tu tiempo al principio es: HTML, CSS, JavaScript, Linux, Git, SQL, Node y Express. Con eso puedes montar la mayoría de aplicaciones web típicas que se construyen en empresas y estar en buena posición para tu primer puesto junior.

¿Dónde encaja freeCodeCamp en todo esto? En que su currículo central está diseñado justo alrededor de estas tecnologías. Si sigues las certificaciones principales, acabarás tocando Front-End, Back-End, matemáticas de ingeniería y computación científica con Python. Y además, ahora tienes casi mil cursos en su canal de YouTube (incluido contenido en español) para profundizar en temas concretos.

Capítulo 1 (III): autoformación, universidad y otras rutas

Otro bloque importante del libro se centra en cómo encaja todo esto con la educación formal. Quincy no demoniza la universidad; de hecho, reconoce que un grado en informática sigue siendo una credencial muy valiosa, sobre todo para abrir puertas en empresas grandes y en algunos países donde los títulos pesan muchísimo en procesos de selección y visados.

Ahora bien, también deja claro que no necesitas un título en informática para ser desarrollador profesional. Hay muchísima gente en el sector que se considera, al menos en parte, autodidacta. Incluso quienes han cursado un grado pasan luego su carrera aprendiendo tecnologías nuevas por su cuenta.

Su consejo es bastante sensato: si eres joven y tienes la opción razonable de ir a la universidad sin endeudarte hasta las cejas, un grado puede darte más opciones y mejor salario de salida. Si ya estás más mayor o tienes responsabilidades familiares, puede tener más sentido apoyarte en programas online más flexibles (menciona ejemplos como Western Governors University, University of the People o programas de extensión de universidades públicas) y combinarlo con estudio autónomo serio.

Respecto a bootcamps y certificados privados, es bastante crítico: suelen aportar estructura y presión de grupo, pero no tienen el mismo peso que un título universitario acreditado y a menudo son caros. Frente a eso, defiende que para mucha gente la mejor combinación es recursos gratuitos de calidad (como freeCodeCamp) + comunidad + mucha disciplina.

En todo momento insiste en un punto clave: seas o no seas “universitario”, necesitas desarrollar habilidades de aprendizaje autodirigido. Vas a pasar la vida leyendo documentación, blogs, issues de GitHub, foros y probando cosas. Si te gusta esa dinámica de ir tirando del hilo por tu cuenta, estás en buen camino.

Capítulo 2: cómo construir tu red de contactos en tecnología

El segundo gran bloque del libro se dedica a algo que en España a veces nos da un poco de alergia: el networking. Quincy desmonta la típica imagen de la feria de empleo con trajes rígidos y tarjetas de visita y lo traduce a un enfoque mucho más humano: conocer gente interesante, ayudarles y dejar buena impresión.

Cuenta cómo, mientras aprendía a programar, empezó a ir a meetups locales, hackathons y eventos de startups en el sur de California. Al principio iba con traje y tarjetas de metal grabadas con láser (cosa que llama la atención, pero también canta un poco a “voy demasiado pasado de vueltas”), y poco a poco fue adaptando su estilo al de la comunidad: ropa informal, conversación natural, humildad técnica.

Un punto que recalca es el valor de los “compañeros de trinchera”: gente que, como tú, está empezando o reconvirtiéndose. Puede que hoy no puedan recomendarte en Google, pero dentro de unos años muchos estarán ya dentro de empresas interesantes y, cuando sus jefes les pregunten “¿a quién más conoces que valga la pena?”, pensarán en quienes han visto currar de cerca en esas primeras etapas.

Para hacer el networking menos caótico, propone crear lo que llama un “tablero de red personal”, por ejemplo con Trello. La idea es listar a todas las personas que conoces (amigos de la infancia, excompañeros de curro, gente que ves en eventos, contactos online…) y clasificarlas en columnas: a quién tiene sentido contactar ahora, a quién más adelante, quién tiene un perfil más técnico, etc.

A partir de ahí, recomienda un enfoque de contacto muy concreto: mensajes cortos, personalizados, que celebren algo de la otra persona (nuevo trabajo, proyecto, logro personal) y, si procede, una oferta genuina de ayuda. Nada de plantillas spam ni de “Hola, ¿me ayudas a encontrar trabajo?” a la primera de cambio.

Capítulo 2 (II): conocer gente nueva y aprovechar la red

Además de reactivar contactos pasados, el libro anima a salir de casa y conocer gente nueva. No solo en eventos puramente técnicos: también en asociaciones locales, deportes, voluntariados, espacios de coworking o incluso en entornos religiosos si formas parte de alguno. Nunca sabes quién puede tener conexión con el mundo tech o necesitar ayuda con un proyecto digital.

Quincy insiste en que la primera toma de contacto debería ser ligera y sin presión: presentarte, recordar el nombre, tener una conversación natural y dejar que sea el tiempo el que consolide el vínculo a través de encuentros repetidos. Solo cuando veas química y contexto, tiene sentido proponer verse en otro evento o intercambiar datos de contacto.

Una técnica que sugiere es convertirse en “conector”: alguien que invita a otros a eventos interesantes, que presenta a dos personas que pueden ayudarse mutuamente, que comparte recursos útiles sin pedir nada a cambio. Eso genera una reputación de persona que aporta valor, y a largo plazo te sitúa como pieza central en varias mini-redes.

Respecto a cuándo explotar esa red para encontrar trabajo, su postura es clara: no tengas prisa por pedir, pero sí constancia en dar. Cuando llegue el momento de buscar oportunidades, será más fácil que alguien piense en ti si lleva meses viéndote ayudar, compartir proyectos o simplemente mostrar interés genuino por su trabajo.

Capítulo 3: cómo construir tu reputación como desarrollador

La tercera pata del libro es la reputación. No basta con saber programar y conocer gente: necesitas pruebas visibles de lo que sabes hacer, algo que reduzca el miedo de los empleadores a contratar a la persona equivocada.

Quincy cuenta que buena parte de su reputación la construyó encadenando hackathons por toda la Costa Oeste de EE. UU. Participaba en casi cualquier evento que encontraba: formaba equipos, proponía ideas, programaba prototipos en un fin de semana y los presentaba ante jurados y otras personas del sector.

Uno de los episodios más ilustrativos es el de un hackathon educativo en Silicon Valley donde su equipo desarrolla una extensión de navegador para generar citas académicas automáticamente. No solo la programan y la demuestran, sino que Quincy se planta en la biblioteca de Stanford el domingo por la mañana y consigue que dos estudiantes paguen por la herramienta antes de presentar el proyecto. Esa prueba de “alguien ha sacado la cartera” da una fuerza enorme a la demo.

A través de estos hackathons fue aprendiendo nuevas tecnologías, mejorando su capacidad de presentar proyectos en público, ganando algún premio aquí y allá y, sobre todo, convirtiéndose en un rostro familiar para muchas personas del ecosistema. Esa visibilidad luego le ayudó a conseguir clientes freelance y, finalmente, su primer empleo como desarrollador.

El libro describe varias vías prácticas para ir creando esa reputación: participar regularmente en hackathons, contribuir a proyectos de código abierto (por ejemplo en GitHub), crear contenido técnico (artículos, vídeos, streams), ir encadenando experiencias laborales en empresas cada vez más conocidas, construir un portafolio de proyectos propios y de clientes y, si llega el momento, incluso lanzar tu propio proyecto, empresa o ONG.

Capítulo 3 (II): enseñar tu trabajo y no arruinar tu nombre

Una herramienta muy concreta que recomienda son las demos en vídeo de tus proyectos. La gente está ocupada y raramente se va a bajar tu código y ejecutarlo. En cambio, un vídeo de dos minutos mostrando tu app en funcionamiento, seguido de una breve explicación de cómo la has construido, puede marcar la diferencia.

Ese vídeo lo puedes subir a YouTube, a tu perfil de GitHub, a tu web personal o incluso a redes sociales como Twitter, donde el autoplay ayuda mucho a que la gente lo vea sin esfuerzo. Lo importante es que se vea claramente el valor de lo que has hecho antes de entrar en detalles técnicos.

La otra cara de la moneda es cómo no cargarte tu reputación. Quincy recomienda evitar discusiones tóxicas en redes sociales, no presumir en exceso de tus habilidades, no prometer plazos irreales (prometer de más y cumplir de menos) y, si tienes adicciones o problemas personales serios, abordarlos antes de meterte de lleno en una búsqueda de empleo intensa.

También anima a ser muy consciente de la separación entre vida profesional y personal: no usar tu posición como desarrollador para aprovecharte de otras personas, no mezclar trabajo y ligoteo de formas turbias, y recordar siempre que tu conducta pública deja rastro en internet y puede reaparecer años después cuando menos te lo esperas.

Como truco para ir afinando tu comportamiento, propone el llamado “truco del narrador”: imaginar que una voz en off está narrando lo que haces como si fueras el protagonista de una historia. Eso te obliga a mirar tus decisiones con cierta distancia y preguntarte: “¿de verdad quiero que esta sea la forma en la que me recuerden?”.

Con esa mezcla de proyectos visibles, buenas prácticas y autocrítica, el objetivo es que, con el tiempo, tu nombre empiece a asociarse a alguien fiable, competente y agradable de tener en un equipo. Y eso, en el mundillo del desarrollo, abre muchísimas puertas.

Capítulo 4: cómo empezar a cobrar por programar

El cuarto capítulo entra ya en la parte más delicada: cómo pasar de aprender por tu cuenta a ganar dinero programando, ya sea como freelance o en un trabajo por cuenta ajena. Aquí freeCodeCamp y el libro encajan especialmente bien para quien quiere vivir de esto, no solo programar por hobby.

Quincy explica, con bastante realismo, que el proceso de selección para trabajos de desarrollador suele ser duro: montones de formularios, currículums que nadie lee, pruebas técnicas, entrevistas en varias rondas y largos silencios. Los empleadores son muy conservadores porque contratar mal a un desarrollador es carísimo en tiempo y dinero.

Por eso insiste tanto en que desarrolles tus habilidades, red y reputación a la vez. Si has estado construyendo proyectos, enseñándolos, ayudando a gente y creándote un nombre, es mucho más probable que te lleguen oportunidades por la “puerta lateral”: un contacto que te recomienda, un reclutador que ha oído hablar de ti, un excompañero de hackathon que te escribe porque en su empresa necesitan a alguien con tu perfil.

Mientras tanto, recomienda una vía muy práctica para empezar a monetizar antes de conseguir un contrato fijo: el trabajo freelance. Conseguir un pequeño cliente local para hacerle la web, una automatización o un sistema de reservas es, a menudo, mucho más fácil que entrar de golpe en una empresa grande. Y te sirve para aprender con problemas reales, tratar con clientes, presupuestar y entregar.

En cuanto a tarifas, propone un enfoque sencillo: calcular tu tarifa por hora en tu trabajo actual y duplicarla para freelance, o bien fijar precios por proyecto con una definición clara del alcance. Siempre, eso sí, con contrato por delante y cobrando al menos la mitad por adelantado, para minimizar riesgos de impagos.

Finalmente, entra en el tema de reclutadores y negociación salarial. Defiende que los buenos reclutadores pueden ser grandes aliados (sus incentivos están alineados con que consigas un buen salario) y que, salvo situaciones muy concretas, siempre merece la pena intentar negociar tu oferta, aunque sea un poco. La clave está en tener algo de palanca: otras ofertas, ahorro suficiente para no aceptar lo primero que pase, etc.

Capítulo 5: sobrevivir (y crecer) en tu primer trabajo como dev

El último capítulo se centra en lo que pasa cuando por fin consigues ese primer trabajo como desarrollador. Y aquí no hay azúcar: el primer año puede ser muy duro. De repente te ves dentro de una base de código enorme, con un stack complejo, herramientas de CI/CD, tickets, plazos, reuniones… y rodeado de gente que, aparentemente, controla muchísimo más que tú.

Quincy narra su propia experiencia entrando en una startup de unas 50 personas: una app grande en Ruby on Rails, millones de líneas (incluyendo dependencias), pruebas automatizadas por todas partes y un ritmo al que al principio era incapaz de seguir. Sentía que siempre iba por detrás, que tardaba demasiado en resolver errores, que molestaba a sus compañeros con demasiadas preguntas… y vivía con el miedo constante a que le echaran.

Con el tiempo fue ajustando: aprender a preguntar cuando tocaba sin abusar, entender que algunos bugs llevan días o semanas resolverse incluso para gente muy veterana, aceptar que romper la build es parte del proceso (aunque haga rabiar a todos) y que la única forma de mejorar es seguir leyendo código, escribiendo código y revisando código.

Una de las grandes barreras es el síndrome del impostor, que aquí se dispara. Sientes que todos saben más, que tú estás ahí por error y que en cualquier momento se va a notar. El libro propone, de nuevo, normalizar la sensación (hasta seniors con diez años de experiencia la tienen de vez en cuando) y usarla como recordatorio de que eres un aprendiz permanente, no como evidencia de que “no vales para esto”.

Otro consejo importante es dejar el ego en la puerta. Da igual que antes fueras jefe, que tengas otro título universitario o que hayas dirigido equipos en otro sector: en desarrollo empiezas como junior y tienes que permitirte ser novato. Eso no significa aguantar faltas de respeto, pero sí asumir que vas a equivocarte mucho y que, a menudo, otros sabrán más que tú sobre la base de código o el stack que se usa.

Por último, recomienda evitar encasillarte demasiado pronto. Es tentador convertirse en “la persona que lleva tal módulo” y no salir de ahí, pero a medio plazo te interesa exponerte a distintas partes del sistema, aprender nuevas herramientas y lenguajes y mantener una mentalidad de generalista que luego puedas afinar según lo que te guste y te abra más puertas.

Mirado en conjunto, todo lo que plantea el libro de Quincy Larson encaja muy bien con la filosofía de freeCodeCamp: recursos gratuitos, aprendizaje basado en proyectos, comunidad, foco en tecnologías sólidas y un objetivo final muy concreto: que puedas vivir de programar. Si combinas el currículo de freeCodeCamp (ahora también en español) con las ideas de este libro, algo de trabajo freelance, participación en comunidades y mucha constancia, es bastante razonable pensar que en unos años estarás contando tu propia historia de cómo pasaste de “no saber ni abrir un editor de código” a tener tu primer empleo como desarrollador.