Da junior a senior: la matematica del contesto 🧭
Siamo onesti: la distinzione tra “Junior” e “Senior” non è un concorso di calendario. Non vinci punti solo stando seduto abbastanza a lungo davanti a un editor. La crescita reale avviene quando alleni due muscoli che spesso trascuriamo: varietà di contesti e profondità nel singolo contesto. Il resto è storytelling da job post. 😏
Anni vs esperienza reale 📅
Il tempo serve a cuocere la pasta; per cuocere la seniority servono calore e pressione: problemi veri, feedback rapidi, scelte con conseguenze. Che tu scriva in Go o TypeScript, il punto non è il linguaggio, ma quante volte hai dovuto capire “perché non funziona” e cosa farai per non ripetere l’errore.
Il lavoro dello sviluppatore non è scrivere codice: è risolvere problemi. Il codice è solo il mezzo più rumoroso.
Bug in produzione, incident, requisiti ambigui, refactoring prima di una release: è lì che si misura l’esperienza — nel numero e nella qualità dei problemi affrontati e risolti.
La formula e gli assi del contesto ✖️
Se dovessi riassumere tutto in una riga: seniority ≈ varietà di contesti × profondità per contesto. Due assi semplici:
- orizzontale = quanta varietà di contesti hai attraversato
- verticale = quanta profondità hai raggiunto nei singoli contesti
Il punto dove ti collochi su ciascun asse genera un’area: più è ampia, più sei vicino alla seniority. Non è una gara “o/o”, ma un completamento su due dimensioni.
Visuale rapida: varietà (X) e profondità (Y).
I due estremi: iper-specialista e multi-contesto 🎯
Nella pratica incontriamo due profili ricorrenti:
- Iper-specialista in pochi contesti: velocissimo nel “suo” dominio, rischia però di soffrire appena cambia il vento. Se il contesto evolve, la curva di adattamento può essere ripida.
- Esperto trasversale su più contesti: ha visto abbastanza mondi da riconoscere pattern, limiti e trade-off. Magari non è il più veloce nel primo sprint, ma spesso è quello che non si incastra al terzo.
Perché la formula funziona ✨
Se incrementi solo l’asse orizzontale accumuli curiosità ma poca trazione; se alzi solo il verticale diventi efficientissimo localmente ma fragile fuori dal tuo perimetro. La crescita migliore unisce le due cose: vedi abbastanza mondi da riconoscere i pattern, e scendi abbastanza in profondità da saperli implementare sul serio.
In pratica è una questione di compromessi intelligenti:
- la varietà allena il riconoscimento rapido delle ricorrenze e dei vincoli (sapere che “questo odora di race condition” o “qui stai nascosto dietro un overengineering elegante”)
- la profondità costruisce strumenti mentali e riflessi tecnici (profilare, misurare, ridurre, semplificare) che trasformano l’intuizione in soluzione ripetibile
Il prodotto dei due assi conta più della somma: un po’ di varietà moltiplica il valore della tua profondità, e viceversa. Inoltre c’è un effetto di ritorni decrescenti: dopo un certo punto, spingere solo su uno dei due assi aggiunge poco. Bilanciare, invece, fa crescere l’“area utile” in modo sorprendentemente più veloce.
Segnali di squilibrio da tenere d’occhio: cicli infiniti di hello world su stack sempre nuovi, oppure mesi a ottimizzare l’angolo perfetto di un micro-dettaglio che nessun utente noterà. Se ti riconosci in uno dei due, è tempo di spostare un po’ il peso sull’altro asse.
Conoscere i known-unknown 🧩
La varietà “senza approfondimento” genera una costellazione di known-unknown: sai che certe cose esistono, non le padroneggi ancora. Non è un bug del profilo: è una mappa. La seniority non è “sapere tutto”, ma sapere dove sono i buchi, come colmarli e in quale ordine. Nessuno è stupido: si è solo inesperti finché non si pratica; e l’ignoranza non è un male, è backlog di apprendimento da esplicitare.
Se “non riesci ad approfondire” un’area, spesso manca l’approccio: riduci il perimetro, definisci un obiettivo misurabile, scegli fonti curate, cicli brevi con feedback. Trasforma l’ignoto in un esperimento ripetibile.
Giovane, ma non per forza junior 🌱
Uno sviluppatore giovane con esperienza su una larga varietà di contesti, oppure con profonda esperienza su un singolo contesto, è spesso più vicino al mondo “senior” che a quello “junior”. Perché? Perché ha già costruito mappe mentali, sviluppato anticorpi e allenato il giudizio. L’età anagrafica non ha il monopolio della lucidità.
Ciò che chiude davvero il gap non è il numero di linguaggi studiati, ma i cicli end-to-end affrontati sotto vincoli reali: prendere un requisito ambiguo, portarlo in produzione, reggerne gli effetti e tornare indietro a migliorare. In altre parole: varietà × profondità, con in più ownership, feedback e proattività (non aspettare: proponi spike, studia con costanza, mantieni un learning backlog condivisibile).
Perché allargare il contesto migliora il team 🤝
Approfondire aree adiacenti a ciò su cui lavori ogni giorno affina l’integrazione con il resto del team. Capire un po’ di UX migliora le API. Capire il monitoraggio migliora le scelte architetturali. Capire come ragiona un PM/PO riduce i giri a vuoto. In breve: più contesto condiviso, meno attriti e handoff dolorosi.
Allargare il contesto crea un vocabolario condiviso. Non significa diventare tuttologi, ma capire le “forze” in gioco: latenza contro semplicità, UX contro vincoli tecnici, velocità di delivery contro affidabilità. Con un lessico comune, le decisioni diventano più brevi e migliori.
Gli effetti collaterali positivi si vedono presto: meno back-and-forth nei ticket, meno rielaborazioni, meno sorprese in produzione, onboarding più rapido di nuovi colleghi. E soprattutto, si passa da “il mio pezzo funziona” a “il sistema regge, oggi e tra tre mesi”.
Allenare il problem solving, non la vanity metric 🧩
Misurare l’esperienza in “anni” è comodo, ma fuorviante. Misurala in problemi risolti: requisiti ambigui chiariti, bug diagnosticati, incident gestiti, trade-off esplicitati. Ogni ciclo completo — osservare, ipotizzare, sperimentare, verificare — è un livello guadagnato.
Loop minimo per allenarlo:
- definisci problema e vincoli (SLO, complessità, rischi)
- sperimenta e misura (ipotesi semplice, durata breve)
- decidi: itera, integra o scarta
Poi rendi gli esiti durevoli: test che riproduce il bug, playbook di on‑call, ADR sintetica. Così ogni problema risolto diventa patrimonio del team — e la tua “area” di seniority cresce davvero.
Come crescere davvero: scegli problemi nuovi 🚀
Se vuoi accelerare, cerca intenzionalmente terreni che ti costringano a imparare. Alcuni modi pratici:
- Crea un progetto con obiettivi funzionali chiari: non “giocare con un framework”, ma centrare un risultato.
- Contribuisci a open source risolvendo issue: affronti codice altrui, standard di qualità e review pubbliche.
- Esplora lo sviluppo “opposto” o parallelo: backend se fai frontend (e viceversa), mobile se fai web, un po’ di devops se fai backend. Cambiare prospettiva allena il giudizio.
- Studia nuovi paradigmi e linguaggi: il cervello si affila cambiando mental model, non aggiungendo scorciatoie.
- Impara la forma mentis di chi ti sta attorno: PM/PO, marketing, supporto. Capire “perché” aiuta a scegliere “come”.
Prendi l’abitudine di documentare ciò che scopri e di trasformare ogni inciampo in una pratica: un test, un playbook, una decisione architetturale motivata.
AI: strumento, non scorciatoia 🤖
La AI è uno strumento: aiuta nella discovery (definire problemi, vincoli, casi limite) e nella delivery (ipotesi, alternative, piani), ma le decisioni devono essere comprese e assunte da esseri umani responsabili. Il vibe‑coding — far generare codice solo da indicazioni funzionali, senza comprenderne vincoli e implicazioni — non porta alla seniority: servono comprensione, integrazione e ownership.
Senza controllo, la AI introduce rischi (incoerenze architetturali, debito tecnico, sicurezza, conformità). Metti guardrail minimi: standard condivisi, test, code review, osservabilità e limiti operativi per gli agenti.
Conclusione: meno badge, più mappe 🗺️
La seniority non è un distintivo da mostrare, è una mappa che aggiorni ogni volta che attraversi un territorio nuovo e torni con qualche cicatrice in più. Allena varietà e profondità, scegli problemi che contano e ricordati: il codice è importante, ma la capacità di orientarsi nel contesto lo è di più.