Ogni pochi anni gli strumenti cambiano del tutto, e ogni pochi anni lo stesso piccolo insieme di idee finisce per spiegare cosa è andato storto.
Il problema dell'emivita
La conoscenza tecnica non decade a un ritmo uniforme, e questa differenza è la cosa più utile che un'organizzazione possa capire sulla formazione dei propri ingegneri.
La conoscenza di framework e librerie decade in fretta. Una tecnica legata a una versione specifica, imparata oggi, è spesso obsoleta entro pochi anni, a volte prima. La conoscenza di piattaforme e fornitori decade quasi altrettanto in fretta, e i comandi e le interfacce specifiche cambiano di continuo.
Sotto c'è uno strato che si è mosso a malapena. Come un computer esegue le istruzioni. Quanto costa una struttura dati. Perché alcuni algoritmi scalano e altri no. Cosa fa un sistema operativo con la memoria e con l'attesa. Come le reti consegnano davvero un messaggio.
Formare le persone solo sullo strato che decade in fretta significa riformarle ogni tre anni, per sempre.
Non è un argomento contro la formazione pratica. È un argomento sulla proporzione. Gran parte dello sviluppo tecnico aziendale spende molto sullo strato con la vita più breve e quasi niente sullo strato che rende il prossimo strumento imparabile in una settimana invece che in un trimestre.
Cosa copre la direzione
L'ambito: algoritmi, strutture dati, sistemi operativi, reti e calcolo.
Quattro aree.
Algoritmi e strutture dati. Quanto costano le operazioni, quale struttura si adatta a quale schema di accesso, e come ragionare sulla scala.
Sistemi. Processi, memoria, scheduling, file e le astrazioni che nascondono l'hardware.
Reti. Come si muovono i dati, cosa può andare storto, e perché i sistemi distribuiti sono difficili in un modo specifico.
Teoria della computazione. Cosa è calcolabile, cosa è trattabile, e dove sono i limiti invalicabili.
La complessità, l'unica idea che si ripaga da sola
Se un'organizzazione insegna un solo concetto di questa direzione, dovrebbe essere questo.
La complessità algoritmica descrive come cresce il lavoro svolto da un algoritmo al crescere dell'input. La distinzione non è accademica. È la differenza tra codice che funziona nei test e fallisce in produzione.
Tre conseguenze pratiche.
I dati di test nascondono il problema. Un algoritmo il cui lavoro cresce col quadrato dell'input sembra a posto su mille record e diventa inutilizzabile su un milione. Il fallimento non è un bug che appare più tardi. Era presente dalla prima riga ed era invisibile alla scala del test.
Il ciclo annidato su un database è l'errore costoso più comune nel software commerciale. Una query dentro un ciclo, dove ogni iterazione fa un proprio giro di andata e ritorno, si comporta in modo accettabile con pochi elementi e collassa sotto un volume reale. Questo schema compare di continuo, in ogni linguaggio, scritto da persone con anni di esperienza, perché nessuno ha mostrato loro come vederlo.
Scegliere la struttura giusta è di solito un guadagno maggiore che ottimizzare il codice. Cercare qualcosa in una lista significa esaminare ogni elemento. Cercarlo in una hash table è effettivamente immediato indipendentemente dalla dimensione. Cambiare una riga batte riscriverne cento.
Niente di tutto questo richiede sofisticazione matematica. Richiede l'abitudine di chiedersi cosa succede quando questo diventa dieci volte più grande, e quell'abitudine si insegna in fretta a chi già scrive software.
Cosa fa davvero il sistema operativo
Lo strato che la maggior parte degli sviluppatori tratta come invisibile, e dove nasce una quota sorprendente dei problemi in produzione.
Memoria. Come funziona l'allocazione, quanto costa il garbage collection e quando mette in pausa, perché la località della memoria influisce sulla velocità molto più del numero di istruzioni, e cosa succede davvero quando un processo esaurisce la memoria disponibile. I problemi di memoria sono tra i guasti in produzione più difficili da diagnosticare senza questo quadro.
Processi e thread. Cosa significa isolamento, quanto costa un context switch, e perché aggiungere thread oltre un certo punto rende un sistema più lento invece che più veloce.
Input e output. Il motivo per cui la maggior parte delle applicazioni attende invece di calcolare. Le operazioni su disco e rete sono più lente di ordini di grandezza rispetto all'accesso alla memoria, ed è per questo che esistono gli approcci asincroni e non bloccanti. Gli ingegneri che non hanno interiorizzato questo ottimizzano il calcolo in programmi che passano la vita ad aspettare.
Concorrenza. Race condition, deadlock e il fatto che operazioni che nel codice sorgente sembrano atomiche non lo sono. È la categoria di bug che supera ogni test e fallisce in produzione sotto carico, e non può essere ragionata senza il modello.
Dove si colloca nel dominio
Informatica è la prima di otto direzioni nel dominio IA, dati e computing di Astra Trainer, e sta sotto a tutte le altre. Ingegneria del software, data science, cloud e DevOps, cybersecurity e machine learning poggiano tutti sulle stesse idee computazionali, e chi le possiede impara ogni nuovo strato più in fretta.
Si collega più direttamente all'ingegneria del software, che è questo materiale applicato sotto vincoli commerciali, e a sistemi IT e reti di computer, dove gli strati di sistema operativo e rete sono il lavoro quotidiano. Puoi vedere qui le otto direzioni.
Perché conta di più adesso, non di meno
L'ipotesi comune è che gli strumenti di generazione del codice rendano obsoleti i fondamentali. L'argomento opposto è più forte, e si basa su ciò che diventa il lavoro.
Il lavoro si sposta dallo scrivere al giudicare. Revisionare codice che non hai scritto, e decidere se è corretto, richiede più comprensione che produrlo, non meno. Una funzione dall'aspetto plausibile ma con le caratteristiche di complessità sbagliate è esattamente il tipo di cosa che supera una revisione superficiale e fallisce su larga scala.
Il codice generato è sicuro di sé sulle performance in un modo che non può giustificare. Non conosce i tuoi volumi di dati, i tuoi schemi di accesso o il tuo budget di latenza. Qualcuno deve conoscerli.
Il debugging resta la parte difficile. Quando un sistema si comporta in modo inatteso in produzione, la domanda è cosa sta succedendo davvero, e si risponde a partire da un modello di come funziona la macchina.
Le decisioni architetturali non si completano automaticamente. Scegliere tra coerenza e disponibilità, decidere cosa mettere in cache, giudicare dove tracciare un confine: sono le decisioni che determinano se un sistema sopravvive, e sono tutte questioni di fondamentali.
La formulazione onesta è che questi strumenti alzano il pavimento sulla produzione di codice e alzano il valore di saperlo valutare. Le organizzazioni che leggono solo la prima metà e non la seconda scopriranno quale delle due avevano davvero.
I ruoli, nominati
Ingegneri software a ogni livello, perché questo è il substrato.
Ingegneri di sistemi e programmatori di sistemi.
Ingegneri delle performance, una specializzazione distinta e cronicamente scarsa.
Ingegneri di sistemi distribuiti.
Ingegneri di compilatori e runtime.
Ingegneri di database, dove strutture dati e storage si incontrano.
Ricercatori di sicurezza, il cui lavoro dipende dal capire cosa fa davvero la macchina più che cosa dice il codice sorgente.
Architetti tecnici, che prendono le decisioni informate da questo materiale.
Research engineer nei sistemi di machine learning, dove l'efficienza su larga scala è l'intero problema.
Chi può essere formato per questo
Sviluppatori autodidatti e diplomati di bootcamp. Il gruppo più ampio e più gratificante. Hanno spesso una solida competenza pratica, buone abitudini di tooling ed esperienza reale di delivery, con un divario specifico qui. Colmarlo è un lavoro ben definito, non un programma generico di upskilling, e l'effetto sul loro potenziale è grande.
Analisti e data scientist. Verso performance e scala, dove query e pipeline che funzionano sui campioni falliscono sui dati completi proprio per queste ragioni.
Amministratori IT e di sistemi. Già in possesso della conoscenza di sistemi operativi e reti dal lato operativo, con bisogno dello strato di programmazione.
Ingegneri di altre discipline. I laureati in matematica, fisica e ingegneria si convertono bene, perché lo stile di ragionamento si trasferisce.
Ingegneri di quality assurance e test. Verso ruoli di sviluppo, con un forte senso di come le cose si rompono.
Ingegneri di supporto. Verso lo sviluppo, con conoscenza reale di cosa si rompe in produzione e del perché.
Sui fondamentali e sulle assunzioni. I colloqui algoritmici sono ampiamente usati e ampiamente criticati come filtro di selezione, e le prestazioni in quei colloqui correlano solo in modo imperfetto con le prestazioni sul lavoro. Questa direzione esiste per rendere le persone più brave a costruire e diagnosticare sistemi, non per ottimizzare per un formato di colloquio. Le organizzazioni che usano questo materiale dovrebbero essere chiare su quale delle due cose stanno facendo, perché la formazione che serve l'una non serve necessariamente l'altra.
Cosa portare a casa
La conoscenza tecnica decade a ritmi diversi, e la maggior parte dei budget di formazione va sullo strato che decade più in fretta.
La complessità è il concetto singolo a maggior valore, perché prevede il fallimento su larga scala prima che il codice venga scritto.
La maggior parte dei problemi di performance in produzione riguarda memoria, attesa o concorrenza, e tutti e tre vivono nello strato del sistema operativo che la maggior parte degli sviluppatori tratta come invisibile.
Il codice generato alza il valore del giudizio, e qui giudizio significa fondamentali.
E le persone che ne beneficiano di più scrivono già software per te, con un divario specifico, visibile e rapido da colmare.
Perché insegnare i fondamentali invece dei framework attuali?
Perché la conoscenza dei framework decade in pochi anni, mentre le idee computazionali di fondo reggono da decenni, e chi possiede i fondamentali impara ogni nuovo framework in una frazione del tempo.
Qual è il concetto singolo più utile?
La complessità algoritmica. Spiega perché codice che supera i test fallisce a volumi di produzione, perché una query dentro un ciclo collassa con dati reali, e perché scegliere la struttura dati giusta di solito batte ottimizzare il codice.
Perché i concetti di sistema operativo contano per chi sviluppa applicazioni?
Perché la maggior parte dei problemi di performance in produzione riguarda memoria, input e output o concorrenza. Le applicazioni tipicamente passano il tempo ad aspettare più che a calcolare, e ottimizzare il calcolo in un programma che aspetta non ottiene nulla.
Gli strumenti di generazione del codice rendono i fondamentali meno importanti?
Li rendono più importanti. Il lavoro si sposta dallo scrivere codice al giudicare codice che non hai scritto, e il codice generato non può conoscere i tuoi volumi di dati, i tuoi schemi di accesso o il tuo budget di latenza.
Chi trae il beneficio maggiore da questa formazione?
Sviluppatori autodidatti e diplomati di bootcamp, che spesso hanno una solida competenza pratica e un divario specifico e insegnabile qui, seguiti da analisti dati che incontrano problemi di scala e amministratori di sistemi che passano allo sviluppo.