Primi 90 Giorni: Guida Passo Passo per Ingegneri del Software
Sei stato in prima linea.
Hai lucidato il tuo CV fino a farlo brillare. Hai potenziato le tue competenze e le tue certificazioni.
Hai sistemato il tuo GitHub, studiato domande di system design finché non si confondevano tutte, e hai cliccato su “candidati” più volte di quante tu voglia ricordare.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Hai affrontato il tour de force dei colloqui—lavagna, esercitazioni a casa, silenzi imbarazzanti e tutto il resto. Hai rinforzato le tue competenze e sei rimasto calmo.
E poi… è arrivata la lettera d’offerta. Hai ottenuto il lavoro! Ora inizia il vero lavoro.
Perché mentre essere assunti è difficile, inserirsi efficacemente lo è ancora di più. Qui passi da candidato a contributore, ed è dove le prime impressioni diventano indelebili. I tuoi primi 90 giorni getteranno le basi per tutto ciò che seguirà.
In questo playbook, ti guiderò su come partire col piede giusto come nuovo software engineer, con consigli pratici da due professionisti veterani del settore tech che ci sono già passati, sanno cosa funziona e cosa no. Ma prima, iniziamo con uno sguardo realistico a cosa significa davvero essere software engineer oggi.
Cos’è un Software Engineer?
Oh cielo, da dove iniziare? Davvero, su questo argomento si potrebbe scrivere un libro, anche perché il termine a volte viene usato come contenitore per diversi ruoli che coprono tutte le fasi del ciclo di vita dello sviluppo software. Di conseguenza, qui possono essere rilevanti anche altri titoli, come sviluppatore o programmatore. Noi useremo ‘software engineer’ come termine ombrello.
Ecco una definizione sintetica di software engineering, fornita dalla Michigan Technological University, per tenerci sul binario giusto: “La software engineering è il ramo dell’informatica che si occupa della progettazione, sviluppo, test e manutenzione delle applicazioni software. I software engineer applicano principi ingegneristici e conoscenze dei linguaggi di programmazione per costruire soluzioni software destinate agli utenti finali.”
Se riduciamo tutto al minimo, suona più o meno così: i software engineer costruiscono oggetti digitali per persone e macchine. Invece di usare martello e chiodi, usano codice, insieme a vari strumenti come Git e altri componenti.
Dovremmo anche sottolineare uno dei motivi per cui tante persone vogliono lavorare come software engineer: il lavoro può essere ben retribuito. Il sito di carriere Glassdoor indica il compenso medio totale per i software engineer a $147.000 all’anno (ultimo controllo: 28 aprile 2025), anche se i numeri effettivi variano a seconda di esperienza, posizione e settore.
Ora affrontiamo alcuni consigli e idee pratiche per partire subito alla grande.
I primi 30 giorni
Nell’articolo dedicato alle carriere nella cybersecurity, abbiamo evidenziato che i primi 30 giorni si riducono, in fondo, a imparare. Questo significa tutto: dai codici e tool a volti e ambienti nuovi. Ed è vero anche qui, sia pure con alcune differenze rispetto a quel settore.
Consiglio #1: Non tutti i tech stack sono uguali
Navigare nel tuo nuovo ruolo deve essere tanto imparare persone e processi quanto apprendere la base di codice o il tech stack.
“Secondo la mia esperienza nelle grandi aziende, è più importante capire le persone [e] i processi che l’architettura del codice,” dice Justin Garrison, Head of Product presso Sidero Labs. Prima del ruolo attuale, Justin è stato Senior Developer Advocate in AWS e ha ricoperto diversi ruoli ingegneristici in Disney, inclusi Senior Software Engineer.
Consiglio #2: Comprendi come l’azienda genera ricavi
Per massimizzare il tuo valore, devi capire come l’organizzazione genera il suo valore.
“Oltre a imparare stack tecnici e requisiti, gli ingegneri dovrebbero capire come l’azienda crea valore e viene pagata,” ci racconta Chris Carter, Principal Product Manager presso NetApp Instaclustr. Prima dell’attuale posizione, Chris ha iniziato in azienda come Senior Development Engineer e Team Lead. Continua:
“Abbonamenti diretti? Team di vendita e offerte personalizzate? Visualizzazioni e pubblicità? Scoprite come l’azienda si misura e come si passa dal codice al KPI.”
Costruisci questa comprensione subito. I software engineer che collegano i punti tra il loro codice e i dati finanziari dell’azienda non passeranno mai di moda.
“Comprendendo come l’azienda stessa misura il proprio successo, puoi posizionarti per contribuire a generare quel successo e dare il tuo apporto ai risultati economici,” dice Chris.
Consiglio #3: Clona il repository, ma non affrettare il commit
Certo, sei impaziente di fare la tua prima pull request. Ma tratta il codice come un organismo vivente: osservane i pattern, comprendi la sua anatomia e fai domande prima di intervenire. Usa le funzionalità del tuo IDE per la navigazione del codice, i comandi grep o la ricerca nel repository per seguire il flusso di dati e logica all’interno del sistema.
E se ti blocchi? Prova a riprodurre il comportamento localmente e poi seguilo passo dopo passo. I debugger sono spesso sottovalutati, e il metodo del “rubber ducking” funziona ancora.
Consiglio Pro: Guarda le pull request recentemente approvate per capire lo stile del codice, la cultura delle revisioni e cosa significa davvero “finito”.
I Primi 60 Giorni
Uno dei modi migliori per accelerare la curva di apprendimento è essere curiosi, non solo su cosa fa il codice, ma anche perché lo fa in quel modo.
Consiglio #4: Chiediti, “Perché è stato costruito così?”
Il codice legacy può sembrare un groviglio, ma spesso c’è sostanza nel “sugo”. Vincoli dovuti a un servizio ormai dismesso, un compromesso di performance, una richiesta di business legata a una funzionalità ormai superata: queste scelte hanno una storia. Conoscere questa storia ti aiuta a evitare di proporre soluzioni già tentate (e fallite), e accresce la tua credibilità.
Parti dalla documentazione interna (anche se datata). Poi chiedi a un collega di spiegarti qualcosa di poco chiaro, trattandolo come coautore della storia del sistema.
“Quali decisioni sono incorporate in questo codice?” è una domanda migliore di “Perché questo codice fa schifo?”
Consiglio #5: Identifica le “regole non scritte” del tuo team
Ogni organizzazione tecnica le ha. Magari il team preferisce le RFC su Notion invece delle segnalazioni su Jira, oppure che si facciano i deploy il giovedì, o che i test unitari siano opzionali, ma i test end-to-end siano sacri.
Queste norme non saranno sempre scritte in un manuale, ma influenzeranno il tuo successo tanto quanto le tue competenze di sviluppo. Osserva le dinamiche su Slack, analizza i messaggi dei commit su Git e chiedi ai colleghi cosa avrebbero voluto sapere quando sono arrivati.
Consiglio #6: Continua a incontrare – e imparare dalle – persone
Justin di Sidero Labs sostiene che incontrare le persone aiuta gli ingegneri a capire come i sistemi collaborano fra loro molto oltre il codice: “Al termine di questi incontri, era molto più semplice comprendere perché i sistemi sono fatti in quel modo.”
Ciò comporta numerosi benefici, tra cui abbassare la pressione sanguigna quando si legge del codice che inizialmente sembra incomprensibile. Se l’ha scritto una persona, probabilmente quella persona aveva le sue ragioni — e queste possono includere variabili organizzative, pressioni temporali, e così via.
Questo tipo di comprensione olistica aiuta nella cultura di team e nella comunicazione, ma anche in termini di empatia e diplomazia quando arriva il momento di individuare e proporre miglioramenti.
I Primi 90 Giorni
Ormai sei cresciuto: “Entro 90 giorni dovresti aver trovato la tua stabilità e, auspicabilmente, sentirti pronto a prenderti carico di compiti più grandi,” dice Chris di NetApp Instaclustr.
Questa ultima fase è davvero dedicata alla pianificazione e all’inizio dell’esecuzione. Dove puoi
iniziare a produrre vero impatto?
Consiglio #7: Inizia a ottimizzare con scopo e impatto
Arrivati a 90 giorni, non sei più solo il “nuovo ingegnere”: sei un contributore emergente. Questo significa che è tempo di cercare opportunità per migliorare le cose. Ma c’è una regola: non ogni miglioramento merita di essere perseguito, e non ogni bug va corretto.
“Non si tratta di creare una lista infinita di cose che non funzionano,” dice Chris. “Si tratta di capire il business, il cliente, e il contesto—e poi usare quelle conoscenze per individuare modi significativi per migliorare.”
Ecco come Chris e il suo team affrontano questo approccio mentale:
- Pensa a monte: Non saltare subito alle soluzioni—comincia scrivendo segnalazioni chiare che descrivano il problema.
- Dai le giuste priorità: Impara come il tuo team valuta impatto, sforzo e urgenza. Un bug minore nell’interfaccia utente su una schermata destinata all’oblio? Probabilmente non è un’emergenza.
- Mentalità orientata al cliente: Chiediti sempre, “Questo avrà valore per un vero utente?” Se la risposta è no, archivia e vai oltre.
Quando avrai acquisito familiarità con i sistemi e la cultura, comincia a cercare compiti a maggior valore aggiunto—quelli che riducono gli attriti, migliorano la delivery o rafforzano l’esperienza dell’utente.
“Consegna in modo costante lavori che fanno avanzare i risultati di business, e sarai subito riconosciuto come qualcuno che ‘ha capito’—e a cui affidare responsabilità maggiori,” dice Chris.
Consiglio #8: Consegna qualcosa. Qualsiasi cosa. Ma prenditene la responsabilità.
Entro il 90° giorno, non è necessario aver riscritto un servizio principale o lanciato una nuova funzionalità da solo. Ma dovresti essere in grado di indicare una cosa, anche piccola, che hai consegnato e di cui ti sei occupato dall'inizio alla fine.
Potrebbe essere:
- Una correzione di bug che ha ridotto gli ostacoli per l’utente
- Un aggiustamento alla pipeline CI/CD che ha velocizzato le build
- Un aggiornamento della README che ha aiutato il prossimo nuovo assunto
- Un’ottimizzazione del backend che ha risparmiato 50 ms su una query comune
Non deve essere qualcosa di eclatante—deve essere utile. L’impatto non riguarda l’apparenza; riguarda la funzione.
Mantra dell’ingegnere: “Ho reso la vita del team migliore dell’1% questa settimana?”
Consiglio #9: Crea un backlog personale di apprendimento
Non diventerai padrone dell’intero codice, infrastruttura e logica di business in 90 giorni. Va bene così. Ciò che conta è quello che farai dopo.
Crea un “backlog” personale di competenze e lacune da colmare. Annotati:
- Aree del sistema che ancora non comprendi
- Strumenti o framework che vuoi approfondire (es. Kubernetes, gRPC, Terraform)
- Debito tecnico o particolarità che vuoi rivedere
Poi dai priorità a una cosa per ogni sprint e spuntala. Non stai solo imparando il sistema—stai progettando la tua roadmap di crescita.
Iscriviti alla newsletter di The CTO Club per ricevere altri playbook per i tuoi primi 90 giorni in qualsiasi ruolo tech!
