Le domande che ci facciamo ancora

Qualcosa è cambiato in ciò che gli sviluppatori si chiedono a vicenda, e me ne sono accorto prima di tutto nel mio comportamento. Per oltre un decennio, tra team enterprise e startup, le domande che circolavano tra le persone erano dominate dalla meccanica. Perché questa regex non matcha. Cosa significa davvero questo errore. Come faccio a far andare d'accordo queste due librerie su una versione. Le ho fatte, ci ho risposto, e a un certo punto negli ultimi due anni ho smesso di fare entrambe le cose, perché ora una macchina risponde in pochi secondi, a qualsiasi ora, senza far sentire nessuno sminuito per aver chiesto. Le domande che passano ancora tra le persone si sono fatte più rare, e si sono fatte più pesanti.

Il vecchio traffico non mi manca. Rispondere alla stessa domanda meccanica per la quarantesima volta non è mai stata la parte bella di questo mestiere, e avere una macchina instancabile che se ne fa carico è un regalo. Ma osservare quali domande attraversano ancora lo spazio tra le persone, dopo che tutto il resto ha smesso di averne bisogno, mi ha insegnato qualcosa su dove si sta spostando il valore di uno sviluppatore. Tre tipi fanno ancora il viaggio, e non sono ugualmente durevoli.

Più nuove del training

Il primo tipo nasce più in fretta di quanto qualsiasi modello possa imparare. Una release esce un martedì e già mercoledì si rompe in modi che nessuno ha documentato, perché nessuno ci ha convissuto abbastanza a lungo per documentarli. Scrivo codice con due modelli diversi, ogni giorno, e nel momento in cui uno strumento mi si aggiorna sotto le mani, entrambi smettono di essere saggi e cominciano a tirare a indovinare con sicurezza, senza cambiare tono di una virgola. Riconoscere quel passaggio, ormai, è una competenza.

L'obiezione ovvia è che i modelli navigano. Possono recuperare release notes e thread di issue su richiesta, e questo ha ristretto parecchio la finestra. Ma il retrieval legge testo, e nei primi giorni dopo una rottura quel testo non esiste ancora. La conoscenza vive nella testa delle cinquanta persone che hanno sbattuto contro lo stesso muro nella stessa settimana, e nei messaggi che si scambiano quando si trovano. Per quel pugno di giorni, quelle persone sono l'unico posto in cui la risposta esiste. Tutto ciò che la macchina finirà per sapere su quella rottura deve prima passare da loro, perché qualcuno deve scrivere una cosa prima che qualsiasi sistema possa recuperarla. La finestra continua a restringersi, ma ogni release la riapre da zero, quindi le domande che ci vivono dentro continuano ad avere bisogno di una persona. Solo che non è mai la stessa persona a lungo.

Più a fondo di una risposta plausibile

Il secondo tipo va in profondità invece che in avanti. L'angolo buio di un compilatore. Il paragrafo di una specifica che due implementazioni leggono in modo diverso. La domanda in cui una risposta plausibile è inutile, perché serve una risposta dimostrabilmente corretta, con la sua provenienza, da qualcuno che sappia indicare la clausola esatta che decide la questione. Quando qualcuno chiede perché l'ottimizzatore può riordinare quelle due scritture, non sta chiedendo un paragrafo che suona come documentazione. Sta chiedendo il memory model, capitolo e versetto.

Qui devo chiarire la mia posizione, perché gioca contro di me. Ho passato buona parte degli ultimi anni a lavorare su sistemi di retrieval per l'ambito legale e sanitario, dove una risposta che non sa mostrare la propria fonte non vale niente, per quanto bene suoni, e tutto lo sforzo di ingegneria va nel fissare ogni affermazione al documento su cui poggia. Quel lavoro è una scommessa sul fatto che questa categoria si possa automatizzare, e la scommessa sta andando bene. Una macchina che risponde con la clausola esatta allegata non è una fantasia; è più o meno la descrizione del mio lavoro. Quindi dei tre tipi, questo è quello che mi aspetto continui a restringersi. Lo specialista che conosce la specifica a menadito manterrà il vantaggio negli angoli in cui i documenti si contraddicono, e nelle domande che i documenti non hanno mai previsto. Ma non ho intenzione di costruire un articolo su un fossato che passo le mie giornate a prosciugare.

La domanda che riguarda te

Il terzo tipo suona come il meno tecnico e si rivela il più durevole. Dai un'occhiata al mio progetto. Quale di questi strumenti per il mio team, vista la nostra codebase, la nostra scadenza e le due persone che poi questa cosa la manterranno davvero. Tu cosa faresti.

Fai queste domande a un modello e ottieni qualcosa di davvero utile, una mappa dello spazio delle opzioni con tutti i tradeoff messi in fila. Insisti e arriverà perfino a sceglierne una, quindi non fingerò che la macchina si rifiuti di decidere. Quello che non può fare è pesare i tradeoff come li pesano le conseguenze vissute, e credo che il motivo sia concreto, non mistico. Il materiale scritto su cui la macchina ha imparato è distorto. I fallimenti clamorosi ricevono un postmortem; quelli lenti no. Nessuno scrive un incident report intitolato "questa libreria era leggermente sbagliata per il nostro team e ci è costata tre ore a settimana per due anni". La persona che ha mantenuto la cosa che un tempo aveva raccomandato porta con sé esattamente quel dato mancante: quali tradeoff della mappa hanno fatto male davvero, quanto forte, e quanto è durato il livido. Quando comprime lo spazio delle opzioni in una decisione per la tua situazione, è quel dato mancante a fare la compressione.

C'è una lettura meno lusinghiera di tutto questo, e in parte la concedo. Alcuni di quelli che chiedono "tu cosa faresti" cercano una copertura più che un consiglio, un nome da indicare se la scelta va storta. Ma anche quella è una richiesta che nessuna macchina può soddisfare, perché un modello non lo puoi indicare. E la versione migliore dello stesso istinto è sana. Vogliono che la decisione arrivi da qualcuno che paga un prezzo se sbaglia, almeno in reputazione, perché un consiglio che non costa niente a chi lo dà è facile darlo con leggerezza.

L'inversione

Quindi la macchina si è presa il centro. L'intero archivio di meccanica già risolta ora sgorga da un prompt all'istante, e da dove mi trovo io, il traffico di quelle domande tra le persone si è ridotto quasi a zero. Ciò che circola ancora pende decisamente verso l'ultimo tipo, le richieste di gusto, di consiglio, di giudizio.

È un ribaltamento su cui vale la pena fermarsi, perché la nostra cultura ha addestrato gli sviluppatori a trattare proprio quelle domande come domande minori. Se chiedevi cosa avrebbe scelto qualcuno, il riflesso era liquidare la richiesta come pura opinione, non una vera domanda, dato che non aveva una risposta verificabile. Il riflesso aveva un suo senso. Le decisioni soggettive le riservavamo alle persone pagate per prenderle, i tech lead e gli architetti, e tra pari davamo valore alle domande che i fatti potevano chiudere.

Le domande che i fatti possono chiudere ora le chiude una macchina prima ancora che arrivino a una persona. Ciò che resta è il tipo senza risposta verificabile, il tipo che una volta veniva liquidato. È passato dall'essere il rumore nel canale alla maggior parte di ciò che il canale trasporta. E le persone che continuano a porlo sanno benissimo come funziona tutto questo. Hanno identificato correttamente la cosa che non possono ottenere da un prompt, e la stanno chiedendo all'unico posto in cui esiste.

Diventa qualcuno a cui vale la pena chiedere

Dovrei dire da che parte sto. Costruisco una parte del macchinario sul lato a buon mercato di questo scambio, strumenti che generano codice e risposte tutto il giorno, e ognuno di essi finisce davanti a un essere umano che deve prendere una decisione che lo strumento non può prendere al posto suo. Quando dico che il valore si è spostato verso la persona disposta a decidere, sto descrivendo il punto esatto in cui i miei strumenti si fermano.

Per uno sviluppatore, la domanda pratica viene di conseguenza. Sei qualcuno a cui vale la pena chiedere? C'è un angolo di questo campo in cui hai convissuto con le tue scelte abbastanza a lungo perché lì il tuo giudizio pesi qualcosa?

E quando la domanda arriva, rispondi con il ragionamento, non solo con il verdetto. Un verdetto invecchia alla release successiva, ed è l'unica parte della tua risposta che chi chiede avrebbe potuto ottenere da un prompt. Quello che non può ottenere da un prompt è la pesatura: come hai confrontato le opzioni, cosa ti è costato quando hai scelto male, a cosa staresti attento adesso. Consegnare anche quello è ciò che rende migliore chi chiede, e un giorno lo rende a sua volta qualcuno a cui vale la pena chiedere.

Non sosterrò che questa finestra reggerà per sempre. Ogni altra finestra di questa storia si è spostata, e potrebbe spostarsi anche questa. Ma oggi, quando qualcuno ti porta il suo progetto e ti chiede cosa faresti, nota cosa è successo. Aveva una macchina che risponde a tutto, e la domanda l'ha portata a te. Prendila sul serio, e rispondi lasciando in vista le tue ragioni.