El teu projecte està acabat, documentat, defensat i publicat: Presentació del projecte va tancar l'última tasca pendent. Aquesta lliçó no ensenya sintaxi nova ni afegeix res al projecte; serveix per al que ve després, que és una pregunta legítima i bastant angoixant quan s'acaba un curs: i ara què? La respondrem en quatre temps. Primer, un balanç honest del que saps fer avui i no sabies fa nou mòduls. Segon, el mapa del que existeix aquí fora i aquest curs no va cobrir, perquè sàpigues què hi ha i per a què serveix. Tercer, els camins professionals que s'obren des d'on ets, amb expectatives realistes. I quart, un pla concret de tres mesos, perquè la diferència entre qui continua programant d'aquí a un any i qui ho deixa no és el talent: és tenir la següent cosa a fer.

1. El camí recorregut
2. TascaFàcil, de la v0.1 a la v1.0
3. El que aquest curs no va cobrir
4. Triar un camí
5. Com continuar aprenent
6. Hàbits professionals que convé consolidar
7. Treballar amb assistents d'IA
8. Errors freqüents de qui comença
9. Un pla per als propers tres mesos
10. Errors comuns i consells
11. Exercicis
12. Conclusió

Vas començar sense saber què era una variable. Aquest és l'inventari, mòdul a mòdul, del que saps fer ara; llegeix-lo a poc a poc, perquè la sensació normal en acabar un curs és la de no saber res, i això no és el que diu la taula:

Aquesta última fila és la que més pesa. Hi ha molta gent que coneix la sintaxi de Python; n'hi ha bastanta menys que hagi portat un projecte propi de la idea a la v1.0 publicada. El primer s'aprèn en unes setmanes; el segon és el que cal per treballar.

Si necessites una prova tangible del camí, allà tens TascaFàcil. Va començar sent tres print i una llista, i va acabar sent un paquet instal·lable amb proves. La seva història és la del curs:

La distància es veu millor comparant la mateixa idea escrita al principi i al final. Així es llistaven les tasques a la v0.1:

I així a la v1.0:

Entre els dos fragments hi ha nou mòduls: funcions amb paràmetres i valors per defecte, anotacions de tipus, docstring, una classe que encapsula la col·lecció, filtratge i ordenació per criteri, el cas de llista buida previst i __str__ fent el format. Però la diferència important no és la sintaxi, sinó que el segon funciona amb tres tasques i amb tres-centes, i que es pot provar, canviar i ampliar sense reescriure'l.

La Marta, en Luis i la Nuria van començar amb una llibreta on apuntaven qui feia què per al Forn Solé i van acabar amb una eina que reparteix la feina de l'estudi, avisa del que és urgent i no perd res. Aquest salt —d'un problema real explicat en una frase a un programa que el resol— és exactament el mateix que acabes de fer tu amb el teu propi projecte, aquesta vegada sense que ningú et digués què escriure a cada pas.

Un curs de fonaments cobreix els fonaments, i els fonaments no són l'edifici. Això és el que existeix aquí fora, per a què serveix cada cosa i quan té sentit ficar-s'hi:

Perquè la recomanació sobre bases de dades no quedi en abstracte, mira la mateixa consulta —«les despeses de menjar d'agost de més de 50 euros»— amb el que saps avui i amb SQL:

Amb 200 moviments, la primera versió és perfecta i més simple. Amb 200.000, la primera carrega tot el fitxer en memòria i recorre cada element, mentre que la segona fa servir índexs i retorna el resultat sense que el teu programa vegi la resta. Aquest és el moment exacte en què toca aprendre SQL: quan el problema apareix, no abans.

Dos consells sobre aquesta taula. El primer: no la converteixis en una llista de tasques. Intentar aprendre els set temes seguits és la manera més ràpida de no aprendre'n cap. El segon: aprèn cadascun quan un projecte teu ho necessiti. Quan el teu programa de despeses es torni lent amb 20.000 moviments, SQL deixarà de ser una assignatura i serà la solució al teu problema, i aleshores s'aprèn en un cap de setmana el que d'altra manera costa un mes.

Amb el que saps avui ja pots començar qualsevol d'aquests camins. Cap no és millor; depenen de quin tipus de problema et ve de gust resoldre. Tots comparteixen el mateix tronc —el que acabes de recórrer— i se separen després:

Les expectatives de l'última columna són honestes, no motivacionals:

I una nota que cap catàleg de cursos no et donarà: l'automatització és el camí amb millor relació entre esforç i utilitat immediata. Si treballes en alguna cosa que no és programació, un script que t'estalviï dues hores setmanals de feina repetitiva et dóna resultats el primer mes, et dóna alguna cosa real per ensenyar i et manté programant. Els camins llargs es recorren molt millor quan pel camí hi ha recompenses.

La regla que resumeix tota la resta: s'aprèn construint. Llegir sobre programació i programar s'assemblen tant com llegir sobre natació i nedar. Un curs, un llibre o un vídeo serveixen per saber que alguna cosa existeix i com es fa servir; el coneixement es fixa quan l'apliques a un problema que no venia resolt.

Projectes següents, de dificultat creixent. Tria el següent esglaó, no l'edifici sencer:

Reptes de programació. Plataformes com Exercism, Codewars o Advent of Code et donen problemes tancats amb solució verificable. Són un gimnàs excel·lent per a algorismes i estructures de dades, i un mal substitut dels projectes: entrenen a resoldre problemes de vint línies, no a construir sistemes. Mitja hora dues o tres vegades per setmana està bé; viure-hi, no.

Llegir codi aliè. És l'habilitat més infravalorada i la que més practicaràs en una feina real, on el 80 % del temps es llegeix codi que no vas escriure tu. Comença per projectes petits, amb aquest recorregut i aquestes preguntes:

Mitja hora amb aquest recorregut sobre dos o tres projectes et dóna més criteri d'estructura que uns quants tutorials, perquè veus decisions reals preses per gent amb més ofici.

Contribuir a projectes lliures. Sona inabastable i no ho és. La via d'entrada real no és arreglar un error complex, sinó aquesta seqüència:

1. Fes servir una eina lliure petita que ja et resulti útil.
2. Troba alguna cosa que no funciona, o que la documentació no explica bé.
3. Busca al seu repositori les incidències etiquetades good first issue, que existeixen exactament per a qui hi arriba nou.
4. Llegeix la seva guia de contribució (CONTRIBUTING.md) i respecta el seu estil, encara que no sigui el teu.
5. Proposa un canvi petit i ben explicat, i accepta la revisió que et facin.

La primera contribució acceptada ensenya més sobre treball en equip —revisions, estil del projecte, discussió tècnica— que qualsevol curs.

Estudiar la documentació oficial. És una habilitat que s'entrena, no un càstig. La documentació de Python té tres parts que convé distingir: el Tutorial (per aprendre alguna cosa nova), la Library Reference (per consultar què fa exactament una funció) i els HOWTO (guies temàtiques excel·lents, com el d'expressions regulars o el de logging). Acostuma't a buscar primer allà i després als fòrums; els fòrums et donen una recepta, la documentació et dóna el model.

Aquests cinc hàbits ja els has practicat al curs. El que decideix el teu progrés no és aprendre'ls una altra vegada, és no abandonar-los quan ningú no te'ls demani:

• Versiona-ho tot des del primer minut. git init és la primera ordre de qualsevol projecte, encara que sigui un script de trenta línies i encara que no el compartiràs. El cost és zero i evita la carpeta de versio_final_2_bona.
• Prova el que importa. No cal cobrir-ho tot: prova els càlculs, les regles del domini i la persistència. És el que et permet canviar codi sense por, i sense aquesta confiança els projectes es paralitzen.
• Escriu per a qui ve al darrere, que gairebé sempre ets tu d'aquí a tres mesos. Noms clars, funcions curtes, un README que expliqui el perquè. El codi s'escriu una vegada i es llegeix moltes.
• Mesura abans d'optimitzar. La intuïció sobre el rendiment és dolenta gairebé sempre. Mesura, localitza el punt lent real i optimitza només això (06-04). La resta del temps, prioritza la claredat.
• Acaba el que comences. És l'hàbit més difícil i el que més et diferenciarà. Un projecte acabat, encara que sigui modest, ensenya i demostra; deu a mitges no fan cap de les dues coses.

Els assistents d'IA formen part de la feina i no té sentit fer veure el contrari. La pregunta útil no és si fer-los servir, sinó com fer-los servir perquè sumin sense impedir que aprenguis. La diferència és si l'assistent fa la feina per tu o amb tu:

La diferència es veu en com formules la petició. Compara:

La segona pregunta parteix del teu codi, descriu el comportament observat i demana una explicació, no una substitució. És la diferència entre sortir-ne amb una funció i sortir-ne entenent per què sorted ordena pel segon element de la tupla.

Tres regles pràctiques que funcionen bé:

1. Intenta el problema vint minuts abans de preguntar. L'aprenentatge passa durant l'intent, no a la resposta. Preguntar després d'intentar-ho és recerca; preguntar abans és dependència.
2. No enganxis mai codi que no sabries reescriure. No per puresa, sinó per conseqüències pràctiques: quan falli en producció, o quan te'l preguntin en una entrevista, l'hauràs d'entendre igualment.
3. Verifica sempre. Els assistents s'equivoquen amb seguretat aparent: inventen funcions que no existeixen, fan servir APIs obsoletes i cometen errors subtils de lògica. Les teves proves automatitzades i la documentació oficial són el filtre.

L'habilitat que de debò importa —i que els assistents no substitueixen— és saber què construir, com estructurar-ho i com comprovar que funciona. Això és justament el que has practicat en aquest mòdul.

Quatre patrons que descarrilen molta gent l'any següent a un primer curs, amb el seu antídot concret:

Un cinquè, menys comentat i molt comú: estudiar sense aplicar durant mesos esperant estar «preparat» per fer alguna cosa real. Aquest moment no existeix. S'està preparat tan bon punt es comença; la resta s'aprèn pel camí, exactament com acabes de fer amb el teu projecte.

Un pla concret val més que qualsevol llista de recursos. Aquest suposa entre cinc i vuit hores setmanals, que és el que es pot sostenir compaginant-ho amb altres coses. Adapta'l, però conserva l'estructura: sempre hi ha un projecte en marxa, i l'estudi està al servei del projecte.

Quatre regles perquè el pla sobrevisqui:

• Franges fixes al calendari. «Quan pugui» vol dir mai. Dues tardes i una estona el cap de setmana funcionen millor que cinc hores seguides un diumenge.
• Sessions curtes i freqüents guanyen a maratons espaiades: la memòria funciona així, i les maratons deixen el codi a mitges.
• Acaba cada sessió amb alguna cosa committejada i una nota de per on anaves (09-03). Reprendre és el que més temps consumeix.
• Revisa el pla cada mes. Si alguna cosa no encaixa amb la teva vida real, canvia-la; un pla abandonat no ensenya res.

• Confondre «acabar un curs» amb «haver acabat». Aquest curs són els fonaments. La programació s'aprèn durant anys i sempre en obres; això no és una mala notícia, és la part interessant de l'ofici.
• Triar camí pel que està de moda. Les modes canvien cada dos anys i l'interès propi no. Tria pel tipus de problema que et ve de gust resoldre: si no t'interessa, no aguantaràs la corba.
• Esperar a «estar preparat». Ningú no se sent preparat mai. La síndrome de l'impostor acompanya també els veterans; s'hi conviu, no es cura estudiant més.
• Aprendre teoria sense projecte. Un tema estudiat sense aplicar-lo s'oblida en setmanes. Cada cosa nova ha d'entrar en alguna cosa que estiguis construint.
• Mesurar el progrés en hores de vídeo. El progrés es mesura en problemes resolts i projectes publicats, no en tutorials consumits.
• Consell: guarda un registre d'aprenentatge. Un fitxer on apuntis, cada setmana, què vas fer i què et va costar. D'aquí a sis mesos serà la prova del teu avenç el dia que et sembli que no avances.
• Consell: busca gent. Una comunitat, un grup local, algú amb qui comentar el que fas. Programar sol molt de temps es fa costa amunt, i la major part del que s'aprèn després d'un curs s'aprèn parlant amb altres.
• Consell: torna a aquest material quan el necessitis. Ningú no recorda la sintaxi de sorted amb key ni l'ordre dels arguments d'open. Buscar-ho no és una fallada: és la feina normal.

Els tres últims exercicis del curs no són de codi: són de direcció. Fes-los per escrit, en un fitxer que puguis rellegir d'aquí a uns mesos.

Recorre la taula de l'apartat 1 i puntua d'1 a 3 el teu domini real de cada mòdul (1: el reconec però no l'aplicaria sol; 2: l'aplico consultant; 3: l'aplico amb soltesa). Per a cada mòdul amb un 1, escriu una tasca concreta que el pujaria a 2, en menys de dues hores de feina. Afegeix una llista de les cinc coses que saps fer avui i no sabies fa nou mòduls, amb l'exemple del projecte que ho demostra.

Amb la taula de l'apartat 4, tria un camí i escriu mig full justificant per què: quin tipus de problemes resol, per què t'interessen a tu, quina expectativa temporal acceptes i quines tres coses concretes hauries d'aprendre primer. Després defineix el teu següent projecte amb el document de definició de 09-01 —problema, MoSCoW i cinc requisits—, triant el nivell de l'apartat 5 que et toqui.

Adapta la taula de l'apartat 9 a la teva disponibilitat real: escriu les hores setmanals de què disposes de debò (no les que t'agradaria), les franges concretes del calendari i el resultat comprovable de cada bloc de dues setmanes. Afegeix una fila de «revisió mensual» i anota la data exacta de la primera. Desa'l on el vegis.

Solució 1. No hi ha solució única, però sí una manera de comprovar que ho has fet bé: les cinc coses de la segona llista han de poder assenyalar-se al teu projecte, amb fitxer i línia. Per exemple, «sé separar la lògica de la interfície» → quadern.py no conté cap print; «sé escriure proves» → tests/test_model.py amb nou casos; «sé versionar» → git log amb vint commits i una etiqueta. Si alguna afirmació no té evidència, és una que encara estàs aprenent, i això també és informació útil. Rúbrica: cada punt té evidència? Les tasques dels mòduls amb 1 caben en dues hores i són concretes («escriure tres proves parametritzades», no «repassar proves»)?

Solució 2. La justificació ben feta parla de problemes, no de tecnologies: «m'interessa que les eines que faig servir cada dia deixin de fer-me perdre temps, així que començo per automatització, i d'allà probablement al back-end» és una resposta sòlida; «trio dades perquè està ben pagat» no sosté els sis mesos següents. Rúbrica: la teva justificació esmenta el tipus de problema i no només el nom del camí? Acceptes l'expectativa temporal de la taula? El teu següent projecte és un esglaó, no un salt? Té el seu calaix Won't escrit?

Solució 3. El pla de l'apartat 9 és la plantilla. Les dues fallades habituals: planificar amb les hores ideals en lloc de les reals —un pla de quinze hores setmanals que en realitat en són cinc s'abandona la setmana tres— i no fixar un resultat comprovable, amb la qual cosa és impossible saber si vas bé. Rúbrica: les hores setmanals són realistes i estan en franges concretes del calendari? Cada bloc acaba en alguna cosa verificable (una etiqueta, un script en ús, un repositori publicat)? Hi ha sempre un projecte en marxa, amb l'estudi al seu servei? Té data la primera revisió?

Nou mòduls enrere, la primera lliçó explicava què era programar i el primer exercici consistia a escriure un print. Avui saps convertir un problema en un algorisme, manejar tipus i validar entrades, decidir i repetir amb estructures de control, descompondre un programa en funcions, triar l'estructura de dades adequada i desar-la al disc, cercar, ordenar i raonar el cost del que escrius, dissenyar classes i organitzar un paquet, i treballar com es treballa de debò: documentant, depurant, versionant, provant i refactoritzant. I per damunt de tot això, saps portar un projecte propi de la idea a la versió publicada, que és l'habilitat que ningú no et pot ensenyar en una lliçó perquè només s'adquireix fent-la sencera una vegada. Ja l'has feta.

El que queda per davant és un mapa, no una llista de deures: bases de dades, web, interfícies gràfiques, concurrència, estructures avançades, expressions regulars i POO avançada, cada cosa al seu temps i sempre quan un projecte teu ho necessiti. Els camins —web, dades, automatització, mòbil, sistemes— es trien pel tipus de problema que et ve de gust resoldre, no per la moda de l'any, i tots arrenquen des d'on ets ara. S'avança construint: el següent esglaó, sempre un de sol, amb reptes i lectura de codi aliè com a gimnàs i la documentació oficial com a font. Se sosté amb hàbits —versionar-ho tot, provar el que importa, escriure per a qui ve al darrere, mesurar abans d'optimitzar i acabar el que es comença— i es protegeix dels quatre descarrilaments clàssics: saltar de tecnologia en tecnologia, el tutorial hell, comparar-se amb veterans i no acabar res. Els assistents d'IA acompanyen bé si els fas servir per entendre, revisar i explorar alternatives, i malament si els delegues la feina que és el teu aprenentatge. I perquè res d'això no quedi en intenció, allà tens el pla de tres mesos amb franges fixes, sessions curtes i un resultat comprovable cada quinzena.

A l'Estudi Alba, la Marta continua coordinant en Luis i la Nuria, el Forn Solé continua demanant canvis d'última hora i la fira del llibre torna cada any. TascaFàcil va passar de tres print a un paquet amb proves en verd perquè algú va decidir, un dia, resoldre un problema petit i concret i després no el va abandonar. El teu projecte té ara la mateixa història i és enterament teu: la idea, el disseny, cada decisió i cada fallada que vas arreglar a les onze de la nit. Això —triar un problema, entendre'l, construir la solució i acabar-la— és programar, i ja ho has fet una vegada. Tot el que vingui a partir d'ara és la mateixa operació amb més eines. Gràcies per arribar fins aquí, i que el següent projecte sigui millor que aquest.