Tu proyecto está terminado, documentado, defendido y publicado: Presentación del proyecto cerró la última tarea pendiente. Esta lección no enseña sintaxis nueva ni añade nada al proyecto; sirve para lo que viene después, que es una pregunta legítima y bastante angustiosa cuando se termina un curso: ¿y ahora qué? Vamos a responderla en cuatro tiempos. Primero, un balance honesto de lo que sabes hacer hoy y no sabías hace nueve módulos. Segundo, el mapa de lo que existe ahí fuera y este curso no cubrió, para que sepas qué hay y para qué sirve. Tercero, los caminos profesionales que se abren desde donde estás, con expectativas realistas. Y cuarto, un plan concreto de tres meses, porque la diferencia entre quien sigue programando dentro de un año y quien lo deja no es el talento: es tener la siguiente cosa que hacer.

1. El camino recorrido
2. TareaFácil, de la v0.1 a la v1.0
3. Lo que este curso no cubrió
4. Elegir un camino
5. Cómo seguir aprendiendo
6. Hábitos profesionales que conviene consolidar
7. Trabajar con asistentes de IA
8. Errores frecuentes de quien empieza
9. Un plan para los próximos tres meses
10. Errores comunes y consejos
11. Ejercicios
12. Conclusión

Empezaste sin saber qué era una variable. Este es el inventario, módulo a módulo, de lo que sabes hacer ahora; léelo despacio, porque la sensación normal al terminar un curso es la de no saber nada, y eso no es lo que dice la tabla:

Esa última fila es la que más pesa. Hay mucha gente que conoce la sintaxis de Python; hay bastante menos que haya llevado un proyecto propio de la idea a la v1.0 publicada. Lo primero se aprende en unas semanas; lo segundo es lo que hace falta para trabajar.

Si necesitas una prueba tangible del camino, ahí está TareaFácil. Empezó siendo tres print y una lista, y terminó siendo un paquete instalable con pruebas. Su historia es la del curso:

La distancia se ve mejor comparando la misma idea escrita al principio y al final. Así se listaban las tareas en la v0.1:

Y así en la v1.0:

Entre los dos fragmentos hay nueve módulos: funciones con parámetros y valores por defecto, anotaciones de tipo, docstring, una clase que encapsula la colección, filtrado y ordenación por criterio, el caso de lista vacía previsto y __str__ haciendo el formato. Pero la diferencia importante no es la sintaxis, sino que el segundo funciona con tres tareas y con trescientas, y que se puede probar, cambiar y ampliar sin reescribirlo.

Marta, Luis y Nuria empezaron con un cuaderno donde apuntaban quién hacía qué para la Panadería Solé y acabaron con una herramienta que reparte el trabajo del estudio, avisa de lo urgente y no pierde nada. Ese salto —de un problema real contado en una frase a un programa que lo resuelve— es exactamente el mismo que acabas de dar tú con tu propio proyecto, esta vez sin que nadie te dijera qué escribir en cada paso.

Un curso de fundamentos cubre los cimientos, y los cimientos no son el edificio. Esto es lo que existe ahí fuera, para qué sirve cada cosa y cuándo tiene sentido meterse:

Para que la recomendación sobre bases de datos no quede en abstracto, mira la misma consulta —«los gastos de comida de agosto de más de 50 euros»— con lo que sabes hoy y con SQL:

Con 200 movimientos, la primera versión es perfecta y más simple. Con 200.000, la primera carga todo el fichero en memoria y recorre cada elemento, mientras que la segunda usa índices y devuelve el resultado sin que tu programa vea el resto. Ese es el momento exacto en el que toca aprender SQL: cuando el problema aparece, no antes.

Dos consejos sobre esta tabla. El primero: no la conviertas en una lista de tareas. Intentar aprender los siete temas seguidos es la forma más rápida de no aprender ninguno. El segundo: aprende cada uno cuando un proyecto tuyo lo necesite. Cuando tu programa de gastos se vuelva lento con 20.000 movimientos, SQL dejará de ser una asignatura y será la solución a tu problema, y entonces se aprende en un fin de semana lo que de otro modo cuesta un mes.

Con lo que sabes hoy ya puedes empezar cualquiera de estos caminos. Ninguno es mejor; dependen de qué tipo de problema te apetece resolver. Todos comparten el mismo tronco —el que acabas de recorrer— y se separan después:

Las expectativas de la última columna son honestas, no motivacionales:

Y una nota que ningún catálogo de cursos te dará: la automatización es el camino con mejor relación entre esfuerzo y utilidad inmediata. Si trabajas en algo que no es programación, un script que te ahorre dos horas semanales de trabajo repetitivo te da resultados el primer mes, te da algo real que enseñar y te mantiene programando. Los caminos largos se recorren mucho mejor cuando por el camino hay recompensas.

La regla que resume todo lo demás: se aprende construyendo. Leer sobre programación y programar se parecen tanto como leer sobre natación y nadar. Un curso, un libro o un vídeo sirven para saber que algo existe y cómo se usa; el conocimiento se fija cuando lo aplicas a un problema que no venía resuelto.

Proyectos siguientes, de dificultad creciente. Elige el siguiente escalón, no el edificio entero:

Retos de programación. Plataformas como Exercism, Codewars o Advent of Code te dan problemas cerrados con solución verificable. Son un excelente gimnasio para algoritmos y estructuras de datos, y un mal sustituto de los proyectos: entrenan resolver problemas de veinte líneas, no construir sistemas. Media hora dos o tres veces por semana está bien; vivir ahí, no.

Leer código ajeno. Es la habilidad más infravalorada y la que más practicarás en un trabajo real, donde el 80 % del tiempo se lee código que no escribiste tú. Empieza por proyectos pequeños, con este recorrido y estas preguntas:

Media hora con ese recorrido sobre dos o tres proyectos te da más criterio de estructura que varios tutoriales, porque ves decisiones reales tomadas por gente con más oficio.

Contribuir a proyectos libres. Suena inalcanzable y no lo es. La vía de entrada real no es arreglar un error complejo, sino esta secuencia:

1. Usa una herramienta libre pequeña que ya te resulte útil.
2. Encuentra algo que no funciona, o que la documentación no explica bien.
3. Busca en su repositorio las incidencias etiquetadas good first issue, que existen exactamente para quien llega nuevo.
4. Lee su guía de contribución (CONTRIBUTING.md) y respeta su estilo, aunque no sea el tuyo.
5. Propón un cambio pequeño y bien explicado, y acepta la revisión que te hagan.

La primera contribución aceptada enseña más sobre trabajo en equipo —revisiones, estilo del proyecto, discusión técnica— que cualquier curso.

Estudiar la documentación oficial. Es una habilidad que se entrena, no un castigo. La documentación de Python tiene tres partes que conviene distinguir: el Tutorial (para aprender algo nuevo), la Library Reference (para consultar qué hace exactamente una función) y los HOWTO (guías temáticas excelentes, como el de expresiones regulares o el de logging). Acostúmbrate a buscar primero ahí y después en foros; los foros te dan una receta, la documentación te da el modelo.

Estos cinco hábitos ya los has practicado en el curso. Lo que decide tu progreso no es aprenderlos otra vez, es no abandonarlos cuando nadie te los pida:

• Versiona todo desde el primer minuto. git init es la primera orden de cualquier proyecto, aunque sea un script de treinta líneas y aunque no lo vayas a compartir. El coste es cero y evita la carpeta de version_final_2_buena.
• Prueba lo que importa. No hace falta cubrirlo todo: prueba los cálculos, las reglas del dominio y la persistencia. Es lo que te permite cambiar código sin miedo, y sin esa confianza los proyectos se paralizan.
• Escribe para quien viene detrás, que casi siempre eres tú dentro de tres meses. Nombres claros, funciones cortas, un README que explique el porqué. El código se escribe una vez y se lee muchas.
• Mide antes de optimizar. La intuición sobre el rendimiento es mala casi siempre. Mide, localiza el punto lento real y optimiza solo eso (06-04). El resto del tiempo, prioriza la claridad.
• Termina lo que empiezas. Es el hábito más difícil y el que más te va a diferenciar. Un proyecto acabado, aunque sea modesto, enseña y demuestra; diez a medias no hacen ninguna de las dos cosas.

Los asistentes de IA forman parte del trabajo y no tiene sentido fingir lo contrario. La pregunta útil no es si usarlos, sino cómo usarlos para que sumen sin impedir que aprendas. La diferencia está en si el asistente hace el trabajo por ti o contigo:

La diferencia se ve en cómo formulas la petición. Compara:

La segunda pregunta parte de tu código, describe el comportamiento observado y pide una explicación, no una sustitución. Es la diferencia entre salir con una función y salir entendiendo por qué sorted ordena por el segundo elemento de la tupla.

Tres reglas prácticas que funcionan bien:

1. Intenta el problema veinte minutos antes de preguntar. El aprendizaje ocurre durante el intento, no en la respuesta. Preguntar después de intentarlo es investigación; preguntar antes es dependencia.
2. No pegues nunca código que no sabrías reescribir. No por pureza, sino por consecuencias prácticas: cuando falle en producción, o cuando te lo pregunten en una entrevista, tendrás que entenderlo igualmente.
3. Verifica siempre. Los asistentes se equivocan con seguridad aparente: inventan funciones que no existen, usan APIs obsoletas y cometen errores sutiles de lógica. Tus pruebas automatizadas y la documentación oficial son el filtro.

La habilidad que de verdad importa —y que los asistentes no sustituyen— es saber qué construir, cómo estructurarlo y cómo comprobar que funciona. Eso es justamente lo que has practicado en este módulo.

Cuatro patrones que descarrilan a mucha gente en el año siguiente a un primer curso, con su antídoto concreto:

Un quinto, menos comentado y muy común: estudiar sin aplicar durante meses esperando estar «preparado» para hacer algo real. No existe ese momento. Se está preparado en cuanto se empieza; el resto se aprende por el camino, exactamente como acabas de hacer con tu proyecto.

Un plan concreto vale más que cualquier lista de recursos. Este supone entre cinco y ocho horas semanales, que es lo que se puede sostener compaginándolo con otras cosas. Adáptalo, pero conserva la estructura: siempre hay un proyecto en marcha, y el estudio está al servicio del proyecto.

Cuatro reglas para que el plan sobreviva:

• Franjas fijas en el calendario. «Cuando pueda» significa nunca. Dos tardes y un rato el fin de semana funcionan mejor que cinco horas seguidas un domingo.
• Sesiones cortas y frecuentes ganan a maratones espaciados: la memoria funciona así, y los maratones dejan el código a medias.
• Termina cada sesión con algo commiteado y una nota de por dónde ibas (09-03). Retomar es lo que más tiempo consume.
• Revisa el plan cada mes. Si algo no encaja con tu vida real, cámbialo; un plan abandonado no enseña nada.

• Confundir «terminar un curso» con «haber terminado». Este curso son los cimientos. La programación se aprende durante años y siempre en obra; eso no es una mala noticia, es la parte interesante del oficio.
• Elegir camino por lo que está de moda. Las modas cambian cada dos años y el interés propio no. Elige por el tipo de problema que te apetece resolver: si no te interesa, no aguantarás la curva.
• Esperar a «estar preparado». Nadie se siente preparado nunca. El síndrome del impostor acompaña también a los veteranos; se convive con él, no se cura estudiando más.
• Aprender teoría sin proyecto. Un tema estudiado sin aplicarlo se olvida en semanas. Cada cosa nueva debe entrar en algo que estés construyendo.
• Medir el progreso en horas de vídeo. El progreso se mide en problemas resueltos y proyectos publicados, no en tutoriales consumidos.
• Consejo: guarda un registro de aprendizaje. Un fichero donde apuntes, cada semana, qué hiciste y qué te costó. En seis meses será la prueba de tu avance el día que te parezca que no avanzas.
• Consejo: busca gente. Una comunidad, un grupo local, alguien con quien comentar lo que haces. Programar solo mucho tiempo se hace cuesta arriba, y la mayor parte de lo que se aprende después de un curso se aprende hablando con otros.
• Consejo: vuelve a este material cuando lo necesites. Nadie recuerda la sintaxis de sorted con key ni el orden de los argumentos de open. Buscarlo no es un fallo: es el trabajo normal.

Los tres últimos ejercicios del curso no son de código: son de dirección. Hazlos por escrito, en un fichero que puedas releer dentro de unos meses.

Recorre la tabla del apartado 1 y puntúa de 1 a 3 tu dominio real de cada módulo (1: lo reconozco pero no lo aplicaría solo; 2: lo aplico consultando; 3: lo aplico con soltura). Para cada módulo con un 1, escribe una tarea concreta que lo subiría a 2, en menos de dos horas de trabajo. Añade una lista de las cinco cosas que sabes hacer hoy y no sabías hace nueve módulos, con el ejemplo del proyecto que lo demuestra.

Con la tabla del apartado 4, elige un camino y escribe medio folio justificando por qué: qué tipo de problemas resuelve, por qué te interesan a ti, qué expectativa temporal aceptas y qué tres cosas concretas tendrías que aprender primero. Después define tu siguiente proyecto con el documento de definición de 09-01 —problema, MoSCoW y cinco requisitos—, eligiendo el nivel del apartado 5 que te toque.

Adapta la tabla del apartado 9 a tu disponibilidad real: escribe las horas semanales de las que dispones de verdad (no las que te gustaría), las franjas concretas del calendario y el resultado comprobable de cada bloque de dos semanas. Añade una fila de «revisión mensual» y anota la fecha exacta de la primera. Guárdalo donde lo vayas a ver.

Solución 1. No hay solución única, pero sí una forma de comprobar que lo has hecho bien: las cinco cosas de la segunda lista deben poder señalarse en tu proyecto, con fichero y línea. Por ejemplo, «sé separar la lógica de la interfaz» → cuaderno.py no contiene ningún print; «sé escribir pruebas» → tests/test_modelo.py con nueve casos; «sé versionar» → git log con veinte commits y una etiqueta. Si alguna afirmación no tiene evidencia, es una que todavía estás aprendiendo, y eso también es información útil. Rúbrica: ¿cada punto tiene evidencia? ¿Las tareas de los módulos con 1 caben en dos horas y son concretas («escribir tres pruebas parametrizadas», no «repasar pruebas»)?

Solución 2. La justificación bien hecha habla de problemas, no de tecnologías: «me interesa que las herramientas que uso a diario dejen de hacerme perder tiempo, así que empiezo por automatización, y de ahí probablemente al back-end» es una respuesta sólida; «elijo datos porque está bien pagado» no sostiene los seis meses siguientes. Rúbrica: ¿tu justificación menciona el tipo de problema y no solo el nombre del camino? ¿Aceptas la expectativa temporal de la tabla? ¿Tu siguiente proyecto es un escalón, no un salto? ¿Tiene su cajón Won't escrito?

Solución 3. El plan del apartado 9 es la plantilla. Los dos fallos habituales: planificar con las horas ideales en vez de las reales —un plan de quince horas semanales que en realidad son cinco se abandona en la semana tres— y no fijar un resultado comprobable, con lo que es imposible saber si vas bien. Rúbrica: ¿las horas semanales son realistas y están en franjas concretas del calendario? ¿Cada bloque termina en algo verificable (una etiqueta, un script en uso, un repositorio publicado)? ¿Hay siempre un proyecto en marcha, con el estudio a su servicio? ¿Tiene fecha la primera revisión?

Nueve módulos atrás, la primera lección explicaba qué era programar y el primer ejercicio consistía en escribir un print. Hoy sabes convertir un problema en un algoritmo, manejar tipos y validar entradas, decidir y repetir con estructuras de control, descomponer un programa en funciones, elegir la estructura de datos adecuada y guardarla en disco, buscar, ordenar y razonar el coste de lo que escribes, diseñar clases y organizar un paquete, y trabajar como se trabaja de verdad: documentando, depurando, versionando, probando y refactorizando. Y por encima de todo eso, sabes llevar un proyecto propio de la idea a la versión publicada, que es la habilidad que nadie te puede enseñar en una lección porque solo se adquiere haciéndolo entero una vez. Ya la has hecho.

Lo que queda por delante es un mapa, no una lista de deberes: bases de datos, web, interfaces gráficas, concurrencia, estructuras avanzadas, expresiones regulares y POO avanzada, cada cosa a su tiempo y siempre cuando un proyecto tuyo la necesite. Los caminos —web, datos, automatización, móvil, sistemas— se eligen por el tipo de problema que te apetece resolver, no por la moda del año, y todos arrancan desde donde estás ahora. Se avanza construyendo: el siguiente escalón, siempre uno solo, con retos y lectura de código ajeno como gimnasio y la documentación oficial como fuente. Se sostiene con hábitos —versionar todo, probar lo que importa, escribir para quien viene detrás, medir antes de optimizar y terminar lo que se empieza— y se protege de los cuatro descarrilamientos clásicos: saltar de tecnología en tecnología, el tutorial hell, compararse con veteranos y no acabar nada. Los asistentes de IA acompañan bien si los usas para entender, revisar y explorar alternativas, y mal si les delegas el trabajo que es tu aprendizaje. Y para que nada de esto se quede en intención, ahí está el plan de tres meses con franjas fijas, sesiones cortas y un resultado comprobable cada quincena.

En Estudio Alba, Marta sigue coordinando a Luis y a Nuria, la Panadería Solé sigue pidiendo cambios de última hora y la feria del libro vuelve cada año. TareaFácil pasó de tres print a un paquete con pruebas en verde porque alguien decidió, un día, resolver un problema pequeño y concreto y luego no lo abandonó. Tu proyecto tiene ahora la misma historia y es enteramente tuyo: la idea, el diseño, cada decisión y cada fallo que arreglaste a las once de la noche. Eso —elegir un problema, entenderlo, construir la solución y terminarla— es programar, y ya lo has hecho una vez. Todo lo que venga a partir de ahora es la misma operación con más herramientas. Gracias por llegar hasta aquí, y que el siguiente proyecto sea mejor que este.