Oltre junior e senior: la fisica della crescita 🔬

Se nella prima parte abbiamo parlato di varietà × profondità come area che definisce la seniority, qui allarghiamo il modello e facciamo finta per un attimo di essere seri: proviamo a trattare la crescita come se fosse quasi una formula. Quasi. 😄

Immaginiamo quattro dimensioni principali:

• X = varietà “orizzontale” di competenze e contesti
• Y = approfondimento “verticale” sugli stessi
• ΔX = distanza e correlazione tra le competenze/contesti
• Z = tempo di pratica profonda sulle medesime aree

Non è matematica vera, è un modello mentale per fare pace con una verità scomoda: non diventi “senior” perché qualcuno aggiorna la tua job title, ma perché il tuo sistema di competenze cambia stato in modo misurabile.

X: la varietà che ti allarga la mappa 🌍

X è quante cose hai visto, quanti sistemi hai toccato, quante volte hai dovuto cambiare angolo di osservazione. Non significa collezionare framework come figurine, ma cambiare davvero contesto:

• da monolite a microservizi, o viceversa
• da prodotto interno a SaaS pubblico
• da team piccolo e caotico a organizzazione strutturata

Ogni nuovo contesto ti regala due cose: un vocabolario diverso e nuove forze in gioco (costi, rischi, vincoli). È la parte orizzontale della mappa: più esplori, più riconosci pattern e odori di problema fin dal profumo. O dalla puzza. 🙃

Il problema? Solo X, senza il resto, produce il famoso profilo “so un po’ di tutto, bene di niente”. Utile in una call di brainstorming, pericoloso quando bisogna prendere decisioni che finiscono in produzione.

Y: la profondità che ti ancora alla realtà 🕳️

Y è quante volte sei sceso fino in fondo su un problema: non solo averlo visto, ma averlo seguito dalla teoria all’incidente, al fix, al post‑mortem. Qui non basta aver letto un articolo: serve avere pagato il prezzo di una scelta tecnica.

La profondità si vede in dettagli fastidiosi:

• sai dove esattamente si rompe una soluzione sotto carico
• conosci i limiti reali di un pattern che tutti vendono come universale
• hai imparato a togliere, non solo ad aggiungere

Y senza X ti rende un ottimo specialista locale, ma fragile se cambiano le condizioni al contorno. È come saper pilotare solo un tipo di aereo, solo con meteo perfetto.

ΔX: la distanza (e affinità) tra ciò che impari 🔁

ΔX è la parte più sottovalutata: non è solo quante aree tocchi, ma quanto sono distanti o correlate tra loro.

Passare da backend Go a backend TypeScript ha una certa distanza; passare da backend a UX, o da sviluppo a sicurezza, ne ha un’altra. Più grande è ΔX, più il cervello è costretto a costruire astrazioni davvero trasversali: modello mentale, non solo sintassi.

La magia succede quando inizi a vedere ponti tra aree lontane:

• il modo in cui pensi alle API ti cambia se hai fatto un po’ di UX
• il modo in cui pensi ai log cambia se hai fatto on‑call e incident reali
• il modo in cui pensi all’architettura cambia se hai toccato i costi di produzione

ΔX è il coefficiente che aumenta il “valore” di X e Y: a parità di ore, imparare qualcosa abbastanza diverso dal solito ti rende più adattabile che stare sempre nello stesso corridoio.

Z: il tempo che conta davvero (non il badge di anzianità) ⏱️

Z non è il numero di anni dalla laurea o dal primo commit. È tempo di pratica deliberata e consapevole sulle stesse aree, con cicli di feedback reali.

Due persone con lo stesso numero di anni di lavoro possono avere Z molto diversi:

• chi ripete lo stesso anno dieci volte, con le stesse task
• chi ogni anno affronta problemi un po’ più duri, riflette su cosa non ha funzionato e ristruttura il proprio modo di lavorare

Z cresce quando:

• ti esponi a conseguenze reali (SLO, clienti, budget)
• ti prendi il tempo per capire perché qualcosa è andato bene o male
• trasformi ciò che impari in pratica condivisa: test, playbook, guideline, decision log

Z senza X e Y è solo anzianità; X e Y senza Z sono solo esperimenti occasionali. Il gioco serio inizia quando queste tre dimensioni si parlano.

Mettere insieme X, Y, ΔX e Z 🧮

Se volessimo forzare una pseudo‑formula, potremmo pensare a qualcosa del genere:

seniority ≈ (X × Y × f(ΔX)) × g(Z)

Dove:

• f(ΔX) aumenta il peso della tua esperienza quando colleghi mondi diversi
• g(Z) tiene conto di quanto a lungo hai fatto sul serio quel gioco

Non è un modo per dare un voto in decimali a una persona, ma per fare domande migliori:

• ho abbastanza X o sto girando sempre nelle stesse tre stanze?
• ho abbastanza Y o resto sempre in superficie perché “non c’è tempo”?
• il mio ΔX è zero (sempre lo stesso dominio) o sto davvero allenando il cambio di prospettiva?
• Z cresce o sto vivendo lo stesso anno in loop?

La seniority smette di essere un titolo mistico e diventa un sistema dinamico da allenare.

Altri spunti da collegare alla formula 🧠

Già che abbiamo aperto il laboratorio, aggiungiamo qualche altra variabile che dialoga bene con X, Y, ΔX e Z.

1. Densità di responsabilità (R)
Non conta solo ciò che sai fare, ma quanto peso reggono le tue decisioni. Gestire incident, prendere decisioni architetturali, dire “no” a certe feature: più responsabilità sostieni, più acceleri Y e Z (e spesso anche la tua lucidità).

2. Qualità del feedback (F)
Non tutto il feedback vale uguale. Review pigre, retro superficiali e metriche vanity gonfiano l’ego ma non la seniority. Feedback chiaro, tempestivo, collegato a effetti reali ti fa crescere molto più in fretta a parità di tempo.

3. Resilienza e antifragilità (A)
Non è solo “reggere lo stress”, ma usare gli errori per migliorare il sistema. Team e persone antifragili trattano bug e incident come materiale di addestramento, non come colpa da insabbiare. A alto moltiplica il valore di ogni Z usato bene.

4. Capacità di sintesi (S)
Capire è una cosa, spiegare in modo semplice è un’altra. S è quella variabile che ti fa passare da “bravo tecnico solista” a persona che innalza il livello del team: decisioni più chiare, meno ambiguità, meno fraintendimenti.

5. Etica delle scelte (E)
Sembra un extra filosofico, in realtà è core: scegliere consapevolmente cosa non fare, cosa non automatizzare, dove mettere un limite, è parte integrante della seniority. Non tutto ciò che è possibile è anche sano, legale o sostenibile.

Queste variabili non vanno in una formuletta unica (per fortuna), ma ti aiutano a leggere la tua storia professionale non come una timeline piatta, bensì come un sistema che evolve.

Come usare il modello senza impazzire 🧭

Questo schema non è pensato per fare auto‑valutazioni ossessive, ma per guidare decisioni pratiche:

• quando scegli il prossimo progetto, chiediti se ti allarga X o ΔX
• quando valuti un nuovo ruolo, guarda quanta responsabilità reale (R) ti porterà
• quando pianifichi il tuo tempo di studio, pensa a come aumentare Y e non solo il numero di tecnologie sfiorate
• quando fai retrospettiva sul tuo anno, prova a raccontarlo in termini di Z: quanta pratica deliberata hai avuto?

Alla fine, la domanda non è “sono junior o senior?”, ma: in quali contesti sono davvero affidabile, e in quali sono ancora in esplorazione? Se riesci a rispondere con onestà, la formula sta già funzionando — anche senza calcolatrice.

E se proprio vuoi una metrica finale, tieniti stretto solo questa: anno dopo anno, riesci a prendere decisioni migliori, con più consapevolezza e meno rumore? Se la risposta è sì, il resto sono solo etichette sul badge.