Tu proyecto funciona, está probado y vive en un repositorio ordenado: Implementación y pruebas cerró la checklist de «terminado». Queda una parte que quien empieza suele considerar accesoria y que en la práctica decide cuánto vale tu trabajo para los demás: saber enseñarlo. Un proyecto que nadie sabe instalar, que no se entiende sin ti al lado o cuyas decisiones no sabes justificar es, para efectos prácticos, un proyecto que no existe. Esta lección convierte tu carpeta de código en algo presentable: un repositorio limpio, un README que hace el trabajo por ti, una demostración de cinco minutos que no depende de la suerte, y las respuestas preparadas para las preguntas que te van a hacer —incluida la más incómoda, la de las limitaciones—.

1. Dejar el repositorio presentable
2. El README como carta de presentación
3. La demostración de cinco minutos
4. Explicar decisiones técnicas
5. Hablar de las limitaciones sin restarte valor
6. Preguntas típicas y cómo responderlas
7. Recibir crítica y convertirla en tareas
8. Publicar el proyecto
9. Autoevaluación final y plan de mejora
10. Errores comunes y consejos
11. Ejercicios
12. Conclusión

Quien mire tu proyecto verá primero el repositorio, no el programa. Y la primera impresión se juega en treinta segundos: si hay un README.md que explica qué es esto y hay ficheros con nombres razonables, sigue leyendo; si ve una carpeta con prueba2.py, datos_final_final.json y ningún texto, cierra la pestaña.

Recorre esta checklist entera antes de enseñárselo a nadie, retomando Documentación y comentarios y Control de versiones:

Sobre el punto 4, una advertencia seria: borrar un fichero con una contraseña en un commit posterior no lo elimina del historial; sigue ahí y cualquiera puede recuperarlo. Si te ha pasado, la respuesta correcta no es maquillarlo sino invalidar esa credencial y, si el repositorio no es público todavía, rehacerlo desde cero. En un proyecto de este curso lo normal es que no haya credenciales, pero sí datos personales reales: los tuyos, en el fichero de gastos o en la agenda de contactos. Esos no se suben.

Y el cierre del trabajo, retomando el versionado semántico de 08-01:

El README es el documento más rentable de tu proyecto: se escribe en una hora y es lo que leerá el 100 % de quienes lo miren. Esta es la estructura, en orden, con el porqué de cada sección:

Un extracto comentado del README de MisGastos:

Los dos últimos apartados llevan bloques de código con los comandos literales, que son estos:

Fíjate en tres decisiones. La descripción menciona el problema antes que la solución: quien lee entiende para qué sirve antes de saber cómo funciona. Las características están en infinitivo o sustantivo, no en «podrás hacer...». Y la instalación son comandos copiables en orden, sin prosa entre ellos: quien evalúa tu proyecto quiere pegarlos y que funcionen.

La parte que más convence, y la que casi nadie incluye, es una demostración en texto de una sesión real. Vale más que cualquier descripción, porque enseña el programa funcionando sin instalarlo:

Cómo se hace: ejecuta el programa con tus datos de ejemplo, copia la salida literal de la terminal y pégala en un bloque ```text. Nada de recrearla a mano —se nota, y además suele quedar desalineada—. Si prefieres capturas de pantalla, súbelas a una carpeta docs/ del repositorio y enlázalas con ![Resumen mensual](docs/resumen.png); pero el texto tiene una ventaja: se busca, se copia y no se rompe.

Antes o después tendrás que enseñar el proyecto en directo: en clase, en una entrevista o a alguien que te preguntó qué estabas haciendo. Cinco minutos parecen pocos y son muchos si no llevas guion, porque el impulso natural es empezar por el código y perderse en detalles.

Este es el guion, y el reparto de tiempo importa tanto como el contenido:

Sobre el bloque 3, que es el que se puede torcer: prepara los datos de antemano. Ten un datos_demo.json con quince o veinte movimientos repartidos en dos meses, copiado al sitio justo antes de empezar. Nunca hagas una demo con la base vacía: registrar cinco gastos en directo consume tus dos minutos y no enseña nada. Y ensaya la secuencia exacta de teclas al menos dos veces; el objetivo es que puedas hablar mientras las tecleas, no leer la pantalla.

¿Y si algo falla durante la demo? Falla, tarde o temprano. Lo que se juzga no es el fallo, es la reacción:

• No lo escondas ni lo minimices. «Ahí hay un fallo, no había probado esta combinación» es una respuesta profesional. Fingir que no ha pasado, no.
• No te pongas a depurar en directo. Consume el tiempo de todos y rara vez sale bien. Anótalo y sigue.
• Ten un plan B: una captura o una sesión grabada en texto en el README con la que continuar explicando.
• Convierte el fallo en información. «Es un caso que no está en mi guion de pruebas; lo añado» demuestra que tienes método, que es justamente lo que se está evaluando.

Todo lo que hay en tu código es el resultado de una decisión, y la pregunta «¿por qué lo hiciste así?» no es un ataque: es la forma estándar de averiguar si entiendes lo que has hecho. Una buena respuesta tiene tres partes: qué elegiste, qué alternativa descartaste y con qué criterio. Tres ejemplos reales sobre MisGastos:

«¿Por qué una clase Movimiento y no un diccionario?» Empecé con diccionarios, que es lo más rápido. El problema apareció con la validación: cada sitio que creaba un movimiento tenía que comprobar que el importe no fuera cero y que la categoría existiera, y me olvidé en uno. Con una clase, la validación está en __post_init__ y no puede existir un movimiento inválido en el programa. Además __str__ me da la línea de tabla ya formateada. Si solo fuera un contenedor de datos sin reglas, habría dejado el diccionario.

«¿Por qué JSON y no CSV, si son registros planos?» Por los tipos. En CSV todo vuelve como cadena y tendría que reconvertir importes y fechas al leer, con el riesgo de fallar en silencio. JSON conserva los números y me deja añadir campos opcionales sin romper los ficheros antiguos, para lo que además guardo un número de versión. CSV sí lo uso, pero solo como exportación de un sentido, que es donde tiene ventaja: abrir el mes en la hoja de cálculo.

«¿Por qué separaste la interfaz de la lógica, si es un programa pequeño?» Sobre todo para poder probarlo. Los cálculos del resumen están en Cuaderno, que no imprime nada, así que puedo verificarlos con pytest en centésimas de segundo; si estuvieran mezclados con los print tendría que simular la pantalla para probarlos. El efecto secundario es que cambiar el formato de una pantalla no puede romper un cálculo, porque viven en ficheros distintos.

El patrón se ve en los tres: contexto, alternativa, criterio, consecuencia. Y algo igual de importante: si una decisión la tomaste sin pensar, dilo. «Lo hice así porque era lo que sabía hacer, y ahora que lo miro habría sido mejor...» es una respuesta que suma, porque demuestra criterio adquirido. La respuesta que resta es inventarse una justificación que no sostienes en la repregunta.

Todo proyecto tiene carencias, y el tuyo, que es el primero, tiene bastantes. La diferencia entre parecer un principiante que no sabe y un profesional que empieza está entera en cómo se cuentan. El patrón tiene tres tiempos:

«Lo sé → lo dejé fuera a propósito → así lo haría»

Aplicado:

Las tres versiones de la derecha comparten algo: convierten una carencia en una decisión y proponen el camino. Eso solo es posible si de verdad tomaste la decisión, y por eso el cajón Won't de Definición del proyecto era tan importante: ahora es tu guion.

Dos cosas que no debes hacer nunca: disculparte en bucle («perdón, sé que está muy mal hecho, es que soy principiante»), que invita a mirar el proyecto con desconfianza y no aporta información; e inventar limitaciones que no tienes para parecer humilde. Di lo que es.

Estas preguntas salen casi siempre. Prepáralas por escrito; responder bien una pregunta previsible es de las cosas que más diferencian una presentación de otra:

Sobre la de la IA: la respuesta honesta siempre es mejor. «La usé para entender un TypeError que no sabía leer y para que me revisara el almacen.py; el diseño y el código son míos» es una respuesta profesional y verificable —porque si el código es tuyo, sabrás explicarlo—.

Cuando enseñas tu proyecto recibes comentarios, y la reacción instintiva es defenderse. Es un error: la crítica de alguien que se ha molestado en mirar tu código es de las cosas más valiosas que vas a recibir gratis. El procedimiento:

1. Escucha entera la observación sin interrumpir y sin justificarte todavía.
2. Anótala literal. No la interpretes en el momento; ya la interpretarás en frío.
3. Pregunta si no la entiendes. «¿A qué te refieres con que el módulo hace demasiadas cosas?» es una pregunta legítima y demuestra interés.
4. Agradece. Aunque no estés de acuerdo. El coste de escuchar es cero.
5. En frío, clasifícala en una de estas cuatro cajas.

La cuarta caja es donde más se sufre si no la tienes clara: hay comentarios que describen otro proyecto, no el tuyo. Y la primera es la más valiosa de todas: quien encuentra un fallo en tu programa te está haciendo un favor, aunque no lo parezca en ese momento. Convierte cada comentario de las dos primeras cajas en una línea de tu lista de tareas, con su prioridad; de eso sale el plan de mejora del apartado 9.

Un proyecto en tu disco duro no le sirve a nadie, empezando por ti. Publicarlo cuesta veinte minutos:

Después, dedica un rato a la página del repositorio, que es tu escaparate:

• Descripción corta (el campo About): una frase con lo que hace y en qué está escrito. «Gestor de gastos personales por línea de comandos en Python, con persistencia en JSON y pruebas con pytest».
• Temas (topics): python, cli, json, pytest, learning-project. Ayudan a que aparezca en las búsquedas.
• README bien renderizado: míralo en GitHub, no solo en el editor. Comprueba que las tablas se ven y que los bloques de código tienen su lenguaje.
• Licencia: si quieres que otros lo usen, añade una MIT; sin licencia, técnicamente nadie puede reutilizarlo.

Sobre el portfolio: dos o tres proyectos terminados, explicados y con historial de commits valen más que veinte repositorios a medias. Quien evalúa mira si el proyecto está acabado, si el README explica el porqué, si hay pruebas y si los commits cuentan una historia coherente. Un proyecto pequeño y completo comunica «esta persona termina las cosas», que es exactamente la señal que se busca.

Y una práctica que enseña más de lo que parece: mirar proyectos ajenos. Busca en GitHub una aplicación de línea de comandos en Python con pocas estrellas —los proyectos enormes son ilegibles al principio— y examina, en este orden: el README (¿entiendes qué hace en un minuto?), la estructura de ficheros (¿reconoces las capas?), un módulo cualquiera (¿cómo nombran las funciones?), los tests (¿qué prueban?) y el historial (¿cómo escriben los mensajes?). Media hora haciendo esto te da referencias que ningún tutorial te da.

Ha llegado el momento de usar la rúbrica que escribiste en 09-01, cuando aún no sabías cómo iba a salir el proyecto. Rellénala con honestidad —la única persona a la que engañarías es a ti— y multiplica cada puntuación por su peso:

La columna de la derecha es la que hace útil el ejercicio: obliga a justificar la nota con una evidencia, no con una impresión. Un 3 en pruebas significa poder decir «once pruebas que cubren modelo, agregación y ciclo guardar/cargar», no «creo que están bien».

Con la rúbrica rellena, el plan de mejora sale solo: ordena por peso descendente los criterios con nota más baja. Ejemplo de MisGastos, que salió con 2,85 de media:

Siete horas de trabajo que suben la media a un 3,4. Y observa el orden: primero lo barato que arregla una nota baja, después lo caro. Añadir una función nueva es lo más divertido y casi nunca es lo que más mejora el proyecto.

• Enseñar el código antes que el problema. Nadie puede valorar una solución si no sabe qué problema resuelve. Treinta segundos de contexto primero, siempre.
• README de tres líneas. «Proyecto final del curso de Python» no dice nada. Si solo tienes una hora para pulir el proyecto, inviértela entera aquí: es lo que más multiplica.
• Demo sin datos preparados. Registrar registros en directo consume el tiempo y aburre. Ten un fichero de demo listo y ensayado.
• Disculparse todo el rato. Rebaja el valor de lo que has hecho y no aporta información. Usa el patrón «lo sé, fue a propósito, así lo haría».
• Defenderse de la crítica. Escuchar es gratis y decidir es tuyo. Anota, agradece, clasifica en frío.
• Subir datos personales. Revisa el repositorio antes de hacerlo público: el fichero de datos reales no se sube, y borrarlo después no lo quita del historial.
• Consejo: cuenta el proyecto en voz alta a alguien que no programe. Si consigues que entienda qué hace y por qué, tienes la presentación resuelta.
• Consejo: escribe tu guion de cinco minutos y cronométralo. Casi siempre son ocho la primera vez, y lo que sobra es el bloque técnico.

Los últimos pasos reales de tu proyecto. Al terminarlos, está entregado.

Recorre la checklist del apartado 1 punto por punto y arregla lo que falle, incluida la comprobación de clonar en una carpeta nueva. Después escribe tu README.md completo con las diez secciones del apartado 2, incluyendo una demostración en texto de una sesión real copiada literalmente de tu terminal. Crea la etiqueta v1.0 y súbela.

Escribe tu guion de cinco minutos siguiendo la tabla del apartado 3, con el tiempo asignado a cada bloque y los datos de demo preparados en un fichero aparte. Ensáyalo cronometrado dos veces. Después redacta por escrito tres decisiones técnicas de tu proyecto con el patrón contexto-alternativa-criterio-consecuencia, y tres limitaciones con el patrón «lo sé, lo dejé fuera a propósito, así lo haría».

Rellena la rúbrica del apartado 9 con una evidencia concreta por criterio y calcula tu nota ponderada. Construye después el plan de mejora ordenando por peso los criterios con nota más baja, con una acción concreta y una estimación por fila. Finalmente, elige la acción de prioridad 1 y hazla; después vuelve a puntuar ese criterio.

Solución 1. El apartado 2 contiene la estructura y el extracto del README de MisGastos. Los tres fallos más habituales: un README que describe el código en lugar del problema, una sección de instalación con prosa entre los comandos, y ninguna demostración de sesión. Rúbrica de autoevaluación: ¿alguien que no conoce tu proyecto sabría en un minuto qué hace y para quién? ¿Puede instalarlo copiando y pegando, sin preguntarte nada? ¿Hay ejemplo de sesión real? ¿La sección de limitaciones existe y está escrita como decisiones? ¿git tag muestra v1.0?

Solución 2. El apartado 3 tiene el guion con tiempos y el apartado 4 los tres ejemplos de decisión bien argumentada —clase frente a diccionario, JSON frente a CSV, separación de capas— con la estructura contexto, alternativa, criterio y consecuencia. El apartado 5 hace lo propio con las limitaciones. Rúbrica: ¿tu guion dedica los primeros 60 segundos al problema y a la solución, sin mencionar tecnología? ¿La demo es de un flujo real con datos ya cargados? ¿Cada decisión menciona la alternativa que descartaste? ¿Cada limitación termina proponiendo cómo se resolvería? ¿Cabe en cinco minutos cronometrados?

Solución 3. El apartado 9 tiene la rúbrica y el plan de mejora de MisGastos, con su nota de 2,85 y las cuatro acciones ordenadas por peso. Lo que suele fallar en este ejercicio es la generosidad: si te pones un 4 en pruebas con tres pruebas sueltas, la rúbrica deja de servir para nada. Rúbrica de la rúbrica: ¿cada nota tiene una evidencia concreta y numérica al lado? ¿Tu plan está ordenado por peso del criterio, no por lo que te apetece hacer? ¿Cada acción cabe en tres horas? ¿Has hecho ya la primera?

Un proyecto que no se sabe explicar no cuenta, y explicarlo empieza por el repositorio: README completo, requirements.txt, .gitignore, cero datos personales o credenciales, sin ficheros temporales, historial legible, todo commiteado, etiqueta v1.0 y la comprobación definitiva de clonar en una carpeta nueva y arrancar. El README es el documento más rentable que escribirás: diez secciones en orden —título y frase, descripción del problema antes que de la solución, características, requisitos, instalación en comandos copiables, uso con demostración en texto de una sesión real, estructura, pruebas, limitaciones y autoría— y se escribe en una hora.

La demostración de cinco minutos tiene guion y reparto de tiempos: treinta segundos de problema, treinta de solución, dos minutos de demo del flujo principal con datos preparados de antemano y ensayados, un minuto de detalle técnico del que estés orgulloso y un minuto de limitaciones y siguientes pasos; y si algo falla, se reconoce, se anota y se sigue, sin depurar en directo. Las decisiones técnicas se defienden con el patrón contexto, alternativa descartada, criterio y consecuencia —por qué una clase y no un diccionario, por qué JSON y no CSV, por qué separar la interfaz de la lógica—, y las limitaciones con el patrón «lo sé, lo dejé fuera a propósito, así lo haría», que convierte cada carencia en una decisión y por el que el cajón Won't de 09-01 se vuelve tu guion. Las preguntas típicas se preparan por escrito, la de la IA incluida, donde la respuesta honesta siempre gana. La crítica se escucha entera, se anota literal, se agradece y en frío se clasifica en error real, mejora acertada, preferencia personal o fuera de alcance; las dos primeras se convierten en tareas. Y el proyecto se publica: repositorio en GitHub con descripción, temas y licencia, con la idea de que dos o tres proyectos terminados valen más que veinte a medias, y con el hábito de leer código ajeno para tener referencias. La autoevaluación cierra el círculo con la rúbrica de 09-01, exigiendo una evidencia concreta por criterio, y el plan de mejora ordena por peso lo que más sube la nota.

Con esto, el proyecto está hecho, terminado, defendido y publicado —que es exactamente lo que se propuso al abrir el módulo—. Queda una última conversación, y no es técnica: qué hacer a partir de ahora. En Siguientes pasos como programador recorreremos lo aprendido en estos nueve módulos, lo que este curso no cubrió y conviene saber que existe, los caminos profesionales que se abren con lo que ya sabes, los hábitos que conviene consolidar y un plan concreto para los próximos tres meses.