Come creare un portfolio da developer che funziona
Come costruire un portfolio da sviluppatore: quali progetti mettere, cosa scrivere per ognuno, gli errori che lo rendono inutile e quanto conta davvero.
Chi cerca il primo lavoro da sviluppatore sente ripetere che serve un portfolio, e finisce per costruire una vetrina piena di esercizi da tutorial che non convince nessuno. Il problema non è la quantità di progetti: è che quasi tutti i portfolio rispondono alla domanda sbagliata. In questo articolo ti spiego cosa guarda davvero chi seleziona, e come costruirne uno che aiuti invece di occupare un weekend.
A cosa serve davvero
Un portfolio serve a dimostrare che sai costruire qualcosa che funziona, e che sai spiegare le decisioni che hai preso. Non serve a mostrare quante tecnologie conosci.
Chi lo guarda — un recruiter tecnico, un futuro capo — ha poco tempo e cerca risposte a tre domande:
- Sa scrivere codice che funziona?
- Sa portare a termine qualcosa?
- Ragiona, o copia e basta?
Tutto ciò che non risponde a queste tre domande è decorazione.
Quanti progetti: tre, fatti bene
Tre progetti curati battono dieci abbozzati. Non è un modo di dire: dieci progetti mediocri comunicano attivamente che non sai portare a termine niente.
La composizione che funziona:
1. Un progetto completo e funzionante. L'elemento più importante di tutti. Un'applicazione vera, online, che una persona può usare. Non serve che sia originale: un gestionale, un'app per tenere traccia di qualcosa, uno strumento che risolve un problema tuo.
2. Un progetto che mostra profondità tecnica. Qualcosa in cui hai affrontato un problema non banale: prestazioni, un'integrazione complicata, molti dati da gestire. È quello di cui parlerai al colloquio.
3. Un progetto piccolo e rifinito. Anche semplice, ma fatto bene: codice pulito, test, documentazione. Dimostra che sai lavorare con cura.
Cosa non mettere: l'app to-do del tutorial, il clone di Netflix seguito passo passo, l'esercizio del corso. Chi seleziona li riconosce a colpo d'occhio, e comunicano il contrario di quello che vorresti.
La cosa che quasi nessuno fa
Per ogni progetto, scrivi perché hai fatto le scelte che hai fatto.
È il singolo elemento che distingue un portfolio efficace da uno inutile, e lo fa pochissima gente.
Non "realizzato con React e PostgreSQL" — quello si vede dal codice. Ma:
"Ho scelto PostgreSQL invece di MongoDB perché i dati hanno molte relazioni e servivano transazioni sugli ordini. All'inizio avevo usato Mongo e mi sono trovato a duplicare dati in tre posti."
Questo paragrafo vale più di due progetti in più. Dimostra che hai valutato alternative, incontrato un problema reale e imparato qualcosa — cioè esattamente quello che si fa al lavoro.
Un README ben fatto contiene:
- Cosa fa, in due righe, e a chi serve
- Il link al progetto funzionante e qualche schermata
- Le scelte tecniche e il perché
- Un problema che hai incontrato e come l'hai risolto
- Cosa faresti diversamente oggi
L'ultimo punto è controintuitivo ma potente: riconoscere i limiti del proprio lavoro è un segnale di maturità, non di debolezza.
Il progetto deve essere online
Un progetto che si può solo leggere su GitHub vale una frazione di uno che si può usare.
Chi valuta non clonerà mai il tuo repository per farlo girare in locale. Aprirà un link, proverà trenta secondi, e si farà un'idea.
Metterlo online oggi costa zero: i piani gratuiti di diverse piattaforme bastano ampiamente. Il come è in mettere online un sito a costo zero.
Un accorgimento pratico: se serve registrarsi, metti delle credenziali di prova nel README. Un modulo di login davanti a un progetto da valutare è il modo più veloce per far chiudere la scheda.
Il codice viene letto
Vale la pena curarlo, perché è la parte che verrà davvero guardata:
Cronologia dei commit sensata. Messaggi chiari, non venti commit chiamati "update". Racconta come hai lavorato.
Struttura ordinata. Cartelle logiche, nomi comprensibili.
Niente segreti nel repository. Chiavi API o password nel codice sono una bandiera rossa immediata. Usa le variabili d'ambiente.
Qualche test. Anche pochi. Molti candidati non ne hanno nessuno: averne è un elemento di distinzione a basso costo.
Niente codice morto. File commentati, cartelle vuote, resti di tentativi: puliscili.
Se non hai dimestichezza con la parte di versionamento, la base è in usare Git e GitHub.
Serve un sito-portfolio?
Non è obbligatorio. Un profilo GitHub ben curato, con un README personale che presenta i progetti migliori, è sufficiente per la maggior parte delle candidature.
Ha senso farlo se vuoi fare frontend — in quel caso il sito è un progetto, e dimostra le tue competenze — o se lavori come freelance e ti serve un biglietto da visita.
Se lo fai, tienilo semplice: chi sei, cosa sai fare, tre progetti, contatti. Un sito-portfolio con animazioni elaborate e caricamento lento comunica il contrario di quello che vorresti, e vale la pena curarne almeno le prestazioni di base.
Quanto conta, onestamente
Vale la pena ridimensionare, perché molti ci mettono energie sproporzionate.
Il portfolio conta soprattutto per chi non ha esperienza lavorativa. È lì che sostituisce il curriculum vuoto e dà qualcosa di concreto di cui parlare.
Conta molto meno se hai già esperienza: in quel caso pesano di più i lavori fatti e come li racconti.
E conta meno del come ti presenti. Un portfolio decente più un candidato che sa spiegare cosa ha fatto batte un portfolio impressionante di qualcuno che al colloquio non sa argomentare le proprie scelte. Il portfolio serve ad arrivare al colloquio; poi conta come lo affronti.
Regola pratica: due settimane per costruirlo, poi smetti di limarlo e inizia a candidarti. L'errore più comune è rifinirlo all'infinito per rimandare il momento di espormi.
In sintesi
Un portfolio deve rispondere a tre domande: sai costruire, sai finire, sai ragionare. Tre progetti curati lo fanno meglio di dieci abbozzati.
Gli elementi che contano davvero: il progetto è online e provabile, e per ognuno spieghi le scelte tecniche e i problemi incontrati. Quest'ultimo punto lo fa pochissima gente ed è quello che distingue di più.
Evita gli esercizi da tutorial, cura la cronologia dei commit, non lasciare segreti nel codice.
E soprattutto: il portfolio serve ad arrivare al colloquio, non a vincerlo. Due settimane di lavoro, poi inizia a candidarti — le candidature insegnano più di un'altra settimana di rifiniture.
Se stai costruendo i primi progetti e vuoi indicazioni su cosa fare, ho raccolto delle idee in progetti per imparare a programmare.