Puedes entender una función cuando la ves en clase y quedarte completamente en blanco al abrir un proyecto vacío. A mí me ha pasado muchas veces.
En un ejercicio ya sabes qué toca practicar. Si la clase va de arrays, seguramente la solución necesita un array. En un proyecto propio nadie te da esa pista. Primero tienes que decidir qué quieres construir, cómo dividirlo y qué parte de JavaScript necesitas para conseguirlo.
Ese salto fue lo que más me ayudó a aprender. No dejé de estudiar teoría ni de hacer ejercicios, pero empecé a utilizar JavaScript en proyectos que quería usar de verdad. Ahí fue cuando los conceptos dejaron de estar aislados.
Hacer ejercicios no es lo mismo que construir
Los ejercicios tienen una función clara. Sirven para practicar una parte concreta del lenguaje sin cargar con todo lo demás. El problema llega cuando te acostumbras a recibir siempre el enunciado, los datos y el resultado esperado.
Después abres un repositorio nuevo y aparecen preguntas que no son de sintaxis:
- Qué debería incluir la primera versión.
- Cómo organizar los datos.
- Qué ocurre si el usuario hace algo que no esperabas.
- Qué merece la pena guardar.
- Cuándo una función está terminada.
- Qué puedes dejar para más adelante.
Es normal sentirse peor programador en ese momento. Un proyecto deja al descubierto todo lo que un ejercicio decide por ti.
Para mí, aprender JavaScript empezó a ser mucho más útil cuando dejé de medir el progreso por el número de clases terminadas y empecé a medirlo por los problemas que ya era capaz de resolver.
Apuntes ICO empezó siendo otra cosa
Apuntes ICO no nació como una aplicación de apuntes. La primera versión era una web para enseñar los ejercicios que hacía durante mi formación en comunicación.
Mientras avanzaba con las clases me di cuenta de que tenía otro problema. Había lecciones grabadas, directos semanales y contenido de distintos mentores, pero no tenía un sitio donde consultarlo todo de una forma que me resultara cómoda.
Decidí cambiar el proyecto entero.
Pasó de ser una web para mostrar ejercicios a una aplicación que organizaba las cuatro fases del programa, catorce semanas de contenido y las clases de los mentores. Además, tenía que poder consultarla desde el móvil e incluso sin conexión.
Ese cambio me obligó a pensar antes de escribir código. La dificultad no era hacer aparecer un texto al pulsar un botón. Era conseguir que una cantidad grande de información tuviera sentido dentro de la web.
Tuve que decidir cómo separar fases, semanas y profesores; cómo moverme entre secciones sin perderme; y cómo hacer que páginas largas siguieran siendo legibles en una pantalla pequeña. JavaScript formaba parte de la solución, pero el aprendizaje importante estaba en conectar la interfaz, el contenido y el comportamiento.
También lo compaginaba con las propias clases de ICO, las clases de inglés y el máster de desarrollo. No construí la aplicación en una tarde siguiendo un tutorial. El contenido y el proyecto fueron creciendo a la vez.
Cuando estuvo lista, la compartí con la comunidad de ICO. Dejó de ser algo que solo funcionaba en mi ordenador. Otras personas iban a navegar por ella, instalarla y utilizarla para consultar la formación. Eso hizo que errores que antes podían parecer pequeños empezaran a importar de verdad.
Para que un proyecto sea real no hace falta cobrar
Durante bastante tiempo asociaba un proyecto real con un cliente. Ahora lo veo de otra manera.
Un proyecto es real cuando resuelve una necesidad concreta y alguien depende del resultado. Puede ser un cliente, un compañero o tú mismo. Si la herramienta no es cómoda y dejas de usarla, has recibido feedback real aunque no haya una factura de por medio.
Eso ocurrió también con EmoWords. La idea vino de algo que repetía mi profesora de inglés: una palabra se recuerda mejor si la conectas con una experiencia o una emoción propia.
Quise convertir esa idea en una app. Al hacerlo aparecieron problemas que nunca habría elegido en una lista de ejercicios: guardar vocabulario en el navegador, reproducir pronunciaciones, organizar diferentes formas de repaso, calcular progreso y mantener una racha.
No dominaba JavaScript cuando empecé EmoWords. Utilicé IA como apoyo y tuve que investigar bastante. La diferencia es que yo conocía el problema y sabía cómo quería que se comportara la aplicación. Podía probar cada parte y detectar cuándo una solución técnicamente válida no encajaba con el producto.
Cómo encontrar una idea que te sirva para aprender
Buscar ideas en listas de 100 proyectos puede servir para arrancar, pero muchas terminan siendo la misma calculadora, lista de tareas o aplicación del tiempo. No hay nada malo en hacerlas. El problema es que, si la aplicación te da igual, es fácil abandonarla en cuanto deja de ser divertida.
Yo empezaría buscando fricciones pequeñas:
- Una información que consultas a menudo y nunca encuentras rápido.
- Algo que organizas manualmente en notas o en una hoja de cálculo.
- Una tarea repetitiva que podrías simplificar.
- Una herramienta que utilizas, pero que no funciona como te gustaría.
- Una idea que has escuchado y que podría convertirse en una utilidad.
No necesitas inventar una startup. Apuntes ICO empezó porque yo quería consultar mejor una formación que ya estaba haciendo. EmoWords empezó con una frase de mi profesora de inglés.
La necesidad te da algo que una lista genérica no puede darte: criterio para decidir. Sabes qué funciones aportan valor porque tú conoces el problema.
La primera versión tiene que ser pequeña
Una vez tienes la idea, el siguiente peligro es intentar construirla completa desde el primer día.
Si hubiera pensado en Apuntes ICO como cuatro fases, catorce semanas, todos los mentores, una PWA y funcionamiento offline desde el primer momento, probablemente no habría empezado. La primera versión solo necesitaba demostrar que podía organizar una parte del contenido y navegar por ella con comodidad.
Para reducir el alcance de un proyecto me sirven estas tres preguntas:
- ¿Qué acción principal debe poder completar alguien?
- ¿Qué es imprescindible para que esa acción funcione?
- ¿Qué puedo añadir después sin rehacer la base?
Esto no es solo gestión de proyectos. También mejora el aprendizaje. Si intentas resolver navegación, persistencia, autenticación, sincronización, animaciones y responsive a la vez, no sabes qué parte te está bloqueando.
Una versión pequeña te permite cerrar un ciclo: construir, probar, detectar un problema y corregirlo.
El proyecto debería estar un poco por encima de tu nivel
Si ya sabes hacer todas las partes, practicarás velocidad, pero aprenderás pocos conceptos nuevos. Si no entiendes absolutamente nada del stack, acabarás pegando piezas sin saber dónde se rompen.
Intento que mis proyectos mezclen tres cosas:
- Una base que ya controlo.
- Algo que he estudiado, pero todavía necesito practicar.
- Un problema nuevo que me obliga a investigar.
En Apuntes ICO ya podía construir la estructura visual. El reto estaba en organizar una aplicación mucho más grande, añadir comportamiento y conseguir que pudiera instalarse y funcionar sin conexión.
En EmoWords tenía clara la experiencia que quería crear, pero todavía estaba aprendiendo JavaScript. Eso hizo el proceso más difícil, aunque también me obligó a entender para qué servía cada parte.
Usar IA no debería convertirte en espectador
He usado IA para programar. Ocultarlo haría que el artículo sonara más limpio, pero sería menos real.
El problema no es pedir ayuda. También utilizamos documentación, Stack Overflow, vídeos y código de otros proyectos. El problema aparece cuando aceptas una implementación completa y no puedes explicar qué entra, qué cambia y qué devuelve.
Cuando uso IA intento no entregarle todas las decisiones. Prefiero pedir una pieza concreta, integrarla en mi código y romperla a propósito para comprobar que entiendo sus límites.
Algunas preguntas que me hago antes de dar una solución por buena son:
- ¿Puedo explicar este código sin leer la respuesta original?
- ¿Sé qué datos modifica?
- ¿Qué ocurre si la entrada está vacía o tiene otro formato?
- ¿Estoy usando esta solución porque encaja o porque ha sido la primera que funciona?
- ¿Podría localizar el error si mañana deja de funcionar?
No siempre puedo responder que sí a todo. En ese caso, esa parte sigue siendo una deuda de aprendizaje. El proyecto puede avanzar, pero no debería engañarme pensando que ya domino el concepto.
Publicar te enseña una parte que el localhost no puede
Mientras una aplicación vive solo en tu ordenador, tú completas mentalmente todo lo que falta. Sabes dónde pulsar, qué datos introducir y qué errores evitar.
Cuando la compartes, desaparece esa ventaja.
Con Apuntes ICO tuve que pensar en personas que no conocían la estructura como yo. También tuve que ser cuidadoso porque la formación era privada: podía compartir la herramienta con la comunidad, pero no exponer públicamente su contenido.
Publicar un proyecto te obliga a revisar cosas distintas al código:
- Si se entiende para qué sirve.
- Si la navegación es clara.
- Si funciona fuera de tu dispositivo.
- Si estás mostrando información que no deberías.
- Si puedes explicar qué hiciste y por qué.
Además, convierte el aprendizaje en una prueba. Decir que sabes JavaScript aporta poco. Enseñar una aplicación, contar los problemas que encontraste y reconocer qué partes mejorarías permite evaluar mucho mejor tu nivel.
El proceso que me funciona
No tengo un método perfecto, pero este patrón se ha repetido en varios proyectos:
- Detecto algo que me molesta o que echo en falta.
- Defino una primera versión que pueda terminar.
- La construyo con una base que ya conozco.
- Investigo cuando aparece un problema real.
- Uso la herramienta y compruebo si resuelve la necesidad.
- Añado funciones cuando la base ya funciona.
- La comparto y observo qué falla fuera de mi entorno.
- Documento las decisiones y lo que haría de otra forma.
Sigo necesitando teoría, ejercicios y documentación. La diferencia es que ahora suelo llegar a ellos con una pregunta concreta.
Aprender JavaScript con proyectos reales no consiste en evitar los fundamentos ni en intentar construir el próximo producto millonario. Consiste en dejar de estudiar cada concepto como una pieza aislada y darle un problema al que responder.
Si no sabes qué construir, no empieces por la tecnología. Revisa qué herramienta echas de menos, qué proceso te resulta incómodo o qué información nunca consigues consultar bien. Ahí puede estar tu siguiente proyecto y, probablemente, la siguiente parte de JavaScript que necesitas aprender.
You can understand a function during a lesson and still stare at an empty repo with no idea what to write. I’ve been there plenty of times.
An exercise tells you what you’re meant to practise. If the lesson is about arrays, the solution probably needs an array. Your own project gives you no such hint. You have to decide what you’re building, how to break it down and which part of JavaScript can get you there.
That jump made the biggest difference to the way I learn. I didn’t stop studying the fundamentals or doing exercises. I started using JavaScript in projects I genuinely wanted to use, and the concepts stopped feeling like separate pieces.
Completing exercises isn’t the same as building
Exercises have a clear purpose. They let you focus on one part of the language without carrying the rest of an application on your back. The trouble starts when you get used to always receiving the brief, the input data and the expected output.
Open a fresh repo and a different set of questions appears:
- What belongs in the first version?
- How should the data be structured?
- What happens when someone does something I didn’t expect?
- What needs to be persisted?
- When is a feature actually done?
- What can wait until later?
Feeling like a worse developer at that point is normal. A real project exposes every decision an exercise usually makes for you.
JavaScript became far more useful to me when I stopped measuring progress by the number of completed lessons and started looking at the problems I could now solve.
ICO Notes started as a completely different project
ICO Notes wasn’t originally a notes app. The first version was a website for displaying exercises from my communication course.
As the course progressed, I found a different problem. There were recorded lessons, weekly live sessions and content from several mentors, but I had nowhere I could browse all of it in a way that worked for me.
So I changed the entire project.
It went from an exercise showcase to an app that organised four programme phases, fourteen weeks of content and each mentor’s lessons. I also wanted to use it from my phone and access it offline.
That change forced me to think before writing code. The hard part wasn’t showing some text after a click. It was making a large amount of information make sense inside a website.
I had to decide how phases, weeks and mentors fitted together, how to move between sections without getting lost and how to keep long pages readable on a small screen. JavaScript was part of the solution, but the useful learning came from connecting the interface, content and behaviour.
I was building it alongside the ICO course itself, my English lessons and my web development master’s. It wasn’t a one-afternoon tutorial build. The content and the app grew together.
Once it was ready, I shared it with the ICO community. It no longer had to work only on my laptop. Other people were going to browse it, install it and use it as a reference. Small bugs suddenly mattered.
A real project doesn’t need to make money
I used to associate real projects with client work. I don’t anymore.
A project is real when it solves a specific need and somebody depends on the outcome. That might be a client, a classmate or you. If the tool is awkward and you stop using it, that’s real feedback even if nobody sent an invoice.
The same thing happened with EmoWords. The idea came from something my English teacher often said: you remember a word more easily when you connect it to one of your own experiences or emotions.
I wanted to turn that idea into an app. That brought up problems I would never have picked from an exercise sheet: storing vocabulary in the browser, playing pronunciation audio, organising several review modes, calculating progress and maintaining a streak.
I wasn’t confident with JavaScript when I started EmoWords. I used AI for support and had to research a lot. The important difference was that I understood the problem and knew how I wanted the app to behave. I could test each part and spot when a technically valid answer didn’t fit the product.
Finding an idea that will actually help you learn
Lists of 100 project ideas can get you moving, but many of them repeat the same calculator, to-do list and weather app. There’s nothing wrong with building those. The issue is that if you don’t care about the app, dropping it becomes very easy as soon as the fun part ends.
I’d start with small bits of friction instead:
- Information you check often but can never find quickly.
- Something you manage manually in notes or a spreadsheet.
- A repetitive task you could simplify.
- A tool you use that doesn’t quite work the way you want.
- An idea you’ve heard that could become something useful.
You don’t need a startup pitch. ICO Notes started because I wanted a better way to browse a course I was already taking. EmoWords started with one sentence from a teacher.
A real need gives you something a generic list can’t: a way to judge your own decisions. You know which features matter because you understand the problem.
Keep the first version small
Once you have the idea, the next trap is trying to build the finished product on day one.
If I’d thought of ICO Notes as four phases, fourteen weeks, every mentor, a PWA and full offline support from the start, I probably wouldn’t have begun. The first version only needed to prove that I could organise part of the content and move through it comfortably.
These three questions help me cut down the scope:
- What’s the one thing somebody needs to be able to do?
- What’s essential for that action to work?
- What can I add later without rebuilding the foundation?
This isn’t only project management. It makes learning easier too. If you’re tackling navigation, persistence, authentication, sync, animation and responsive design at once, you won’t know which problem is actually blocking you.
A small version lets you close the loop: build, test, find a problem and fix it.
Work slightly above your current level
If you already know every part, you’ll practise speed but learn little that’s new. If the entire stack is unfamiliar, you’ll probably end up gluing snippets together without knowing where they break.
I try to mix three things in a project:
- A foundation I already understand.
- Something I’ve studied but still need to practise.
- One new problem that forces me to research.
With ICO Notes, I could already build the visual structure. The challenge was organising a much larger app, adding behaviour and making it installable and available offline.
With EmoWords, I knew the experience I wanted, but I was still learning JavaScript. That made the build harder, but it also forced me to work out what each part was there for.
AI shouldn’t turn you into a spectator
I’ve used AI to write code. Hiding that would make the story cleaner, but less honest.
Asking for help isn’t the problem. We also use docs, Stack Overflow, videos and code from other projects. The problem is handing over the decisions as well, then accepting an implementation you can’t explain.
When I use AI, I try not to give it the entire problem. I’d rather ask for one specific piece, fit it into my code and deliberately break it to check whether I understand its limits.
Before I accept an answer, I try to ask myself:
- Could I explain this code without reopening the original response?
- Do I know which data it changes?
- What happens with an empty or unexpected input?
- Does this approach fit my project, or was it just the first one that worked?
- Could I debug it if it stopped working tomorrow?
I can’t always answer yes to everything. When I can’t, that part is still learning debt. The project may move forward, but I shouldn’t pretend I now understand the concept properly.
Shipping teaches you what localhost can’t
While an app lives only on your machine, you fill in the missing pieces without noticing. You know where to click, what data to enter and which paths to avoid.
Once you share it, that advantage disappears.
With ICO Notes, I had to think about people who didn’t know the structure as well as I did. I also had to be careful because the course content was private. I could share the tool with the community, but I couldn’t expose the material publicly.
Shipping makes you review more than the code:
- Whether people understand what the app is for.
- Whether the navigation makes sense.
- Whether it works away from your own device.
- Whether you’re exposing anything you shouldn’t.
- Whether you can explain what you built and why.
It also turns learning into evidence. Saying you know JavaScript doesn’t reveal much. Showing an app, walking through the problems you hit and admitting what you’d improve gives a much clearer picture of your level.
The process that works for me
I don’t have a perfect framework, but this pattern has repeated across several projects:
- I notice something that’s annoying or missing.
- I define a first version I can realistically finish.
- I build it on top of something I already know.
- I research when I hit a real problem.
- I use the tool and check whether it solves the original need.
- I add features once the foundation works.
- I share it and see what breaks outside my own setup.
- I document the decisions and what I’d do differently now.
I still need theory, exercises and documentation. The difference is that I now tend to arrive with a specific question.
Learning JavaScript through real projects isn’t about skipping the fundamentals or trying to build the next billion-dollar product. It’s about giving each concept a problem to answer instead of studying it as an isolated piece.
If you don’t know what to build, don’t start with the technology. Look at the tool you wish you had, the process that annoys you or the information you can never browse properly. Your next project might be there, along with the next part of JavaScript you need to learn.