El Proyecto | Sobre nosotros | Contribuir | Donaciones | Licencia

HOME

Empezaste este curso escribiendo console.log('Hola, Taller Nómada'); sin saber muy bien qué era una variable. Terminas con un producto propio planificado, construido por capas, persistido con migraciones, probado en tres niveles, desplegado con HTTPS y despliegue continuo, documentado con ADR y defendible en una entrevista. Entre esas dos frases hay once módulos y bastantes horas tuyas. Esta última lección no enseña una técnica nueva: hace tres cosas distintas y necesarias. Primero, un balance honesto de qué sabes ahora —competencia a competencia, módulo a módulo— y, con la misma honestidad, qué no cubre este curso, porque conocer los propios huecos es tan valioso como conocer las propias capacidades. Segundo, el mapa de lo que viene: TypeScript, Node.js y el backend, dominar un framework de verdad, las herramientas y la plataforma, profundizar en la web y elegir una especialización — cada camino con qué es, por qué importa, cómo empezar y cuánto tiempo pide, sin exageraciones. Y tercero, lo más importante y lo que menos se enseña: cómo se sigue aprendiendo cuando ya no hay un curso que te diga qué toca, cómo mantenerse al día sin agotarse, y qué hacer con todo esto en términos de carrera, con honestidad sobre cómo está el mercado. Terminarás con una hoja de ruta de seis meses adaptada a tu disponibilidad real. Es la última lección: no enlaza con nada posterior, porque lo que viene después ya lo decides tú.

Contenido

El balance: qué sabes ahora
Lo que este curso no cubre
El mapa de los caminos
TypeScript: el tipado estático
Node.js y el backend
Un framework en profundidad
Herramientas y plataforma
Profundizar en la plataforma web
Las especializaciones
Cómo se sigue aprendiendo cuando ya no hay curso
Leer código ajeno y contribuir
Cómo mantenerse al día sin agotarse
Por qué las bases no caducan
La hoja de ruta de seis meses
Carrera: portafolio, currículum y entrevistas
El primer empleo y aprender en el trabajo
Errores Comunes y Consejos
Ejercicios
Conclusión

El balance: qué sabes ahora

Es fácil terminar un curso largo con la sensación de que «no sabes tanto». Es una impresión casi universal y casi siempre falsa: la causa es que has ido subiendo el listón de lo que consideras «saber» al mismo ritmo que aprendías.

Esta tabla es el inventario real. No es de temario: es de competencias, escritas como cosas que puedes hacer.

Módulo	Lo que puedes hacer ahora
M1 · Introducción	Montar un entorno de desarrollo, entender qué hace un motor de JavaScript, declarar y usar variables con criterio, elegir el tipo adecuado, y leer un mensaje de error sin bloquearte
M2 · Control de flujo	Expresar reglas de negocio con condicionales legibles, recorrer datos con el bucle adecuado, y manejar errores con `try/catch` distinguiendo lo esperado de lo excepcional
M3 · Funciones	Descomponer un problema en funciones con una responsabilidad, usar closures para encapsular estado, escribir funciones de orden superior, y resolver estructuras recursivas
M4 · Objetos y arrays	Modelar entidades, transformar colecciones con `map`, `filter` y `reduce`, desestructurar, copiar sin efectos colaterales y serializar a JSON
M5 · Avanzado	Diseñar clases con encapsulación real, organizar el código en módulos, dominar la asincronía con promesas y `async/await`, y explicar el bucle de eventos y las microtareas
M6 · DOM	Construir interfaces sin framework: selección, creación, eventos, delegación, renderizado de listas y formularios accesibles con validación
M7 · APIs del navegador	Persistir datos, hablar con una API con `fetch` robusto, usar WebSockets, convertir una web en PWA con service worker, y conocer las APIs esenciales
M8 · Pruebas	Depurar con método, mantener la calidad con ESLint y Prettier, escribir pruebas unitarias, de integración y de extremo a extremo, y usar dobles de prueba
M9 · Rendimiento	Medir antes de optimizar, fijar un presupuesto, optimizar código, gestionar memoria, manipular el DOM eficientemente y dividir la carga
M10 · Frameworks	Entender por qué existen, conocer React, Redux, Vue y Angular a nivel funcional, y elegir con criterio en lugar de por moda
M11 · Proyecto	Planificar un producto, construirlo por capas, persistir y sincronizar datos, montar una estrategia de pruebas y CI, desplegar con seguridad, y presentarlo y defenderlo

Y las competencias transversales, que son las que más valen y las que ningún temario lista:

Competencia	Dónde la adquiriste
Convertir un problema en un modelo de datos y unas reglas	01-08, 11-01
Decidir con criterio y poder defender la decisión	10-06, 11-01, 11-06
Medir antes de opinar	Todo el M9, 11-04
Depurar con método en lugar de a tientas	08-01, 11-02, 11-04
Escribir código que otra persona pueda mantener	M8, 11-02, 11-06
Terminar cosas	Todo el M11

Esa última fila es, sin ninguna exageración, la que más te va a diferenciar. Muchísima gente empieza proyectos; muy poca los lleva desde el plan hasta el despliegue documentado.

Una forma de comprobarlo tú mismo: vuelve a leer el código que escribiste en el Módulo 1 y en el 2. Si te parece mejorable —y te lo va a parecer— es la prueba objetiva de que has avanzado. La incomodidad al mirar el propio código antiguo es la señal más fiable de progreso que existe en esta profesión, y no desaparece nunca: dentro de dos años sentirás lo mismo con lo que escribes hoy.

Lo que este curso no cubre

Igual de importante, y bastante más raro de encontrar escrito.

Área	Qué no se ha visto	Cuánto importa
Tipado estático	TypeScript: tipos, genéricos, inferencia	Mucho en equipos y en el mercado laboral
Backend	Node.js como servidor, APIs REST, bases de datos, autenticación	Mucho si quieres full-stack o entender el sistema completo
Un framework en serio	Solo se vieron los fundamentos de cuatro; ninguno en profundidad	Mucho para la mayoría de ofertas
CSS moderno	Grid, contenedores, sistemas de diseño, animaciones	Bastante: se ha usado, no enseñado
Bases de datos	Modelado relacional, SQL, índices, transacciones	Mucho en backend
Algoritmos y estructuras	Complejidad, grafos, árboles balanceados, dinámica	Medio: importa en algunas entrevistas
Seguridad web en profundidad	OWASP, CSRF, sesiones, criptografía aplicada	Mucho en producción real
Arquitectura a escala	Micro-frontends, monorepos, sistemas de diseño	Medio: llega con el tamaño del equipo
DevOps	Docker, Kubernetes, infraestructura como código, la nube	Medio-alto según el puesto
Móvil	React Native, Capacitor, aplicaciones nativas	Depende de tu objetivo
Trabajo en equipo real	Revisiones cruzadas, metodologías, gestión de producto	Mucho, y solo se aprende trabajando

Esa última fila merece una nota honesta: hay cosas que no se aprenden en ningún curso. Trabajar con código que escribió otra persona hace cuatro años, negociar un alcance con quien no es técnico, mantener un sistema del que nadie recuerda nada, o revisar el código de un compañero sin romper la relación. Se aprenden trabajando, y no pasa nada por no saberlas todavía. Lo que sí ayuda es saber que existen y no confundir «no las domino» con «no valgo».

Y una advertencia sobre la lista. Verla completa produce cierto vértigo. No hay que aprenderlo todo, y desde luego no a la vez. La sección siguiente ordena esto en caminos, y la 14 lo convierte en un plan de seis meses con una dirección principal.

El mapa de los caminos

flowchart TD
    A["Sabes JavaScript<br/>y has terminado un producto"] --> B["TypeScript<br/><i>1-2 meses</i>"]
    A --> C["Un framework<br/>en profundidad<br/><i>2-3 meses</i>"]
    A --> D["Node.js<br/>y backend<br/><i>3-4 meses</i>"]

    B --> E["Front-end<br/>de producto"]
    C --> E
    C --> F["Especialista<br/>front-end"]
    D --> G["Full-stack"]
    B --> G

    A --> H["Plataforma web<br/>a fondo<br/><i>continuo</i>"]
    H --> I["Accesibilidad<br/>Rendimiento<br/>Seguridad"]

    A --> J["Herramientas<br/>y plataforma<br/><i>transversal</i>"]
    J --> G
    J --> K["Tooling / DevEx"]

    style A fill:#dcfce7,stroke:#16a34a
    style B fill:#dbeafe,stroke:#2563eb
    style C fill:#dbeafe,stroke:#2563eb
    style D fill:#dbeafe,stroke:#2563eb

Los tres caminos azules son los principales, y el orden recomendado es este:

TypeScript primero, porque es el más barato (empiezas hoy, sobre tu propio proyecto) y porque multiplica el valor de todo lo demás.
Un framework en profundidad después, porque es lo que más aparece en las ofertas y porque ya tienes el criterio de 10-06 para elegir cuál.
Node.js cuando quieras entender el sistema completo, o si te atrae el backend.

Los caminos grises —plataforma web y herramientas— no son alternativas: son continuos. Se avanza en ellos siempre, en paralelo, un poco cada mes.

Y la regla que gobierna todo el mapa, que conviene escribir en algún sitio visible:

Elige una dirección principal para los próximos seis meses. Una. Las demás seguirán ahí.

El error más común al terminar un curso es empezar cuatro cosas a la vez, tener tres meses de sensación de avance, y no dominar ninguna. Uno a la vez, con profundidad, es más rápido aunque no lo parezca.

TypeScript: el tipado estático

4.1 Qué es y por qué importa

TypeScript es JavaScript con tipos comprobados antes de ejecutar. Se escribe casi igual, se compila a JavaScript, y el navegador nunca lo ve.

Lo que cambia no es la sintaxis: es cuándo descubres los errores.

// Sin tipos: esto falla en producción, un martes, en el móvil de alguien
function horasDe(tarea) {
  return tarea.horasEstimadas.toFixed(1);   // 💥 si horasEstimadas es undefined
}

// Con tipos: falla al escribirlo, en tu editor, subrayado en rojo
interface Tarea {
  id: number;
  titulo: string;
  horasEstimadas: number;
  responsableId: string | null;
}

function horasDe(tarea: Tarea): string {
  return tarea.horasEstimadas.toFixed(1);   // ✅ el compilador garantiza que existe
}

Por qué cambia el trabajo en equipo, que es su valor principal y el menos evidente:

Sin tipos	Con tipos
Para saber qué devuelve una función, la lees	La firma lo dice, y el editor te lo muestra
Al cambiar un campo, buscas usos con `grep` y confías	El compilador te enumera todos los sitios que hay que tocar
La documentación se desactualiza	Los tipos no pueden desactualizarse: no compilan
Refactorizar da miedo	Renombrar es una operación segura del editor
«¿Esto puede ser `null`?»	La respuesta está escrita

Ese segundo punto es el que más se nota en un proyecto real. Cambiar responsable: string por responsableId: string | null en tu proyecto significó revisar a mano todos los sitios afectados; con TypeScript, el compilador te da la lista completa y no se le escapa ninguno.

4.2 La puerta de entrada barata: `// @ts-check` y JSDoc

No hace falta migrar nada para empezar. TypeScript puede comprobar tu JavaScript actual usando comentarios JSDoc, que ya conoces de 08-02.

// @ts-check
/**
 * Calcula las horas abiertas de una lista de tareas.
 * @param {Array<{estado: string, horasEstimadas: number}>} tareas
 * @param {string} [responsableId] - Si se indica, filtra por responsable
 * @returns {number} Horas de las tareas no terminadas
 */
export function horasAbiertas(tareas, responsableId) {
  return tareas
    .filter((t) => t.estado !== 'hecha')
    .filter((t) => !responsableId || t.responsableId === responsableId)  // ⚠️ error
    .reduce((suma, t) => suma + t.horasEstimadas, 0);
}

Con esa única línea // @ts-check al principio del fichero, tu editor ya te subraya que t.responsableId no existe en el tipo declarado. Cero configuración, cero compilación, cero cambios en el código que se ejecuta.

El siguiente paso es un jsconfig.json que lo active para todo el proyecto:

{
  "compilerOptions": {
    "checkJs": true,
    "strict": true,
    "target": "ES2022",
    "module": "ESNext",
    "moduleResolution": "bundler",
    "noEmit": true
  },
  "include": ["src/**/*.js"]
}

Este es el camino que recomiendo, y no es el habitual: aprender TypeScript sobre tu propio proyecto, tipando el dominio primero, con JSDoc y sin compilación. Es gradual, reversible y aplicado a un código que conoces.

4.3 La migración gradual

Cuando quieras dar el salto a .ts de verdad:

Paso	Qué haces	Duración
1	`// @ts-check` + JSDoc en `dominio/`	1 semana
2	`jsconfig.json` con `checkJs` en todo el proyecto	1 día
3	Instalar TypeScript; renombrar `dominio/*.js` a `.ts`	1 semana
4	`datos/` y `aplicacion/`	1–2 semanas
5	`vista/` (la que más `any` tolerará al principio)	1–2 semanas
6	Activar `strict` completo y eliminar los `any`	Continuo

Empieza siempre por el dominio. Es donde los tipos aportan más (las entidades y las reglas), donde el código es más estable, y donde no hay any inevitables del DOM.

4.4 Un ejemplo de tu propio modelo tipado

// src/dominio/tipos.ts
export type Estado = 'pendiente' | 'en-curso' | 'hecha';
export type Prioridad = 'alta' | 'media' | 'baja';
export type Rol = 'coordinacion' | 'equipo' | 'invitado';

export interface Usuario {
  readonly id: string;
  nombre: string;
  iniciales: string;
  rol: Rol;
  activo: boolean;
}

export interface Tarea {
  readonly id: number;
  titulo: string;
  responsableId: string | null;
  revisorId: string | null;
  prioridad: Prioridad;
  readonly estado: Estado;          // solo cambia por cambiarEstado()
  etiquetas: readonly string[];
  horasEstimadas: number;
  fechaLimite: string | null;
  tareaMadreId: number | null;
  readonly creadaEn: string;
}

// R6: la matriz de transiciones, comprobada por el compilador
export const TRANSICIONES: Record<Estado, readonly Estado[]> = {
  'pendiente': ['en-curso'],
  'en-curso': ['hecha', 'pendiente'],
  'hecha': ['en-curso']
} as const;

export interface Repositorio {
  listarTareas(): Promise<Tarea[]>;
  guardarTarea(tarea: Tarea): Promise<Tarea>;
  borrarTarea(id: number): Promise<void>;
  listarUsuarios(): Promise<Usuario[]>;
}

Fíjate en cuatro cosas que ese fichero consigue gratis:

Estado y Prioridad como uniones de literales hacen imposible escribir 'terminada' por error. Es la R6 y las validaciones de conjunto cerrado, comprobadas por el compilador en lugar de en ejecución.
readonly documenta y hace cumplir qué campos no se tocan directamente. Es la encapsulación de 05-03 expresada en el tipo.
Record<Estado, readonly Estado[]> garantiza que la matriz de transiciones cubre todos los estados. Si mañana añades 'archivada', no compila hasta que definas sus transiciones. Eso es una regla de negocio verificada por el compilador.
interface Repositorio es tu contrato de 11-02, ahora comprobado: si una implementación olvida un método o cambia una firma, no compila. La prueba de contrato sigue siendo necesaria para el comportamiento, pero la forma la garantiza el tipo.

4.5 Cómo empezar y cuánto pide


Cómo empezar	`// @ts-check` en un fichero de tu dominio, hoy. Después `jsconfig.json`. Después la migración gradual
Qué estudiar	Tipos básicos, uniones, interfaces frente a `type`, genéricos, `unknown` frente a `any`, guardas de tipo, utilidades (`Partial`, `Pick`, `Omit`, `Record`)
Cuánto tiempo	2–3 semanas para ser productivo. 2–3 meses para soltura con genéricos y tipos avanzados
Cuándo notarás el beneficio	El primer refactor grande. Ahí se paga solo
Qué NO hacer	Poner `any` en cuanto algo se complica. Cada `any` es un agujero que anula la garantía en cadena

Node.js y el backend

5.1 Qué es y por qué importa

Node.js es JavaScript fuera del navegador. El mismo lenguaje, el mismo bucle de eventos que estudiaste en 05-07, las mismas promesas — pero con acceso al sistema de ficheros, a la red y a procesos.

Lo que cambia:

Navegador	Node.js
`window`, `document`, DOM	No existen
`localStorage`	Sistema de ficheros y bases de datos
`fetch` para pedir	Servidor que responde peticiones
El usuario controla el entorno	Tú controlas el entorno
Nada es secreto	Las claves están seguras
Un usuario a la vez	Muchos a la vez, con estado compartido

Las dos últimas filas son las importantes, y ya te las encontraste en 11-05: la validación tiene que estar en el servidor porque el cliente lo controla el usuario, y los secretos solo pueden vivir donde el usuario no llega.

5.2 El camino, en cuatro pasos

Paso 1 · Un servidor HTTP básico. Con Express o Fastify, entender rutas, métodos, cabeceras, cuerpos y códigos de estado:

import express from 'express';
import { Tarea } from '../src/dominio/tarea.js';       // ← TU dominio, sin cambios
import { ErrorDeValidacion, ErrorDeRegla } from '../src/dominio/errores.js';

const app = express();
app.use(express.json({ limit: '100kb' }));

app.post('/v1/tareas', async (peticion, respuesta, siguiente) => {
  try {
    const tarea = new Tarea(peticion.body);            // R1-R15 en el servidor
    respuesta.status(201).json(await repositorio.guardar(tarea));
  } catch (error) {
    siguiente(error);
  }
});

// Manejador de errores centralizado: traduce errores de dominio a HTTP
app.use((error, _peticion, respuesta, _siguiente) => {
  if (error instanceof ErrorDeValidacion) {
    return respuesta.status(400).json({ codigo: 'VALIDACION', campo: error.campo, mensaje: error.message });
  }
  if (error instanceof ErrorDeRegla) {
    return respuesta.status(409).json({ codigo: 'REGLA', mensaje: error.message });
  }
  registrar(error);
  respuesta.status(500).json({ codigo: 'INTERNO', mensaje: 'Error interno' });
});

Ese import de tu propio dominio es la recompensa de toda la arquitectura del módulo. Las quince reglas, escritas y probadas una sola vez, ejecutándose en los dos lados. No es un ejemplo idealizado: funciona porque dominio/ nunca importó nada del navegador.

Paso 2 · Base de datos. SQLite para empezar (un fichero, cero instalación), PostgreSQL cuando lo necesites. Lo que hay que aprender: modelado relacional, claves foráneas, SQL básico, índices, y por qué las transacciones existen.

Paso 3 · Autenticación y autorización. La distinción que 11-05 dejó planteada: autenticación es quién eres; autorización es qué puedes hacer. Contraseñas con hash lento (bcrypt o argon2, nunca MD5 ni SHA a secas), sesiones con cookie HttpOnly o tokens, y permisos por rol — tu R15, ahora aplicada donde no se puede saltar.

Paso 4 · Producción. Variables de entorno, registro estructurado, límites de peticiones, CORS, copias de seguridad, contenedores.

5.3 Cómo empezar y cuánto pide


Cómo empezar	Sustituye tu `json-server` por un Express propio de 100 líneas que use tu dominio
Proyecto siguiente	El backend real de tu proyecto: base de datos, autenticación y despliegue. Convierte tu v1.0 en v2.0
Cuánto tiempo	1 mes para un CRUD con base de datos. 3–4 meses para algo con autenticación y desplegado con criterio
Qué NO hacer	Empezar por micro-servicios o GraphQL. Un monolito bien hecho primero

Una nota de honestidad sobre las bases de datos: es la parte donde más gente subestima el esfuerzo. Escribir un SELECT es fácil; modelar bien, entender qué hace un índice, y saber por qué una consulta tarda dos segundos es un mundo propio. Merece la pena y lleva tiempo.

Un framework en profundidad

6.1 Por qué dominar uno de verdad

En 10-06 aprendiste a elegir. Ahora toca dominar, y son cosas distintas.

Conocer cuatro frameworks a nivel de tutorial tiene un valor sorprendentemente bajo:

Nivel	Qué puedes hacer	Valor en el mercado
Tutorial (10 h)	Seguir un ejemplo, entender el vocabulario	Bajo
Funcional (100 h)	Construir una aplicación completa	Medio
Profundo (500+ h)	Depurar problemas raros, tomar decisiones de arquitectura, optimizar, formar a otros	Alto

La diferencia entre el segundo y el tercero es donde está el salto profesional. Y solo se consigue con uno, no repartiendo el tiempo entre cuatro.

6.2 Cuál elegir

Vuelve a la tabla de ponderación de 10-06 y aplícala a ti, no a un proyecto:

Criterio	Peso para tu decisión personal
Ofertas en tu ciudad o en remoto donde busques	Alto: mira ofertas reales, no encuestas globales
Qué te resultó más cómodo en el Módulo 10	Medio: la motivación importa
Sector al que quieres ir	Medio: hay correlaciones por sector
Tamaño de empresa objetivo	Bajo-medio

Un procedimiento concreto de una hora, y es la mejor hora que puedes invertir en esta decisión: abre un portal de empleo, filtra por tu ciudad y por «junior», y cuenta las menciones de cada framework en las primeras cincuenta ofertas. Ese número, para tu mercado, vale más que cualquier tendencia global.

6.3 Qué significa «en profundidad»

No es aprender más API. Es esto:

Nivel	Qué dominas
Fundamentos	Componentes, estado, props, ciclo de vida, eventos
Patrones	Composición, elevación de estado, contenedores frente a presentación, hooks o composables propios
Ecosistema	Enrutado, estado global, formularios, peticiones y caché de servidor
Pruebas	Testing Library con ese framework, y qué no probar
Rendimiento	Cuándo se re-renderiza, memorización, listas virtualizadas, división de código
Arquitectura	Estructura de carpetas, fronteras, dónde vive la lógica de negocio
Interioridades	Cómo funciona la reconciliación o la reactividad por dentro

Las dos últimas filas son las que separan a alguien que usa un framework de alguien en quien se confía para decidir cómo se usa en un equipo. Y fíjate en que la mayoría de esas filas ya las sabes conceptualmente: rendimiento (M9), pruebas (M8), arquitectura (M11). Lo que aprendes es cómo se expresan en esa herramienta.

6.4 Cómo empezar y cuánto pide


Cómo empezar	Reescribe tu propio proyecto con el framework elegido. Ya conoces el dominio: solo cambia la vista
Después	Un proyecto nuevo con el ecosistema completo: enrutado, estado, formularios, peticiones
Cuánto tiempo	2–3 meses para nivel funcional sólido. 6–12 meses de uso real para profundidad
Ventaja que tienes	En 10-06 quedó demostrado que `dominio/reglas.js` era idéntico en los cuatro. Tu dominio se reutiliza tal cual
Qué NO hacer	Saltar de framework cada dos meses. Elige uno y quédate el tiempo suficiente para llegar a lo difícil

Herramientas y plataforma

No es un camino en sí mismo: es lo que acompaña a cualquiera de los otros y lo que separa a alguien que programa de alguien que entrega software.

Área	Qué aprender	Prioridad	Tiempo
Git avanzado	`rebase` interactivo, `bisect`, `cherry-pick`, `reflog`, resolución de conflictos, flujos de trabajo	Alta	2 semanas
Terminal	Bash o Zsh, tuberías, `grep`, `find`, `sed`, guiones propios	Alta	Continuo
CI/CD	Ya tienes la base de 11-04. Matrices, cachés, entornos, aprobaciones	Media	2 semanas
Docker	Imágenes, contenedores, `docker-compose`, por qué existe	Media-alta	3 semanas
La nube	Un proveedor, servicios básicos: cómputo, almacenamiento, base de datos, red	Media	1–2 meses
Observabilidad	Registro estructurado, métricas, trazas, alertas	Media	2 semanas

Git avanzado es la de mejor relación entre esfuerzo y beneficio de toda la tabla, y la más infravalorada. Dos semanas de estudio y práctica te dan capacidades que usarás todos los días durante toda tu carrera:

Comando	Para qué sirve de verdad
`git bisect`	Encontrar automáticamente qué commit rompió algo. Solo funciona bien si tus commits son pequeños — lo que ya haces desde 11-02
`git rebase -i`	Limpiar el historial antes de fusionar: unir, reordenar, reescribir mensajes
`git reflog`	Recuperar trabajo que creías perdido. Casi nada se pierde de verdad en Git
`git worktree`	Trabajar en dos ramas a la vez sin `stash`
`git blame`	Encontrar el commit —y el ADR— que explica una línea rara

Esa última es la que cierra el círculo con 11-06: git blame sobre una línea extraña te lleva al commit, y el cuerpo del commit te lleva al porqué. Por eso se escriben así.

Docker en una frase, porque suele explicarse mal: es la forma de empaquetar tu aplicación con todo lo que necesita para ejecutarse —versión de Node, dependencias del sistema, configuración— en algo que funciona igual en tu portátil, en la CI y en producción. Resuelve el «en mi máquina funciona» de forma definitiva.

Profundizar en la plataforma web

Este camino es distinto de los demás: no se termina nunca y siempre da rendimiento, porque lo que aprendes aquí no depende de ninguna herramienta.

Área	Qué profundizar	Por qué
Accesibilidad	WCAG 2.2, ARIA de verdad, lectores de pantalla, auditorías	Obligación legal creciente y especialización con demanda y poca oferta
Seguridad	OWASP Top 10, XSS, CSRF, sesiones, CSP avanzada, cadena de suministro	Todo el mundo lo necesita, casi nadie lo domina
Rendimiento	Web Vitals a fondo, perfilado, red, renderizado	Impacto directo y medible en el negocio
Arquitectura front-end	Sistemas de diseño, monorepos, micro-frontends, contratos	Llega con el tamaño del equipo
Web Components	`customElements`, Shadow DOM, plantillas	Lo único que sobrevive a todos los frameworks
CSS moderno	Grid, consultas de contenedor, capas, `:has()`, propiedades personalizadas	Se ha usado en el curso, no enseñado

Sobre OWASP, porque es la más importante de la lista y la menos conocida: es una lista de los diez riesgos de seguridad más críticos en aplicaciones web, actualizada periódicamente y usada como referencia en toda la industria. Ya conoces varios de sus temas —XSS (06-02, 11-03), configuración insegura (11-05), secretos expuestos (11-05)—, pero hay otros que no se han tocado: control de acceso roto, fallos criptográficos, inyección, y la seguridad de la cadena de suministro (las dependencias que instalas).

Sobre Web Components, con el matiz de 10-06: son el estándar del navegador para crear elementos propios reutilizables, con connectedCallback como ciclo de vida, attachShadow para aislar estilos y CustomEvent para comunicar — todo lo que ya sabes, pero estandarizado. Su valor real no es sustituir a los frameworks, sino funcionar en cualquier sitio: un componente que tiene que vivir en una web de React, otra de Angular y otra sin nada.

Cómo estudiar este camino: no en bloques de dos meses, sino un tema al mes, en paralelo a lo demás. Un mes de accesibilidad seria aplicada a tu proyecto. Otro de OWASP con auditoría propia. Otro de CSS moderno rehaciendo tu interfaz. Es acumulativo y no caduca.

Las especializaciones

A medida que avances, aparece la pregunta de en qué te quieres convertir. No hay que responderla hoy, pero conviene conocer el mapa.

Especialización	Qué haces	Qué necesitas	Mercado
Front-end de producto	Interfaces, experiencia, colaboración con diseño	Un framework a fondo, CSS, accesibilidad, sensibilidad de producto	Amplio
Full-stack	Front y back, sistema completo	Framework + Node/otro lenguaje + base de datos + despliegue	El más demandado en empresas pequeñas y medianas
Rendimiento web	Medir y optimizar experiencias	M9 a fondo, red, navegadores, herramientas	Nicho, bien pagado
Accesibilidad	Auditar, corregir, formar	WCAG, ARIA, lectores, normativa	Nicho creciente, poca oferta de perfiles
Tooling / DevEx	Herramientas internas, CI, empaquetadores	Node, Git, CI/CD, empatía con quien desarrolla	Nicho, en empresas medianas y grandes
Móvil con web	Aplicaciones con tecnología web	React Native o similar + plataformas	Amplio
Ingeniería de plataforma	Infraestructura para equipos	Nube, contenedores, redes, automatización	Alto, requiere experiencia

Tres cosas que conviene saber sobre esto:

No hace falta elegir ahora. La mayoría de la gente descubre su especialización trabajando, al notar hacia qué problemas gravita.
Las especializaciones nicho tienen menos ofertas pero mucha menos competencia. Alguien que de verdad sabe de accesibilidad es difícil de encontrar; alguien que sabe React, no.
Empezar generalista es lo normal y lo sano. Especializarse demasiado pronto, sin haber visto suficiente, suele ser una decisión mal informada.

Cómo se sigue aprendiendo cuando ya no hay curso

Este apartado es, de toda la lección, el que más va a determinar dónde estés dentro de tres años. Porque a partir de mañana nadie te va a decir qué toca estudiar.

10.1 Las fuentes fiables

No todas las fuentes son iguales, y distinguirlas ahorra muchísimo tiempo perdido:

Fuente	Fiabilidad	Para qué
MDN Web Docs	Muy alta	La referencia de la plataforma web. Tu primera parada, siempre
Especificaciones (WHATWG, ECMA, W3C)	Máxima	Cuando MDN no basta o hay un caso límite raro
Documentación oficial de la herramienta	Alta	Empezar y consultar
Notas de versión y `CHANGELOG`	Alta	Enterarse de cambios reales sin ruido
Blogs de ingeniería de empresas conocidas	Media-alta	Experiencias reales con contexto
Libros técnicos	Alta, aunque envejecen	Profundidad y estructura
Vídeos y tutoriales	Variable	Primer contacto; verifica siempre
Respuestas en foros	Variable y a menudo obsoleta	Pistas, nunca la última palabra
Contenido generado sin verificar	Baja	Punto de partida, jamás la respuesta final

Tres hábitos concretos que valen más que cualquier lista de recursos:

Ve a MDN antes que a un buscador. La mitad de las veces que buscas algo de JavaScript o del DOM, la respuesta canónica está ahí, actualizada y con la tabla de compatibilidad.
Lee las notas de versión de lo que usas. Diez minutos cuando sale una versión nueva de Node, de tu framework o de tu empaquetador. Es la forma más eficiente que existe de mantenerse al día, porque es información filtrada por relevancia real.
Verifica la fecha de todo lo que leas. Una respuesta de 2016 sobre asincronía en JavaScript puede ser correcta o completamente obsoleta, y no lo dice.

10.2 Aprender construyendo

Sigue siendo, con diferencia, la forma más eficaz. La progresión que funciona:

Nivel	Qué construir	Qué se aprende
1	Reescribir algo que ya hiciste con tecnología nueva	La tecnología, sin la carga de diseñar el problema
2	Una herramienta para ti mismo	Requisitos reales; los usas y ves los fallos
3	Algo que use otra persona	Casos límite, soporte, comentarios reales
4	Algo con restricciones difíciles	Escala, tiempo real, offline, accesibilidad seria

El nivel 2 es el punto óptimo y el más infravalorado. Una herramienta que resuelva un problema tuyo real —un lector de algo, un organizador de lo que sea, un panel de datos que consultas a menudo— tiene tres ventajas enormes: sabes exactamente qué debe hacer, la usas de verdad (así que los fallos aparecen), y la motivación no depende de nadie.

Y una regla de tamaño, ya conocida de 11-01 pero aplicada al aprendizaje: mejor un proyecto pequeño terminado que uno grande a medias. Terminar enseña cosas que empezar no enseña nunca: despliegue, documentación, casos límite, mantenimiento.

Leer código ajeno y contribuir

Leer código ajeno es la habilidad que más rápido crece y menos se practica. En el trabajo real leerás mucho más código del que escribes.

Cómo leer un proyecto que no conoces, con método:

#	Paso	Qué buscas
1	README y documentación	Qué es y cómo se ejecuta
2	Estructura de carpetas	El mapa mental de quien lo escribió
3	Punto de entrada (`main`, `index`)	Por dónde empieza todo
4	Un flujo completo, siguiendo las llamadas	Cómo se conecta
5	Las pruebas	La mejor documentación de comportamiento que existe
6	El historial de un fichero raro	Por qué está así (`git log -p`, `git blame`)

El paso 5 es el atajo que casi nadie usa: si quieres saber qué hace un módulo, lee sus pruebas antes que su código. Están escritas para explicar comportamiento, no para implementarlo.

Contribuir a proyectos de código abierto enseña cosas que ningún proyecto propio puede enseñar:

Trabajar con convenciones que no elegiste.
Pasar por una revisión de código real de alguien que no te conoce.
Entender un sistema grande antes de tocarlo.
Escribir mensajes de commit y descripciones de PR para desconocidos.

Cómo empezar, en orden de dificultad creciente:

Documentación. Un error, un ejemplo que falta, una traducción. Es una contribución real y la barrera es mínima.
Reproducir incidencias. Coger un fallo reportado, confirmarlo y añadir un caso mínimo. Es muy útil y muy valorado.
Buenas primeras incidencias. Muchos proyectos las etiquetan para gente nueva.
Corrección pequeña con prueba. Un fallo acotado, con su prueba de regresión.
Funcionalidad, siempre después de proponerla en una incidencia. Nunca abras una PR grande sin haberla discutido.

Y una preparación emocional honesta: tu primera contribución probablemente reciba comentarios, cambios pedidos, o incluso el rechazo. Es lo normal y no es personal. Quien mantiene un proyecto vela por su coherencia a largo plazo, no por tu tarde. Aplica lo de 11-06: la crítica al código no es crítica a ti.

Cómo mantenerse al día sin agotarse

El desarrollo web tiene fama de cambiar demasiado rápido. Es verdad a medias, y la mitad falsa es la que produce agotamiento.

Lo que cambia rápido:

Las librerías de moda y sus versiones mayores.
Las herramientas de compilación.
Los patrones concretos dentro de un framework.
Las opiniones sobre la mejor forma de hacer algo.

Lo que no cambia:

El lenguaje (añade, casi nunca rompe).
El DOM y los eventos.
HTTP, la caché, la seguridad.
La accesibilidad.
Cómo se prueba, cómo se depura, cómo se mide.
Diseñar un modelo de datos y unas reglas.
Saber decidir.

La proporción es la clave de todo este apartado: lo estable es la mayor parte de lo que usas a diario, y es exactamente lo que este curso te ha dado.

Las cinco reglas de higiene informativa:

Regla	Detalle
1 · No intentes seguirlo todo	Es imposible y es el origen del agotamiento. Elige tres o cuatro áreas
2 · Filtra por permanencia	Antes de estudiar algo, pregúntate: ¿esto seguirá siendo cierto en cinco años?
3 · Aprende bajo demanda	Estudia lo que necesitas para lo que estás haciendo. Lo aprendido sin uso se olvida en semanas
4 · Un tema a la vez	Profundidad en uno vale más que superficie en cinco
5 · Descansa sin culpa	Nadie está al día de todo. Nadie. Ni las personas que más admiras técnicamente

Un ritmo sostenible concreto, que puedes copiar:

Frecuencia	Actividad	Tiempo
Diaria	Escribir código (aunque sean 30 minutos)	30–60 min
Semanal	Leer algo técnico con calma	1–2 h
Mensual	Un tema nuevo, aplicado a algo real	4–8 h
Trimestral	Revisar dónde estás y ajustar el rumbo	1 h
Anual	Un salto grande (una tecnología o especialización)	—

La constancia gana a la intensidad, y no es un tópico: una hora al día durante un año son 365 horas y un hábito; un fin de semana de doce horas cada dos meses son 72 horas y ningún hábito.

Sobre el síndrome del impostor, que aparecerá: es prácticamente universal en esta profesión, y tiene una causa estructural. Comparas tu interior —tus dudas, tus búsquedas, lo que no sabes— con el exterior de los demás —sus charlas, sus artículos, sus respuestas seguras—. Nadie publica sus tres horas buscando un punto y coma. El antídoto que funciona no es convencerse de que se vale mucho, sino llevar registro de lo hecho: hace un año no sabías qué era una promesa; hoy has desplegado un producto con cola de sincronización idempotente. Eso es un dato, no una impresión.

Por qué las bases no caducan

Vale la pena cerrar el argumento con el dato del propio curso, porque es más convincente que cualquier afirmación.

En 10-06 escribiste la misma pantalla cuatro veces: JavaScript puro, React, Vue y Angular. Y el resultado fue que dominio/reglas.js era idéntico en las cuatro. Las mismas cuarenta líneas. Todo lo que cambió fue la vista.

Eso significa, de forma medida y no opinada:

Lo que sobrevive a un cambio de framework	Lo que no
El lenguaje	La sintaxis concreta de las plantillas
El modelo de datos y las reglas	El nombre del hook o de la directiva
Saber estructurar en capas	La estructura de carpetas de moda
Las pruebas de comportamiento	Las pruebas acopladas a la implementación
HTTP, caché, seguridad	La librería de peticiones de turno
Accesibilidad	—
Rendimiento y cómo medirlo	Los umbrales exactos
El criterio para decidir	Las opiniones de este año

Y hay una segunda demostración en tu propio proyecto: tu dominio/ sin dependencias del navegador se puede importar tal cual en un servidor Node y ejecutar las mismas quince reglas. No porque sea listo el diseño, sino porque respetaste una frontera durante todo el módulo.

La conclusión práctica es liberadora: cada hora invertida en fundamentos se amortiza durante toda tu carrera; cada hora invertida en la herramienta de moda se amortiza durante el tiempo que dure la moda. No significa ignorar las herramientas —hay que usarlas y hay que dominar una—, sino saber dónde estás invirtiendo cada vez.

La hoja de ruta de seis meses

Tres perfiles según tu disponibilidad real. Elige el tuyo con honestidad, no el que te gustaría poder cumplir: un plan incumplido desde la tercera semana se abandona entero.

Perfil	Horas/semana	Total 6 meses	Situación típica
A · Intensivo	20–25 h	~550 h	Dedicación completa o casi
B · Sostenido	10–12 h	~280 h	Trabajo o estudios + tardes y fines de semana
C · Ligero	4–6 h	~130 h	Poco tiempo, pero constante

14.1 Perfil A · Intensivo (20–25 h/semana)

Mes	Foco principal	Entregable
1	TypeScript: JSDoc → migración de tu proyecto completo	Tu proyecto en TS estricto, sin `any`
2	Framework elegido: fundamentos + reescribir tu proyecto	Tu proyecto en el framework, con pruebas
3	Framework: ecosistema completo (enrutado, estado, formularios, peticiones)	Proyecto nuevo mediano, desplegado
4	Node.js: servidor, base de datos, autenticación	Backend real de tu proyecto
5	Full-stack: integrar, desplegar, monitorizar	Producto completo en producción
6	Empleabilidad: portafolio, currículum, entrevistas, algoritmos básicos	Portafolio y candidaturas enviadas

14.2 Perfil B · Sostenido (10–12 h/semana)

Mes	Foco principal	Entregable
1	TypeScript con JSDoc sobre tu dominio	`dominio/` tipado y comprobado
2	TypeScript completo + Git avanzado	Proyecto migrado; historial limpio
3	Framework: fundamentos, reescribiendo tu proyecto	Tu proyecto en el framework
4	Framework: ecosistema + pruebas	Proyecto pequeño nuevo, desplegado
5	Node.js: servidor + base de datos	API propia funcionando
6	Integración y portafolio	Producto full-stack + portafolio

14.3 Perfil C · Ligero (4–6 h/semana)

Mes	Foco principal	Entregable
1	TypeScript con `// @ts-check` y JSDoc	Dominio comprobado sin compilar
2	TypeScript: tipos de la capa de datos	Repositorio y API tipados
3	Framework: fundamentos	Una pantalla de tu proyecto migrada
4	Framework: aplicación pequeña completa	Aplicación desplegada
5	Node.js: un servidor mínimo con tu dominio	API de 3 rutas funcionando
6	Consolidar y portafolio	Portafolio actualizado con 2 proyectos

gantt
    title Hoja de ruta de 6 meses — perfil B (sostenido, 10-12 h/semana)
    dateFormat YYYY-MM-DD
    axisFormat %b

    section TypeScript
    JSDoc y @ts-check sobre el dominio     :ts1, 2026-12-01, 30d
    Migración completa + strict            :ts2, after ts1, 30d
    section Herramientas
    Git avanzado (rebase, bisect, reflog)  :git, after ts1, 21d
    section Framework
    Fundamentos reescribiendo el proyecto  :fw1, after ts2, 30d
    Ecosistema, pruebas y despliegue       :fw2, after fw1, 30d
    section Backend
    Node, Express y base de datos          :node, after fw2, 30d
    section Cierre
    Integración full-stack y portafolio    :fin, after node, 30d
    Plataforma web (1 tema/mes, continuo)  :plat, 2026-12-01, 180d

Fíjate en la última barra: «plataforma web» recorre los seis meses enteros. Es el camino continuo del apartado 8, un tema al mes en paralelo. No compite con lo demás porque es de otra naturaleza.

Cómo usar el plan:

Elige tu perfil con honestidad. El B es el realista para la mayoría de la gente.
Ajusta el orden a tu objetivo. Si buscas empleo pronto, adelanta el framework al mes 1.
Revísalo cada mes. Si un tema te está costando el doble, ajusta el plan, no te castigues.
Un entregable por mes, sin excepción. Sin algo terminado, el mes no cuenta. Es la misma disciplina de los hitos de 11-01.
Protege dos franjas fijas a la semana. La pérdida de ritmo es la causa número uno de abandono, muy por delante de la dificultad.

Carrera: portafolio, currículum y entrevistas

Empiezo por la parte honesta, porque hay demasiado material que no la dice: el mercado de entrada es competitivo. Hay muchas más personas buscando un primer empleo que puestos junior, los procesos son largos, y recibirás silencios y rechazos que no reflejan tu valía. Esto no es desánimo: es información para que interpretes correctamente lo que va a pasar y no lo leas como un veredicto sobre ti.

Lo que sí puedes controlar, y donde la mayoría de la gente no aprovecha su margen:

15.1 El portafolio

Regla	Detalle
Dos o tres proyectos, no diez	Uno grande y terminado —el tuyo— y uno o dos pequeños bien acabados
Terminados de verdad	Desplegados, con README, con pruebas, defendibles
Con decisiones documentadas	Los ADR de 11-06 son un diferenciador enorme y casi nadie los tiene
Con demo accesible	Un enlace que funcione, con datos de ejemplo cargados
Sin clones de tutorial	Otra lista de tareas de tutorial no dice nada. La tuya sí, porque tiene reglas, arquitectura y decisiones propias

15.2 El currículum técnico

Sección	Qué poner
Encabezado	Nombre, puesto objetivo, ciudad/remoto, correo, GitHub, LinkedIn
Resumen	2–3 líneas: qué sabes hacer y qué buscas. Sin adjetivos vacíos
Proyectos	Antes que la formación si no tienes experiencia. Con números y enlaces
Tecnologías	Agrupadas y honestas: separa lo que dominas de lo que conoces
Experiencia	Aunque sea de otro sector: hay competencias transferibles reales
Formación	Al final si no es lo más relevante

Los errores más frecuentes:

Listar 30 tecnologías. Comunica superficialidad y te expone a preguntas que no puedes responder.
Poner niveles con barras o porcentajes. «JavaScript 85 %» no significa nada.
Adjetivos sin evidencia: «apasionado», «proactivo», «resiliente».
No poner enlaces. El GitHub y la demo son lo que de verdad se mira.
Más de dos páginas sin experiencia que lo justifique.

15.3 Las entrevistas

Fase	Qué evalúan	Cómo prepararte
Filtro inicial	Encaje básico, comunicación, expectativas	Ten tu presentación de dos minutos preparada
Técnica de conocimientos	Fundamentos: JavaScript, DOM, asincronía, HTTP	Repasa M3, M5 y M7. Sabe explicar el bucle de eventos
Ejercicio práctico	Cómo escribes y cómo piensas	Practica en voz alta; explicar mientras codificas es una habilidad aparte
Sobre tu proyecto	Criterio y profundidad	Ya lo tienes preparado (11-06)
Cultural / equipo	Cómo trabajas con otros	Ejemplos concretos de colaboración y de conflicto resuelto

Los temas que más se preguntan a nivel junior, y en los que este curso te ha preparado:

Tema	Módulo
`var`, `let`, `const`, ámbito y hoisting	03-04, 03-05
Closures	03-04
`this` y sus reglas	04-02
Prototipos y herencia	05-01
Promesas, `async/await` y el bucle de eventos	05-06, 05-07
Igualdad, coerción y valores falsy	01-07
`map`, `filter`, `reduce`	04-04, 04-05
Delegación de eventos y propagación	06-04
Peticiones, errores, CORS	07-02, 07-03
Cómo probarías esto	M8

Sobre los ejercicios de algoritmos. Algunos procesos los incluyen y otros no, y su peso varía muchísimo. Si en las ofertas que te interesan aparecen, dedica un par de horas semanales durante unas semanas a los fundamentos: arrays, cadenas, mapas y conjuntos, dos punteros, y saber razonar sobre complejidad. No es lo primero a lo que dedicar tiempo si no lo piden, pero tampoco conviene descubrirlo el día de la entrevista.

Y el consejo que más cambia el resultado de una entrevista técnica: piensa en voz alta. Quien te entrevista quiere ver cómo razonas, no solo si llegas. Di lo que estás considerando, las alternativas que descartas y por qué. Un ejercicio a medias con un razonamiento excelente puntúa mejor que una solución correcta salida de la nada — y si te bloqueas, decir «no sé esto, pero lo abordaría así» es una respuesta perfectamente válida.

El primer empleo y aprender en el trabajo

16.1 Cómo buscarlo

Vía	Eficacia	Nota
Contactos y recomendaciones	La más alta	Encuentros locales, comunidades, antiguos compañeros
Portales de empleo	Media	Mucho volumen, mucha competencia
Candidatura directa a empresas	Media-alta	Personalizada, a empresas que te interesen de verdad
Reclutadores especializados	Media	Útiles si te llegan; poco control
Prácticas y becas	Alta	La puerta de entrada clásica y perfectamente válida

Una recomendación concreta y contrastada: ve a encuentros técnicos de tu ciudad. No a repartir currículums —eso funciona mal—, sino a conocer gente y hablar de lo que hacéis. Una proporción muy alta de los primeros empleos llega por alguien que te conoce, no por un formulario.

Y una calibración importante: las ofertas listan un ideal, no un requisito. Si cumples una parte razonable de lo que piden, presenta la candidatura. Descartarte tú antes de que te descarten es el error más caro y más común.

16.2 Los primeros meses

Mes	Qué esperar	Qué hacer
1	Sensación de no entender nada	Es normal y universal. Pregunta mucho; toma notas
2–3	Primeras tareas pequeñas	Termínalas bien. La fiabilidad vale más que la velocidad
4–6	Empiezas a moverte solo	Ofrécete para lo que nadie quiere: se aprende ahí
6–12	Aportas de verdad	Empieza a proponer, no solo a ejecutar

Cinco cosas que aceleran mucho el aprendizaje en el trabajo:

Pregunta pronto, con contexto. «He probado A y B, esperaba X, obtengo Y, ¿por dónde tiro?» es una pregunta que a nadie molesta. Estar bloqueado tres días en silencio, sí.
Lee el código del repositorio aunque no te toque. Es la forma más rápida de entender el sistema y las convenciones.
Pide revisiones y pídelas exigentes. «¿Me dices qué harías distinto?» es la frase que más te hará crecer.
Revisa el código de otros. Enseña muchísimo, aunque al principio te sientas sin autoridad para hacerlo. Preguntar en una revisión ya es aportar.
Escribe lo que aprendes. Un documento propio de «cosas de este sistema». En seis meses será tu activo más valioso, y en doce, el que usen los que lleguen después.

Y una advertencia sobre las comparaciones. Vas a trabajar con gente que sabe mucho más que tú. Eso no es una señal de que no vales: es exactamente la razón por la que ese es un buen sitio para estar. Un entorno donde eres la persona que más sabe es un entorno donde no aprendes.

Errores Comunes y Consejos

Empezar cuatro caminos a la vez. TypeScript, React, Node y Docker en paralelo produce tres meses de sensación de avance y cero profundidad en nada. Uno a la vez, con un entregable por mes.

Saltar de framework cada dos meses. El valor está en la profundidad, y la profundidad solo llega tras el punto en el que la novedad se acaba y empiezan los problemas difíciles. Elige uno y quédate.

Aprender por acumulación en lugar de por uso. Ver veinte horas de vídeo sin escribir código produce la sensación de aprender y muy poco aprendizaje real. La regla: por cada hora de consumo, al menos una de construcción.

Esperar a «saber lo suficiente» para buscar empleo. Ese momento no llega nunca porque el listón sube contigo. Con un proyecto terminado y defendible ya tienes más que mucha gente que está aplicando.

Confundir el ruido con la profesión. Las discusiones sobre qué framework es mejor son entretenimiento. El trabajo real es entender problemas, modelarlos, y entregar algo que funciona y se mantiene.

Descartarte antes de que te descarten. Las ofertas listan ideales. Si cumples una parte razonable, preséntate: la decisión no es tuya.

Compararte con perfiles públicos. Comparas tu interior con el exterior de otros. Nadie publica sus tres horas buscando un punto y coma.

Abandonar por perder el ritmo dos semanas. Perder el ritmo es normal. Lo que hunde un plan no es la pausa, sino convertir la pausa en abandono. Vuelve con una sesión pequeña, sin recuperar nada.

Consejo · Escribe lo que aprendes, aunque no lo publique nadie. Explicar obliga a entender de verdad, y detecta los huecos que la lectura oculta. Si además lo publicas, es portafolio.

Consejo · Termina cosas, aunque sean pequeñas. Terminar enseña lo que empezar nunca enseña: despliegue, documentación, casos límite y mantenimiento. Y es la competencia que más te diferencia.

Consejo · Guarda tu curva de progreso. Un fichero con lo que sabías hace seis meses. Es el antídoto más eficaz contra el síndrome del impostor, porque es un dato y no una impresión.

Consejo · Enseña a alguien. Explicar a quien empieza consolida más que releer. Y ahora mismo puedes: hay quien está donde estabas tú en el Módulo 1.

Consejo · Ten siempre un proyecto propio en marcha. Aunque sea pequeño y lento. Es donde pruebas sin consecuencias, donde mantienes la curiosidad y donde nace casi todo lo que luego usas en el trabajo.

Ejercicios

Los últimos ejercicios del curso no son de código: son de dirección. Dedícales tiempo real, porque su resultado es lo que harás durante los próximos seis meses.

Ejercicio 1 — El balance y el plan.

Rellena tu inventario de competencias: recorre la tabla del apartado 1 y marca cada fila con «lo domino», «lo he hecho», «lo he visto». Sé honesto: la tabla es para ti.
De la lista del apartado 2, elige las tres áreas no cubiertas que más te importan para tu objetivo, y escribe por qué cada una.
Elige tu perfil de dedicación (A, B o C) contando las horas reales de las que dispones esta semana, no las que te gustaría tener.
Escribe tu hoja de ruta de seis meses con la plantilla del apartado 14, adaptada a tu objetivo: mes, foco y entregable concreto. Un entregable por mes, sin excepción.
Dibuja tu plan como diagrama de Gantt en Mermaid, incluida la barra continua de plataforma web.
Reserva las franjas en tu calendario —dos fijas por semana— y ponles una alarma de revisión mensual.
Escribe tu objetivo de seis meses en una frase, del estilo «en seis meses quiero poder construir y desplegar una aplicación full-stack con TypeScript y presentarme a puestos junior de front-end».

Ejercicio 2 — El primer paso de TypeScript, hoy.

No dejes que el plan se quede en papel: el primer paso se da ahora y cuesta una tarde.

Añade // @ts-check al fichero más importante de tu dominio.
Documenta con JSDoc todas sus funciones públicas: parámetros, tipos de retorno, opcionales y null.
Corrige todo lo que el editor subraye. Anota cuántos problemas reales encontró — habrá alguno que no esperabas.
Crea jsconfig.json con checkJs y strict para todo src/, y anota cuántos errores aparecen.
Escribe el equivalente del fichero tipos.ts del apartado 4.4 para tu dominio: uniones de literales para tus conjuntos cerrados, readonly donde corresponda, y el Record que garantiza que tu matriz de transiciones cubre todos los estados.
Documenta en docs/decisiones.md qué te ha aportado y qué te ha costado. Es la información con la que decidirás si migras del todo.

Ejercicio 3 — La dirección y el portafolio.

Elige tu framework con el procedimiento de una hora del apartado 6.2: cincuenta ofertas reales de tu mercado, contadas. Anota los números y la conclusión.
Elige el tema mensual de plataforma web para los próximos tres meses (accesibilidad, seguridad, CSS moderno, rendimiento…) y qué harás con cada uno sobre tu proyecto.
Actualiza tu portafolio con lo de 11-06: repositorio fijado, README del perfil, currículum con números concretos y enlaces.
Escribe tu presentación de dos minutos: quién eres, qué sabes hacer, qué has construido y qué buscas. Ensáyala en voz alta.
Identifica tres empresas en las que te gustaría trabajar y anota, para cada una, qué piden que todavía no tienes. Eso ajusta tu hoja de ruta con datos reales.
Enseña algo a alguien: escribe una explicación de un concepto que domines —closures, el bucle de eventos, por qué el dominio no debe conocer el navegador— dirigida a quien está donde tú estabas en el Módulo 1. Publícala o compártela.
Empieza el proyecto siguiente, aunque sea pequeño. La mejor forma de consolidar lo aprendido es usarlo antes de que se enfríe.

Soluciones

No hay soluciones correctas para estos ejercicios: son decisiones tuyas. Estos son los criterios con los que puedes juzgar si tu plan es bueno.

Criterios de un buen plan de seis meses

#	Criterio	Señal de que falla
1	Una dirección principal	Cuatro tecnologías en el mes 1
2	Horas realistas	El perfil A con 5 horas libres a la semana
3	Un entregable concreto por mes	«Aprender TypeScript» en vez de «proyecto migrado a TS estricto»
4	Entregables verificables	No se puede decir si está hecho o no
5	Construye sobre lo que ya tienes	Empieza un proyecto nuevo desde cero en vez de aprovechar el tuyo
6	Deja margen	Seis meses llenos al 100 %, sin holgura
7	Apunta a un objetivo declarado	No sabes para qué es el plan
8	Tiene revisión mensual	Se escribe una vez y no se vuelve a mirar

Rúbrica del plan (18 puntos)

Dimensión	0	1	2	3
Honestidad del inventario	Inflado o vacío	Aproximado	Realista	Con evidencia por competencia
Elección de dirección	Sin decidir	Elegida	Justificada	Con datos de tu mercado
Realismo de horas	Fantasía	Optimista	Realista	Medida con la semana real
Entregables	Vagos	Concretos	Verificables	Cada uno usable en el portafolio
Continuidad	Sin franjas	Franjas	Franjas protegidas	Además con revisión mensual agendada
Conexión con el objetivo	Ninguna	Implícita	Explícita	Con tres empresas y sus huecos identificados

Umbral: 12/18. Y una condición que no se compensa: el ejercicio 2 tiene que estar hecho, no planificado. Un plan sin un primer paso dado el mismo día es una lista de deseos.

La autoevaluación final del curso:

Pregunta	Sí / No
¿Tengo un producto propio terminado, desplegado y defendible?
¿Sé explicar por qué tomé sus decisiones principales?
¿Sé qué no cubre este curso y cuáles de esos huecos me importan?
¿Tengo una dirección principal elegida para los próximos seis meses?
¿He dado ya el primer paso, hoy, no «la semana que viene»?
¿Tengo dos franjas semanales protegidas en el calendario?
¿Sé dónde buscar cuando no sepa algo, y distinguir una fuente fiable?
¿Entiendo que el listón sube conmigo y que eso es progreso, no fracaso?

Conclusión

Aquí se acaba el curso, así que este cierre no prepara la lección siguiente: hace balance y te devuelve el mando.

Tienes el inventario real de lo que sabes, competencia a competencia y módulo a módulo: montar un entorno y leer un error sin bloquearte; expresar reglas con condicionales y manejar errores distinguiendo lo esperado de lo excepcional; descomponer en funciones, usar closures y resolver estructuras recursivas; modelar entidades y transformar colecciones; diseñar clases con encapsulación real, organizar en módulos y dominar la asincronía; construir interfaces sin framework con eventos, delegación y formularios accesibles; persistir, hablar con una API, usar WebSockets y convertir una web en PWA; depurar con método y probar en tres niveles; medir antes de optimizar y fijar un presupuesto; conocer cuatro frameworks y, sobre todo, elegir con criterio; y planificar, construir, sincronizar, probar, desplegar y defender un producto completo. Con las competencias transversales que ningún temario lista: convertir un problema en un modelo y unas reglas, decidir y poder defenderlo, medir antes de opinar, depurar con método, escribir código mantenible y —la que más te diferencia— terminar cosas.

Y tienes, con la misma honestidad, lo que este curso no cubre: tipado estático, backend, un framework en serio, CSS moderno, bases de datos, algoritmos, seguridad en profundidad, arquitectura a escala, DevOps, móvil, y las cosas que solo se aprenden trabajando con otras personas y con código que escribió alguien hace cuatro años. Conocer los propios huecos vale tanto como conocer las propias capacidades, y no confundir «no lo domino todavía» con «no valgo» es una habilidad profesional en sí misma.

Tienes el mapa de los caminos con la regla que lo gobierna: una dirección principal para los próximos seis meses, una sola, porque las demás seguirán ahí. TypeScript como el más barato de empezar —hoy, con // @ts-check y JSDoc sobre tu propio dominio, sin compilar nada— y el que multiplica el valor de todo lo demás, con la migración gradual empezando por el dominio y con esas cuatro cosas que se consiguen gratis: uniones de literales que hacen imposible escribir un estado inventado, readonly que expresa la encapsulación en el tipo, un Record que obliga a cubrir todas las transiciones, y tu contrato de repositorio comprobado por el compilador. Node.js como el camino que cierra el sistema, con la recompensa concreta de importar tu propio dominio/ en un servidor y ejecutar las mismas quince reglas donde el usuario no puede saltárselas. Un framework en profundidad, con la diferencia clara entre las cien horas que dan nivel funcional y las quinientas que dan valor real, elegido con una hora de contar ofertas de tu mercado en lugar de tendencias globales, y empezando por reescribir tu propio proyecto porque el dominio ya está hecho. Y los dos caminos continuos: herramientas —con Git avanzado como la mejor inversión por hora de toda la tabla— y la plataforma web, un tema al mes, que no caduca nunca.

Sabes cómo se sigue aprendiendo cuando ya no hay curso: MDN antes que un buscador, las notas de versión como la forma más eficiente de estar al día, la fecha de todo lo que leas, y la progresión de construir que tiene su punto óptimo en una herramienta para ti mismo, porque sabes qué debe hacer, la usas de verdad y la motivación no depende de nadie. Sabes leer código ajeno empezando por las pruebas, y contribuir empezando por la documentación, con la preparación emocional de que los primeros comentarios llegarán y no son personales.

Sabes mantenerte al día sin agotarte, distinguiendo lo que cambia rápido —librerías, herramientas, opiniones— de lo que no cambia —el lenguaje, el DOM, HTTP, la accesibilidad, cómo se prueba, cómo se mide, cómo se decide—, con las cinco reglas de higiene informativa y un ritmo sostenible donde la constancia gana a la intensidad. Y sabes que el síndrome del impostor tiene una causa estructural —comparar tu interior con el exterior de los demás— y un antídoto que es un dato y no una frase de ánimo: llevar registro de lo hecho.

Tienes el argumento de por qué las bases no caducan, y no como opinión sino como medición de este mismo curso: dominio/reglas.js fue idéntico en JavaScript puro, React, Vue y Angular. Las mismas cuarenta líneas. Todo lo que cambió fue la vista. Cada hora invertida en fundamentos se amortiza durante toda tu carrera.

Tienes una hoja de ruta de seis meses en tres perfiles de dedicación, con un entregable obligatorio por mes y dos franjas semanales protegidas, porque la pérdida de ritmo hunde más planes que la dificultad. Y tienes la parte de carrera con su honestidad por delante: el mercado de entrada es competitivo y los silencios no son un veredicto sobre ti; lo que controlas es un portafolio de dos o tres proyectos terminados y defendibles —con ADR, que casi nadie tiene—, un currículum con números y enlaces en lugar de adjetivos y barras de porcentaje, y unas entrevistas donde pensar en voz alta cambia el resultado más que saber la respuesta. Y los primeros meses de trabajo, donde no entender nada es universal, donde preguntar con contexto no molesta a nadie, y donde trabajar con gente que sabe más que tú no es una amenaza: es exactamente la razón por la que ese es un buen sitio para estar.

Y ahora el cierre de verdad.

La primera línea de código de este curso fue console.log('Hola, Taller Nómada');. Una función, una cadena de texto y un mensaje en una consola. Ese día no sabías qué era una variable, y el tablero de Marta, Iván y Lucía eran seis tareas y cuarenta y ocho horas que ni siquiera cabían en un objeto porque los objetos venían tres módulos después. Desde entonces esas seis tareas han sido condicionales, bucles, funciones, arrays, clases, promesas, nodos del DOM, peticiones a una API, pruebas, milisegundos medidos y cuatro versiones de la misma pantalla. Han sido el hilo que sostuvo cada concepto nuevo, y siguen ahí, intactas: 48 horas, 45 abiertas, una vencida, esfuerzo ponderado 124.

Pero Nómada Tareas dejó de ser tu proyecto hace seis lecciones. En el Módulo 11 el ejemplo guiado se apartó y construiste lo tuyo: tu producto, tu modelo, tus reglas, tus decisiones, tus fallos y tus pruebas de regresión. Taller Nómada se quedó donde tenía que quedarse, como referencia contra la que comparar, y lo que se despliega hoy con HTTPS lleva tu nombre y no el suyo.

Eso es todo lo que este curso podía darte: un lenguaje, un método y un producto terminado que demuestra que sabes usarlos. Lo que queda no lo puede escribir nadie más, porque ya no hay una lección siguiente que enlazar ni un módulo que empiece mañana. Hay una hoja de ruta que has escrito tú, un editor abierto, y la única pregunta que importa a partir de aquí:

Siguientes Pasos: TypeScript, Node.js y tu Carrera