Nick White sostiene che molta della formazione tecnica non sia inutile, anche quando non serve in ufficio, e che l’IA stia premiando chi sa adattarsi più che chi ama il codice.
Nick White apre con una confessione che suona quasi come una provocazione: dice di non aver mai amato programmare, pur avendo costruito la propria carriera sul codice. La tesi che segue è meno paradossale di quanto sembri: molte cose studiate da uno sviluppatore servono poco in modo diretto, ma non per questo sarebbero tempo buttato. Nel suo racconto, il problema vero non è se un concetto torni identico al lavoro, ma se lasci nel cervello modelli utili per ragionare quando il contesto cambia. E oggi, con l’IA che scrive sempre più codice, quella capacità di adattamento gli sembra contare più dell’innamoramento per la programmazione.
White contesta l’idea che ciò che non si usa subito sia automaticamente inutile. Da studente aveva imparato memory management, strutture dati, algoritmi, loop e condizioni, ma nel lavoro quotidiano sostiene di aver usato solo una parte minima di quel bagaglio.
Non credo che le cose che ho imparato e quelle su cui ho lavorato, quando non le usavo direttamente, siano state sprecate.
4:00
Non è solo la cosa concreta. È che impari modelli mentali.
5:05
La sua argomentazione passa da scuola e matematica: si imparano regole rigide, coerenti, e quelle regole insegnano a pensare. Per White, anche quando un singolo concetto non torna identico nel lavoro, il modo di ragionare resta e si trasferisce altrove, dal codice alla fisica, dalla psicologia alla biologia evolutiva.
White dice di essere entrato nel software soprattutto per soldi, dopo aver studiato ingegneria elettrica e aver trovato il primo corso di programmazione tutt’altro che entusiasmante. Racconta però che proprio la semplicità dei primitivi di base, variabili, funzioni, if, cicli, lo aveva poi conquistato.
Mi sono avvicinato alla programmazione per il denaro. Sono entrato nelle big tech per i soldi.
7:22
Questi piccoli primitivi, che sono molto logici e molto coerenti, hanno il potere dell’infinita complessità.
8:08
Il punto di rottura, per lui, arriva con il web development. XHR, acronimo di XML HTTP request, gli appare come l’esempio perfetto di un mondo incoerente, in cui nomi e funzioni non coincidono e la logica sembra più sporca che elegante.
Io odiavo il web development in un modo che non riesco a articolare.
8:56
Il passaggio più concreto del racconto riguarda Google, dove White dice di aver capito che molte competenze allenate per i colloqui non erano il centro del lavoro. Racconta un episodio su CL e repository monolitici, con numeri di merge crescenti in modo monotono, che gli ha fatto pensare per un attimo di essere davanti a un caso da manuale di DSA.
Monotonic increasing, ehi, DSA, giusto?
2:52
Probabilmente non avevo davvero bisogno di conoscere quei concetti.
2:36
Poi arriva la parte più pragmatica: a Google, dice, ha spesso copiato e incollato da codice esistente o dalla ricerca interna, invece di riscrivere tutto da zero. Le documentazioni, aggiunge, erano spesso pessime, così il modo più rapido per andare avanti era trovare chi aveva già usato quell’API, capire il minimo indispensabile e adattarlo.
Non scrivevo molto codice a mano da molto tempo.
11:04
Le documentazioni fanno schifo, quindi entro nel codebase, trovo qualcuno che ha già usato quell’API, copro e incollo il suo codice.
11:51
Per White, il passaggio all’AI coding non è uno strappo netto ma una variazione della stessa logica che lo ha già accompagnato nella carriera. Sostiene che oggi si ottenga valore dai modelli solo restando comunque programmatori, cioè sapendo cosa chiedere, come verificare e quando correggere.
Stiamo vedendo questo grande passaggio al prompt degli LLM e poi all’attesa che sistemino qualcosa.
13:36
Per molte persone non è più divertente come prima.
13:42
Qui il suo discorso diventa quasi autobiografico. Dice che il piacere per lui è sempre stato legato alla profondità, non alla superficie, e che il rischio attuale è premiare chi si innamora troppo degli strumenti, anche quando il problema vero è il prodotto o il business.
A volte i programmatori amano troppo il codice o gli strumenti che usano.
14:46
Si concentrano su quello più che sul business.
14:55
L’ultima parte è quasi una teoria della carriera. White racconta di aver guadagnato molto dal suo periodo da copy-paste programmer, dal lavoro ripetitivo su Google e dai video su LeetCode, perché ogni volta ha accettato un compromesso diverso invece di inseguire una purezza professionale.
Io ero un programmatore copia e incolla.
10:22
Cerco di andare in profondità e di essere il migliore che posso, a modo mio.
17:29
Nel suo racconto, la gratificazione non sparisce, ma va riposizionata. Al posto dell’idea romantica del programmatore innamorato del mestiere, White propone quella di chi impara a riformulare il proprio lavoro come esercizio di disciplina, impatto e indipendenza.
Se non abbracci il cambiamento, finirai piuttosto depresso perché il mondo cambia sempre.
18:09
Perché White dice di non amare programmare?
Per White, la programmazione non è mai stata una passione pura: è entrato nel settore per soldi e poi ha imparato ad apprezzarne solo alcuni aspetti, come la logica dei primitivi.
Secondo lui, LeetCode serve davvero nel lavoro?
Secondo White, serve meno di quanto suggeriscano i colloqui tecnici. Però le strutture mentali allenate con DSA e problemi logici lo hanno aiutato a ragionare meglio sul lavoro.
Perché critica tanto il web development?
Perché lo vede come un mondo incoerente e pieno di nomi che non corrispondono alla funzione reale, come nel caso di XHR.
Cosa pensa dell’AI coding?
White la vede come un cambio di forma, non come una fine del mestiere. Per lui, però, la gratificazione diminuisce per chi amava scrivere codice a mano.
Qual è la lezione principale della sua carriera?
La lezione, per White, è che adattarsi conta più dell’idealizzare il proprio lavoro. Dice di aver costruito la carriera scegliendo il pragmatismo e la profondità quando servivano.
Sintesi assistita dall'AI del podcast di NeetCode, verificata sulla trascrizione originale.