Chiedi a un ingegnere cosa ha fatto questa settimana, e ben poco della risposta sarà digitare nuova logica in un file vuoto.
Dove va davvero il tempo
L'immagine pubblica del lavoro è composizione. La realtà è più vicina ad archeologia, negoziazione e riparazione.
Leggere codice esistente per capire cosa fa. Riprodurre un guasto segnalato. Revisionare la modifica di qualcun altro. Integrarsi con un sistema la cui documentazione è superata. Aspettare una build. Discutere un approccio. Fare il deployment. Indagare perché il deployment si è comportato diversamente dall'ambiente di test. Riparare qualcosa che ha funzionato per due anni e si è fermato.
Scrivere davvero codice nuovo è una parte genuina del lavoro e non è la parte più grande, e raramente è la parte che determina se il progetto riesce.
Il vincolo sulla maggior parte dei team software è la comprensione e il coordinamento, non la velocità di battitura.
Questo ha un'implicazione diretta per la formazione. Un programma di sviluppo interamente incentrato su linguaggi e framework forma per la metà più piccola del lavoro. Le competenze che decidono i risultati, leggere sistemi non familiari, revisionare bene, progettare per il cambiamento, comunicare una decisione tecnica, sono insegnabili e di solito vengono lasciate all'assorbimento.
Cosa copre la direzione
L'ambito: architettura, codice, test, interfacce di programmazione, controllo di versione, deployment e lavoro di squadra.
Quattro aree.
Costruzione. Linguaggi, design, interfacce e l'arte di scrivere codice che altri possono modificare.
Verifica. Test a ogni livello, revisione, e la disciplina di sapere cosa è stato davvero controllato.
Delivery. Controllo di versione, integrazione continua, deployment e pratica di rilascio.
Collaborazione. Lavorare in team su un sistema condiviso, dove vive davvero gran parte della difficoltà del software commerciale.
Il maggior incremento occupazionale dell'intera tabella
Vale la pena riportarlo con precisione, perché la conversazione pubblica su questa professione si è fatta confusa.
Il Bureau of Labor Statistics statunitense prevede che l'occupazione degli sviluppatori software cresca del 15,8% tra il 2024 e il 2034, pari a 267.700 posti in più. Nello stesso insieme di proiezioni, è l'incremento assoluto più grande tra le professioni tech monitorate, superiore in numeri assoluti a data scientist e analisti della sicurezza informatica messi insieme, anche se entrambi crescono a tassi percentuali più alti. L'occupazione totale in tutte le professioni è prevista in crescita del 3,1% nello stesso periodo.
Due precisazioni vanno affiancate subito a quel numero, e ometterle sarebbe disonesto.
È una proiezione. Le proiezioni sono modelli costruiti su ipotesi di adozione tecnologica e crescita del settore, e vengono riviste. Questa incorpora un'ipotesi sull'intelligenza artificiale che aumenta la produttività, ed è per questo che la stessa tabella mostra diverse professioni amministrative in calo.
Le assunzioni junior sono state difficili. Laureati e chi cambia carriera hanno affrontato un mercato più stretto di quanto suggerisca il dato di crescita aggregato, e una crescita decennale aggregata non dice nulla su quanto sia facile trovare un primo lavoro in un dato anno.
La riconciliazione è che gran parte delle posizioni previste deriva da sostituzione più che da espansione, e che la domanda pende verso chi sa lavorare con sistemi esistenti. È un'affermazione su quale formazione paga, non un argomento per cui la crescita sia fittizia.
La revisione è la competenza che fa scalare un team
La competenza insegnabile a maggior rendimento nell'ingegneria del software, e quella che quasi nessuna organizzazione insegna deliberatamente.
La code review è dove i difetti vengono intercettati prima che costino qualcosa, dove la conoscenza si diffonde nel team, dove gli standard diventano reali invece che solo documentati, e dove gli ingegneri junior imparano più in fretta. È anche dove si spreca moltissimo tempo e dove nasce una quantità sorprendente di conflitto sul lavoro.
Quattro cose che separano una revisione utile da un rituale.
Sapere cosa cercare. Correttezza, gestione degli errori, sicurezza, comportamento su larga scala, e se questo sarà comprensibile tra un anno. La formattazione è ciò che uno strumento dovrebbe gestire, ed è ciò su cui i revisori inesperti concentrano la propria attenzione.
Revisionare il design, non il diff. Il commento più prezioso è spesso che la modifica non dovrebbe esistere in questa forma, e quel commento costa molto meno prima che il lavoro sia fatto.
Separare ciò che deve cambiare da ciò che tu avresti fatto diversamente. Confondere preferenza con requisito è la fonte singola più grande di attrito nella revisione, e insegna alle persone a smettere di chiedere.
Renderla sicura. Una cultura della revisione in cui le persone temono di essere criticate produce modifiche più piccole, più tardive, meno oneste, e nasconde i problemi finché non diventano costosi.
Niente di tutto questo è difficile da insegnare. Si dà semplicemente per scontato che si impari per esposizione, e le persone imparano qualunque cosa facesse il loro primo team.
Dove si colloca nel dominio
Ingegneria del software è la seconda di otto direzioni nel dominio IA, dati e computing di Astra Trainer, ed è la più grande per numero di persone in quasi ogni organizzazione partner. Poggia sull'informatica per il modello sottostante e si collega in avanti al cloud computing e DevOps, dove ormai vive la metà del lavoro dedicata alla delivery.
Si collega anche alla cybersecurity, poiché gran parte delle vulnerabilità sono difetti software ordinari, e a intelligenza artificiale e machine learning, dove i sistemi intorno a un modello sono ingegneria del software convenzionale. Puoi vedere qui le otto direzioni.
La manutenzione è il lavoro, non il dopo
Il software non è finito quando viene rilasciato. Gran parte del denaro speso su un sistema nel corso della sua vita viene speso dopo la prima release, e la maggior parte degli ingegneri passa gran parte della carriera a lavorare su codice che esiste già.
Eppure quasi tutta la formazione tecnica usa esercizi da zero. Le persone vengono insegnate a costruire qualcosa di nuovo, in isolamento, con requisiti puliti e nessuna storia, e poi vengono assunte in un sistema con quindici anni di decisioni accumulate, migrazioni parziali e commenti che descrivono un comportamento cambiato da tempo.
Le competenze che colmano quel divario sono specifiche e insegnabili.
Leggere codice non familiare. Trovare il punto d'ingresso, tracciare un percorso, costruire un modello mentale funzionante senza leggere tutto.
Modificare il codice in sicurezza. Aggiungere test a codice non testato prima di modificarlo, fare piccole modifiche reversibili, e usare tipi e contratti per contenere l'effetto di una modifica.
Capire perché qualcosa è fatto in un certo modo. Gran parte di ciò che sembra irrazionale nel codice legacy era una risposta corretta a un vincolo che non esiste più o a un bug che non si ricorda più nessuno. Cancellarlo senza sapere quale dei due è il modo in cui accadono i disservizi.
Gestire il debito tecnico onestamente. Distinguere le decisioni che erano compromessi ragionevoli dalla trascuratezza accumulata, e rendere visibile il costo di ciascuno a chi decide le priorità.
Migrare in modo incrementale. Quasi ogni grande riscrittura tentata come sostituzione unica è una storia ammonitrice. La migrazione incrementale è una competenza con pattern noti e viene insegnata raramente.
I ruoli, nominati
Ingegneri software, tra front end, back end e full stack.
Platform engineer, che costruiscono gli strumenti interni da cui dipendono altri team.
Ingegneri mobile.
Ingegneri di qualità e test, inclusa l'automazione.
Site reliability engineer, dove l'ingegneria del software incontra le operations.
Architetti tecnici.
Engineering manager e tech lead, dove il vincolo è di solito il giudizio più che la capacità di scrivere codice.
Developer experience engineer, una specializzazione in crescita rivolta al collo di bottiglia di comprensione e coordinamento.
Ingegneri di integrazione, che collegano sistemi non progettati per incontrarsi.
Chi può essere formato per questo
Ingegneri di quality assurance e test. La conversione interna più solida. Conoscono già il prodotto, sanno come si guasta e conoscono la codebase dall'esterno.
Ingegneri di supporto e operations. Verso lo sviluppo, con una conoscenza della produzione che ai team di sviluppo manca e di cui spesso hanno bisogno.
Data analyst. Già scrivono codice, con bisogno di pratica ingegneristica: controllo di versione, test, revisione e design per il cambiamento.
Business analyst e personale di prodotto con inclinazione tecnica, verso ruoli affini all'ingegneria dove la comprensione di dominio è la metà scarsa.
Ingegneri di altre discipline. Ingegneri meccanici, elettrici e civili si convertono bene, portando un metodo sistematico.
Scienziati e ricercatori che già scrivono codice per il proprio lavoro, con bisogno di pratica collaborativa più che di programmazione.
Sviluppatori esperti su tecnologie datate. Spesso trascurati, con una conoscenza profonda dei sistemi e bisogno di un toolchain aggiornato più che di un cambio di carriera.
Sul codice generato e la responsabilità. Il codice prodotto da strumenti di generazione è responsabilità dell'organizzazione che lo rilascia, e può presentare difetti, vulnerabilità di sicurezza, implicazioni di licenza o comportamenti che nessuno nel team sa spiegare. Revisione, test e obblighi di provenienza non si trasferiscono allo strumento. I settori con software regolamentato, inclusi quelli medico, automobilistico, aeronautico e finanziario, hanno requisiti specifici sul processo di sviluppo e sulla tracciabilità che si applicano indipendentemente da come è stato prodotto il codice.
Cosa portare a casa
Produrre codice nuovo è la minoranza del lavoro, e una formazione che copre solo linguaggi e framework affronta la metà più piccola.
Gli sviluppatori software dovrebbero aggiungere 267.700 posti entro il 2034, il maggiore incremento assoluto tra le professioni tech monitorate dal BLS, ed è una proiezione che convive con un mercato delle assunzioni junior davvero difficile.
La code review è la competenza insegnabile a maggior rendimento in un team ed è quasi universalmente lasciata all'assorbimento.
Manutenzione e lavoro su codice legacy sono dove le carriere vengono davvero trascorse, e la formazione insegna in modo schiacciante per il lavoro da zero.
E i migliori candidati interni sono di solito in test, supporto e operations, già in possesso della conoscenza che un nuovo assunto impiega un anno ad acquisire.
Su cosa passano davvero il tempo gli ingegneri software?
Leggere codice esistente, riprodurre guasti, revisionare modifiche, integrarsi con sistemi la cui documentazione è superata, fare deployment e indagare le differenze tra ambienti. Scrivere codice nuovo è reale ma non è la quota più grande.
Lo sviluppo software sta ancora crescendo come professione?
Il BLS prevede una crescita del 15,8% dal 2024 al 2034, pari a 267.700 posti in più, il maggiore incremento assoluto tra le professioni tech monitorate. È una proiezione più che un'osservazione, e convive con un mercato delle assunzioni junior difficile.
Perché la code review conta così tanto?
Perché intercetta i difetti prima che costino qualcosa, diffonde la conoscenza nel team, rende reali gli standard e insegna agli ingegneri junior più in fretta di qualsiasi altra cosa. È anche dove nasce la maggior parte dell'attrito tecnico quando è fatta male.
Perché il lavoro su codice legacy è sottoformato?
Perché la formazione tecnica usa esercizi da zero con requisiti puliti, mentre la maggior parte degli ingegneri passa la carriera a modificare sistemi con anni di storia accumulata, migrazioni parziali e motivi non documentati.
Chi si converte bene verso l'ingegneria del software?
Prima gli ingegneri di test e qualità, poi il personale di supporto e operations, i data analyst che già scrivono codice, gli ingegneri di altre discipline, e gli sviluppatori esperti su tecnologie datate che hanno bisogno di un toolchain aggiornato più che di un cambio di carriera.