Pubblica qualcosa di piccolo questa settimana

La maggior parte delle persone bloccate in loop di tutorial non ha un problema di competenze. Ha un problema di shipping. Puoi guardare quaranta ore di contenuti Python e comunque bloccarti nel momento in cui ti siedi per costruire qualcosa di tuo, perché i tutorial rimuovono ogni decisione per te. Questa guida è una forcing function: scegli qualcosa di piccolo, finiscilo, mettilo davanti a qualcuno, questa settimana.

Scegli un progetto che puoi finire in un weekend

Il failure mode qui è lo scope. Le persone decidono che il loro primo progetto dovrebbe essere un'app SaaS con auth, billing e una dashboard. È un progetto da sei mesi travestito da uno da weekend.

Invece scegli qualcosa con una sola funzione chiara:

• Uno strumento CLI che rinomina i file in una cartella in base alla data EXIF
• Uno script che scrape un'API pubblica e ti invia un riassunto giornaliero via email
• Un'app Flask con un form e una pagina di output
• Un'estensione del browser che evidenzia una parola chiave su qualsiasi pagina visiti

Scrivi lo scope in una sola frase prima di scrivere qualsiasi codice. Se la frase ha bisogno di "e" più di una volta, tagliane. "Uno strumento che traccia le mie spese e anche le categorizza e anche le mette in un grafico" sono tre progetti. Pubblica il tracker per primo.

Stabilisci una deadline vera e un pubblico vero

Una deadline senza conseguenze non è una deadline. Dillo a un amico, posta in un server Discord, oppure impegnati a dimostrarla a un collega venerdì. Il pubblico ha più importanza della deadline — sapere che qualcuno guarderà davvero il progetto cambia come lo costruisci. Smetti di lucidare l'architettura e inizi a assicurarti che il happy path funzioni davvero.

Datti un numero, non una sensazione. "Ci lavorerò quando ho tempo" non produce nulla. "Due ore stasera, due ore domani, pubblica sabato mattina" produce un progetto.

Costruisci la versione brutta per prima

Salta i dibattiti sulla struttura delle cartelle, salta la scelta di un CSS framework, salta la decisione tra Postgres e SQLite per uno strumento che memorizzerà quaranta righe. Scrivi un file. Usa istruzioni print() invece di un logger. Usa una lista Python invece di un database se è tutto quello che ti serve.

# expenses.py - ugly version, and that's fine
import csv
from datetime import date

def add_expense(amount, category):
    with open('expenses.csv', 'a', newline='') as f:
        writer = csv.writer(f)
        writer.writerow([date.today().isoformat(), amount, category])

add_expense(12.50, 'coffee')

Ecco un expense tracker funzionante. Non è scalabile, non ha test, e ti porterà al 90% di qualcosa che puoi effettivamente usare domani. Puoi refactorizzare una cosa brutta che funziona. Non puoi refactorizzare una cosa bella che non esiste.

Deployalo da qualche parte, anche in modo disordinato

Un progetto sul tuo laptop non conta come shipped. Mettilo davanti a internet o davanti a una persona che lo esegue da sola.

• Strumento CLI: esegui un push verso un repo pubblico di GitHub con un README di due paragrafi che mostra esatti comandi di install e run
• App web: deploy su Render, Fly.io, oppure un droplet DigitalOcean da $5 — non spendere tre giorni a confrontare le opzioni di Kubernetes per un progetto con un utente
• Script: configura un cron job oppure una GitHub Action così funziona senza che tu la tocchi

L'attrito di deployment uccide più side project di qualsiasi sfida tecnica. Se git push verso una piattaforma come Render è troppo in questo momento, registra semplicemente un video Loom di 90 secondi in cui funziona localmente e invialo. Il punto è una prova esterna che funziona, non la maturità dell'infrastruttura.

Scrivi quello che si è rotto

Dopo il shipping, spendi quindici minuti scrivendo tre cose che sono andate male e come le hai risolte. Non per nessun altro — per te. Questo è l'apprendimento vero. Il tutorial ti ha insegnato la sintassi. Il pip install rotto, l'errore CORS, il bug off-by-one della data a mezzanotte — quelli ti insegnano come il software si comporta davvero.

Tieni queste note in un singolo file in esecuzione. Dopo cinque o sei piccoli progetti, noterai le stesse categorie di bug che si ripetono, e quello è il tuo curriculum vero: i vuoti che i tutorial non coprono mai.

Poi scegli la prossima cosa, leggermente più grande

Non saltare da uno script CLI a un sistema distribuito. Aggiungi una dimensione di complessità alla volta: il prossimo progetto ha un database invece di un CSV, oppure una suite di test di base, oppure un secondo utente. Piccoli step compositi battono una riscrittura ambiziosa che si ferma nella terza settimana.

Se vuoi step strutturati dopo questo, i segmenti Python e DevOps di Korra Studio coprono esattamente i gap di deployment e tooling che tendono a far inciampare le persone proprio dopo il loro primo progetto published.