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.