Sui programmatori 10x

C'è questa vecchia e un po' stantia discussione sui programmatori 10x. O esistono, o è un mito delle startup, o sono semplicemente manager che fantasticano su «assumiamo un mago invece di una squadra». In presentazioni, post e conversazioni questo tema tornava regolarmente, di solito da qualche parte accanto a «ci servono persone forti», «abbiamo una piccola squadra» e «la scadenza era ieri» — e sullo sfondo degli agenti IA è rifiorito selvaggiamente da capo.

Quello che mi ha sempre dato fastidio di questo tema è che si cerca di stipare assolutamente tutto dentro il «10x»: velocità di scrittura del codice, capacità di correggere bug, conoscenza del progetto, capacità di non danneggiare il progetto, esperienza nel comunicare con il management, gusto architetturale ed esperienza navigata, disponibilità a fare le nottate e un buff di fortuna. E poi da tutto ciò si costruisce una bella leggenda su una persona che lavora dieci volte più velocemente di tutti gli altri.

I sogni di un PM restano comunque solo sogni, e nella vita reale tutto è più opaco e allo stesso tempo più interessante. Ho visto persone che davvero portavano a termine i compiti molto più velocemente di altri. L'ho visto nell'open source, nei progetti di gioco, sul codice vecchio, nelle piccole librerie. Ma quasi sempre il motivo non era che la persona fosse nata con un coefficiente x10 e un buff alla velocità di battitura delle lettere, bensì che dietro alla sua velocità c'era un capitale accumulato — come la conoscenza del progetto, di uno strumento, una competenza di nicchia, o anni passati a scavare in compiti simili.

La persona fusa con il progetto

Il tipo più ovvio di programmatore «10x» è la persona che semplicemente conosce il progetto meglio di chiunque altro. Sì, esistono anche loro. Di solito sono fedeli e con i capelli grigi. Nelle vecchie basi di codice o nei vecchi progetti sembra quasi magia: entri in Slack a chiedere di un bug, e un paio di minuti dopo arriva una risposta che dice in quale file guardare e cosa correggere. Raro, ma capita. Oppure dici «il comportamento della finestra si è rotto su questa e questa transizione», e la persona si ricorda che tre anni fa lì c'era un hack per un'altra schermata, poi è stato aggirato con un flag, poi qualcuno ha aggiunto un'eccezione per il tutorial. E sì, molto probabilmente hanno di nuovo ragione.

Nei vecchi progetti di gioco questo si nota in modo particolare, e i giochi «con un'eredità» mostrano rapidamente che «conoscere il C++» e «conoscere il progetto» sono due cose molto diverse. Puoi essere un programmatore eccellente ma passare il primo mese o due semplicemente a camminare attraverso un campo minato di vecchi formati, strane dipendenze, decisioni storiche e comportamenti che i giocatori ricordano meglio della documentazione.

E qui la velocità appare non da qualche abilità astratta, ma semplicemente dalla memoria. Sai già dove vive la UI, dove sta la simulazione, dove sono i salvataggi, dove è «meglio non toccare se non vuoi rompere mezzo livello». E persone del genere spesso ricordano anche che questo controllo sembra ridondante, ma senza di esso uno scenario si rompe. Sanno che il pathfinding si comporta in modo strano non perché sia stato scritto male, ma perché dieci anni fa bisognava allungare il frame, e i giocatori ci si sono già abituati.

Questo non riguarda il 10x — la persona ha semplicemente pagato con il proprio tempo, nel corso di diversi anni, la capacità di correggere le cose più velocemente ora. Il problema è che non puoi semplicemente assumere una persona del genere dalla strada, e farla crescere all'interno del progetto è anch'esso problematico — non tutti sono disposti, vogliono, o possono. E se ce n'è solo una, il progetto ottiene contemporaneamente un superpotere e un enorme bus factor, dove tutta la magia poggia su una persona, sulla sua memoria e sulla sua disponibilità a continuare.

Semplicemente un programmatore veloce

C'è un secondo tipo di efficienza — non scrivere più codice, ma scriverne di meno. Potresti dire che suona banale, ma nel gamedev, specialmente nel gamedev, molto tempo brucia nel tentativo di costruire il sistema «giusto» prima ancora che sia chiaro se serva davvero. È iniziato con una piccola feature, e una settimana dopo abbiamo già una plugin API, la nostra serializzazione, una factory astratta di factory e un TODO per «rifattorizzare più tardi».

È una malattia, non so come si chiami, e più vecchio è il progetto, più hotspot di questo tipo ha. Ce ne sono particolarmente tanti tra i tool e la UI. Sembra che, ora, lo scriveremo in modo bello, universale, per il futuro. E poi salta fuori che il futuro in quella forma non è mai arrivato, ma ora devi mantenere l'universalità.

Uno sviluppatore veloce semplicemente fa di meno. Da qualche parte hardcoda, da qualche parte mette un hack, da qualche parte lo sposta in una config, da qualche parte non fa proprio nulla. Questo tipo di pigrizia professionale è già un'abilità — una che si testa male in un colloquio ma è molto visibile dopo un mese o due di lavoro sul progetto.

DoItProperlyMan

Se ti dedichi molto all'open source, col tempo arrivi a capire che il codice in un progetto è il 20% del contributo al progetto.

Hai bisogno che il progetto compili, che il README non menta, che una nuova persona riesca a superare almeno i primi dieci passaggi senza stregonerie. Hai bisogno che una pull request sia revisionabile, non un indovinello su cosa intendesse l'autore. Hai bisogno che le issue non si trasformino in una palude di «a me non funziona» senza versione del compilatore, OS e log.

Ed è qui che appare un altro tipo di persona «10x». Potrebbero non scrivere il maggior numero di righe di codice, ma sanno come districare il caos. Sanno spiegare dove mettere una modifica. Sanno dire «questo non va qui». Sanno spezzare un grosso compito in tanti piccoli. Sanno fare in modo che la persona successiva non passi una serata sulla build.

Una persona del genere spesso non entra nella mitologia dei 10x, perché non assomiglia affatto a un eroe che ha scritto un nuovo sistema in una notte. Ma spianano la strada su cui poi corrono tutti gli altri, e senza di loro quegli altri inciamperebbero «eroicamente» ogni dieci metri.

Competenza di nicchia

A volte la specializzazione ristretta dà davvero il 10x — per esempio, quando una persona ha conoscenze rare; spesso questo si sovrappone al primo punto. Vecchie basi di codice, formati di dati personalizzati, specificità del rendering, bug delle librerie UI, stranezze dei sistemi di build, bug delle piattaforme, e così via all'infinito. Sono tutte aree in cui una persona esperta può fare in un giorno ciò che un'altra impiegherebbe una settimana o più, giusto per capire da che parte guardarlo.

Se sai già leggere i vecchi formati, capisci come sono disposti i dati e non hai paura del codice dei primi anni 2000, allora parti già non da zero. Sai già che un gioco può essere logico all'interno della propria stranezza e che un bug a volte è una feature storica. E anche che «migliorare» non sempre significa renderlo migliore, e semplicemente spendi meno tempo sugli unknown unknowns. E non perché sai tutto, ma perché capisci più in fretta dove guardare.

La competenza è conoscenza moltiplicata per memoria moltiplicata per esposizione e comprensione del dominio. Questo include il C++, e l'architettura, e la conoscenza di un progetto specifico, e la comprensione dei sistemi di gioco. E spesso una persona tira fuori un bug più velocemente con la competenza che con la conoscenza. Due programmatori con la stessa esperienza ma competenza diversa possono arrivare a risultati diversi semplicemente perché hanno lavorato su progetti diversi.

Il mito del focus

C'è un'idea diffusa secondo cui i programmatori forti semplicemente si concentrano meglio su ciò che conta. La verità qui, come al solito, è a metà. Sì, la capacità di scegliere un compito importante è anch'essa preziosa, ma qualcuno deve pur fare anche i compiti non importanti. Riparare la build, per esempio, o aggiornare le dipendenze. Fare il triage dei piccoli bug. Scrivere esempi. Rispondere alle domande. Ripulire la spazzatura. Portare i nomi a una forma unica. Insomma, fare il lavoro noioso senza il quale il progetto non sembra nemmeno finito.

Il problema è che una tale fatica si vende male come «10x», e per di più non sembra eroica, ma per il giocatore è del tutto irrilevante quanto eroicamente e concentratamente hai chiuso gli ultimi due ticket — sono proprio questi piccoli dettagli che spesso separano un progetto vivo da un «beh, carino, ma doloroso da usare».

Il 10x probabilmente esiste, dopotutto, solo non nel modo in cui lo vorremmo

Non penso che un programmatore 10x sia una persona che entra in qualsiasi progetto e comincia subito a fornire dieci volte più valore. Questo accade solo nelle fiabe, negli annunci di lavoro aperti e nelle presentazioni motivazionali. Ma credo abbastanza nelle persone che diventano 10x in un certo contesto. In una base di codice o un dominio specifico, in una squadra specifica o un particolare tipo di compito. In un progetto su cui si sono arrampicati con le mani, con gli occhi e con il sedere.

Purtroppo, dietro a tutto ciò c'è il tempo: anni di esperienza, decisioni sbagliate, sistemi riscritti, branch abbandonati, bug notturni, utenti strani, build rotte, e la comprensione che a volte il codice migliore è il codice che non hai scritto. Quindi se vuoi cercare i «10x», io cercherei non maghi, ma persone capaci di fare tre cose: capire velocemente il contesto, scegliere correttamente la scala di una soluzione, e lasciare il progetto in uno stato in cui non ti vergogni di tornare.

Questo è meno bello del mito del superprogrammatore. Ma è molto più vicino a come vivono davvero i grandi progetti — e in realtà qualsiasi progetto che sia sopravvissuto a un anno di sviluppo.