Mentore prolifico e automatizzatore di sistemi

Jonathan: Ciao a tutti e benvenuti all'Exercism Community Podcast. Ho l'onore di avere qui con me Isaac, uno dei nostri maintainer e contributori, che recentemente ha fatto tantissimo mentoring con moltissimi studenti nei nostri GoHort, le nostre coorti di apprendimento, che abbiamo portato avanti per 30 giorni, credo due volte ormai, soprattutto su Go ed Elixir. E Isaac ha dato una mano sul track di Go, ed è stato fantastico. Allora Isaac, un grande benvenuto a te. Ti va di raccontarmi un po' dove vivi, da dove vieni e come sei arrivato nel settore tech?

Isaac: Sì, vivo in California. Abito a San Jose, in California. La verità, onestamente, è che sono arrivato al settore tech perché mio fratello maggiore era nel tech e io facevo tutto quello che faceva lui. Avevo un sacco di fratelli e sorelle. Ci piaceva stare insieme, o ad alcuni di noi piaceva stare con certi più che con altri. Avevo un fratello maggiore con cui mi piaceva davvero passare il tempo. A lui non piaceva necessariamente stare con me altrettanto, ma io gli stavo molto dietro e volevo fare qualunque cosa stesse facendo lui. A circa 15 anni ha preso in mano un libro «C for Dummies» che girava per casa, e io ne avevo 9, se non ricordo male. Quindi lui scriveva in C, e io pensavo: se lo fa lui, lo faccio anch'io. A quell'età i miei programmi erano piuttosto semplici ed elementari. Erano più del tipo: come ti chiami, ciao Bob. Non erano troppo complessi. Bisogna pur cominciare da qualche parte. Bisogna cominciare da lì. Pensavo: oh, puoi stampare un carattere speciale e fa un suono. Fortissimo. Ho scritto un programma che letteralmente stampa soltanto uno «slash A». Ma avevo iniziato a 9 anni. Scrivevo programmi in C. Avevamo una vecchia macchina con Windows 3.1 che si avviava in DOS, e poi mio fratello aveva creato uno script batch che all'avvio del computer mostrava un menu da cui potevi scegliere, tipo avvia Windows, avvia i giochi, c'era tipo un menu dei giochi. Potevi digitare 5 per Warcraft o quello che era. Quindi scrivevo script batch, dato che avevamo altri giochi installati e via dicendo. Da lì è andata sempre in discesa. Mio fratello è andato all'università a studiare ingegneria informatica e, di nuovo, io pensavo: se lo fa lui, lo faccio anch'io. Così ho iniziato a scrivere in C a 9 anni. Alle superiori scrivevo... Visual Basic 6. Avevo un Palm Pilot su cui scrivevo vari programmi alle superiori. Il mio professore di matematica era davvero in gamba. Ero in una di quelle vecchie scuole...

Jonathan: Era quella specie di... ti ricordi quando hanno provato a lanciare la cosa pre-iPad e in pochi l'hanno avuta, e aveva quella specie di penna che scribacchiava. E tutti pensavano fosse super figo perché usciva fuori, faceva «zoop», e poi potevi toccarlo. Era... non ha... me lo ricordo sempre perché poi è arrivato l'iPad e tutti dicevano: ah, un po' in anticipo. Il Pilot era proprio quello, un po' avanti rispetto ai tempi, mi capisci?

Isaac: È stato fantastico per un decennio o giù di lì, ma sì, c'era il Graffiti di Palm che usavi per inserire il testo. C'è un piccolo riquadro di input e dovevi scrivere i caratteri, ma erano tipo basati sull'alfabeto. Tipo la A era semplicemente un triangolo e la F era tipo l'angolo retto. Sì, il mio professore di matematica delle superiori ha detto: ehi, se hai scritto il programma, va benissimo se vuoi usarlo durante il compito. Quindi alle superiori scrivevo programmi per il Palm Pilot, che era davvero figo. Sono andato all'università a studiare ingegneria informatica. Sentivo gente parlare di linguaggi di scripting. Non sapevo bene cosa fossero, così ho preso in mano Perl a caso. Poi, finita la scuola di specializzazione, sono andato e mi ha assunto Google. Nel 2013 mi hanno trasferito dalla costa Est alla California. Ed è lì che ho imparato Python, circa dieci anni fa. E Python è il mio linguaggio principale da dieci anni. Ho lavorato in Google, quindi il mio stile è molto influenzato dallo stile Google. Ed è per questo che ho scritto principalmente in quel modo. E poi circa... quattro anni fa, credo nel 2018 o giù di lì, Google ha iniziato a spingere internamente il linguaggio Go e io in quel momento ho imparato Go.

Jonathan: Fico. E Isaac, quando parli di stile Google, c'era un'idea condivisa di quale fosse il modo giusto di fare le cose, oppure... com'è andata? Approfondisci un po' questo punto, perché è interessante.

Isaac: Lo stile di programmazione non è necessariamente il modo corretto di fare le cose, quanto piuttosto un modo uniforme che tutti devono seguire. Dicono che un buon compromesso, o un buon accordo, è un accordo in cui nessuno è contento. Nessuno è del tutto soddisfatto della guida di stile, ma finché tutti la seguono, il codice appare uniforme. Questo significa che chiunque può prendere un pezzo di codice qualsiasi nella codebase di Google e modificarlo, e finché segue le stesse linee guida di stile, il codice è tutto uniforme: non devi stare a pensare che questa codebase usa rientri di quattro spazi e quell'altra di due, o che qui le convenzioni di denominazione sono in un modo e là in un altro. Tutto quanto, in tutta la codebase, è fatto allo stesso modo. A nessuno va bene tutto. Ognuno ha i suoi punti in cui vorrebbe che fosse fatto diversamente, ma dato che esiste una guida di stile documentata, disponibile pubblicamente, basta cercare su Google «Google Python style guide» e ti dice come si scrive il codice in Google. Finché tutti restano fedeli a quella guida, il codice appare molto uniforme, il che è davvero bello: apri qualsiasi codebase e non ci sono sorprese, tipo «ah, loro lo scriverebbero diversamente».

Jonathan: È per questo che Go forse si inserisce così bene in quel contesto? Perché è formattato e dice davvero: è così che si fa. L'influenza di Google si vede eccome.

Isaac: Sì, non so quanto Rob Pike sia stato influenzato dall'approccio di Google o quanto sia stato lui a influenzare l'approccio di Google. Non sono sicuro di quale abbia portato all'altro, ma Go porta decisamente la cosa a un altro livello, dove... Ce ne sono ancora di più: con Python, per esempio, ci sono stili diversi e la gente modifica i propri linter per accettare cose diverse. Per esempio, internamente Google usa rientri di due spazi in Python, perché c'è molto codice annidato in profondità e non vogliono ritrovarsi con un muro enorme di spazi. All'esterno, quasi tutti usano quattro spazi, ed è quello che è scritto nella documentazione di Python. Ma sì, quando si tratta di Go, hanno semplicemente portato tutto a un altro livello e hanno detto: il linguaggio stesso ha anche la formattazione. C'è un solo modo di formattare. Non ci sono framework online su quale sia il modo corretto. C'è solo un modo.

Jonathan: Fa risparmiare un sacco di battibecchi, diciamo così. Sì. Bene.

Isaac: Sì.

Jonathan: Allora, quando hai iniziato in Google, non avevi mai fatto Python, o ne avevi solo assaggiato, o è stato un passaggio facile? Perché l'hai raccontato come se avessi ottenuto il lavoro in Google e poi fosse stato tipo: ok, bene, impariamo Python e via.

Isaac: Esatto. Credo che prima di entrare in Google non avessi mai scritto Python. Scrivevo in Perl da un anno o due. Credo un paio d'anni a quel punto, avevo iniziato a scrivere in Perl. Il mio primo lavoro estivo... è tutta un'altra storia. Ho iniziato a scrivere in Perl sei anni prima di entrare in Google, quindi a quel punto ne scrivevo parecchio. Scrivevo anche un po' di Bash, quindi conoscevo i linguaggi di scripting. Ma non avevo mai scritto Python. Però, una volta che hai smanettato con abbastanza linguaggi... la curva di apprendimento è un po' meno ripida quando ne impari un altro, perché hai già visto quasi tutte le costruzioni e cambia solo un po' la sintassi, un po' il set di strumenti. Ma è tanta roba vecchia e conosciuta, solo scritta un po' diversamente, in modo diverso. Le costruzioni tendono a essere piuttosto simili. Quindi, una volta che hai imparato quattro linguaggi, impararne un quinto è tipo: ah, questo è solo scritto un po' diversamente.

Jonathan: Sì, sì. Interessante. Allora, hai riso un po' del tuo primo lavoro, tipo appena uscito dalle superiori. Quindi adesso tu... perché è... avevi sempre pensato: io farò ingegneria, io farò la cosa del computer. Era sempre stato un pensiero consapevole, oppure era semplicemente il posto in cui ti trovavi naturalmente e ti piaceva, tutto qui? Come è andata...?

Isaac: Credo di sì. Cercavo molto di seguire le orme di mio fratello. Lui è andato a ingegneria informatica. Ha iniziato a scrivere programmi. Ha iniziato a programmare quando io ero bambino. Io seguivo. Scrivo programmi da quando ero piccolo. Lui è andato a ingegneria informatica ed era quello, sai, volevo fare la stessa cosa che faceva lui, e per di più mi divertivo un sacco a scrivere programmi e tutto quanto. Quindi, da quando ho iniziato le superiori, quando mio fratello era già all'università, sapevo che era lì che volevo arrivare.

Jonathan: Quindi lui ha qualche anno più di te, e sembra che abbia avuto un'influenza enorme su di te come persona. Quanti altri fratelli e sorelle hai? O era il numero uno ai tuoi occhi?

Isaac: Ho otto fratelli e sorelle, ma lui era sicuramente quello con cui andavo d'accordo davvero. È uno di quelli... credo di andare d'accordo con alcuni meglio che con altri. Quando ne hai otto, c'è sempre una gamma. Con lui andavo d'accordo molto bene. Tendiamo a pensare molto in modo simile. Tendiamo ad avere interessi simili. Fare i nerd sui computer era la nostra passione costante, e lo è ancora. A sua moglie non piace quando diventa la conversazione a tavola. Dice: niente lavoro a tavola. Noi parliamo di programmazione di continuo, ne parliamo sempre. È davvero difficile dire quanto fosse solo io che volevo copiarlo e quanto fossimo semplicemente noi con interessi simili. Di sicuro ora abbiamo interessi simili. Non so quanto di questo sia natura e quanto cultura. Non posso davvero dire quanto sia io che lo copio e quanto sia semplicemente il fatto che abbiamo interessi simili. Ma dato che seguivo le sue orme fin da piccolo, io seguivo e lui in qualche misura tracciava il percorso, e io lo seguivo.

Jonathan: Sì, davvero bello. E lui? Dov'è adesso? Per curiosità, è sulla costa Est?

Isaac: È ancora sulla costa Est, lavora nel settore tech. Abbiamo lavorato brevemente nella stessa azienda.

Jonathan: Ah, ok, fico. Quindi c'è questo. Bello. Volevo solo chiederlo. Ora, una delle cose... tu sei stato davvero coinvolto nella coorte che abbiamo appena concluso. L'ultima coorte di apprendimento, soprattutto con Go: abbiamo fatto una cosa di 30 giorni con Go. Come... e poi il tuo coinvolgimento con Exercism in precedenza è stato più che altro nella manutenzione, ma anche parecchio nel mentoring, per quanto ho capito. Come hai vissuto questa divisione? Cioè, come sei arrivato a Exercism e quali sono i diversi aspetti in cui ti piace contribuire?

Isaac: Sono arrivato a Exercism perché stavo cercando di rimettermi a studiare Haskell. Avevo seguito un corso Haskell 101 in Google, che è stato molto divertente. Poi ho pensato: dovrei dedicarci più tempo. E poi l'ho lasciato perdere. E poi ho provato a riprenderlo.

Jonathan: e ci vediamo la prossima volta.

Isaac: Con qualsiasi linguaggio, trovo che il modo più facile per impararlo sia scriverlo davvero. Il modo più facile per scriverlo è avere uno scopo per farlo. Non ho trovato un buon scopo per scrivere in Haskell, il che lo rendeva davvero difficile da imparare. Ma ho scoperto Exercism e ho pensato: oh, questo potrebbe aiutarmi a scrivere più Haskell. Ecco come ho scoperto Exercism. Una volta lì, ho pensato: oh, c'è il track di Python, il track di shell e un sacco di esercizi qui dentro, quindi... non so, giù nella tana del coniglio?

Jonathan: E giù nella tana del coniglio sei finito.

Isaac: Sì. Ho iniziato a risolvere esercizi in Python. Ho iniziato a risolvere esercizi in Bash. Ho fatto un paio di esercizi in Go. Quando è arrivato il GoHort e ho guardato alcune delle mie soluzioni precedenti, ho visto che molte erano state inviate tre anni prima. Quindi sì, mi ero iscritto al track di Go nel 2019 e allora avevo risolto una parte di quegli esercizi. E poi a questo punto facevo Python da un decennio. Quindi mi sentivo relativamente a mio agio a entrare come mentore di Python, che è dove passo la maggior parte del mio tempo sugli esercizi in questi giorni. Poi ho iniziato a inviare PR, pull request, al track di Python, perché c'erano cose fuori posto. Poi ho iniziato a coinvolgermi nel track di Bash. E non sono del tutto sicuro di come sia successo, ma sono passato dall'inviare correzioni al track di Bash a essere un maintainer di Bash.

Jonathan: Proprio così, cioè, attento a quello per cui ti iscrivi, no?

Isaac: Sì, e poi Glenn ha creato il track di Ock e io ho pensato: oh, conosco Ock, mi piace Ock, salto anch'io su quel carro. Così ho aiutato a costruire gli esercizi del track di Ock. Non ne sono del tutto certo, ma credo che tre anni fa, quando ho visto gli esercizi di Go, ho completato l'intero track e poi uno dei mentori ha detto: oh, hai finito tutti gli esercizi, forse dovresti diventare mentore. Non sono abbastanza... non scrivo Go abbastanza spesso, né con abbastanza regolarità, per sentirmi a mio agio a fare mentoring. Quindi non ero davvero un mentore di Go. Ma poi, quando mi sono unito al GoHort e c'erano un sacco di persone che volevano mentoring, ho pensato: oh, credo di potermi iscrivere per fare il mentore per un mese e dare una mano. In realtà recentemente mi sono unito al GoHort come studente. E poi sono scivolato dalla sezione studenti, credo.

Jonathan: Sono andato e sono scivolato dalla sezione studenti, credo. Attento a quello per cui ti iscrivi, ti dico. Sembra emergere uno schema: ti iscrivi per una cosa e finisci per essere un'altra, ma è davvero bello. Ok, allora, quando hai fatto mentoring con gli studenti sul track di Go nello specifico, quali sono alcune delle cose più comuni che vedi? Cioè, sul track di Go probabilmente ci sono parecchi sviluppatori esperti, direi, che l'hanno fatto, persone con un po' di esperienza nello sviluppo, ma quali sono state alcune delle cose che hai notato, quelle su cui la gente sembra bloccarsi? C'erano degli schemi ricorrenti, cose che trovavi e dicevi: ok, questa è comune, compare abbastanza... costantemente, potenzialmente.

Isaac: Non lo so. Non ho visto... gran parte del mentoring che ho fatto riguardava persone con soluzioni già completate. Più spesso che no, le persone hanno risolto l'esercizio prima di chiedere mentoring. Quindi nella maggior parte delle interazioni la gente non è bloccata. È più che altro che hanno completato con successo un esercizio e poi gran parte del contributo è: c'è un modo più efficiente di farlo? C'è un algoritmo migliore? Una di quelle che saltano fuori fin troppo spesso è la costruzione di stringhe in... In linguaggi come Go e Python, dove le stringhe sono immutabili, fare tanta concatenazione di stringhe non è molto efficiente. Quindi è molto: ehi, potresti costruire questo usando un array e poi unire le stringhe, oppure puoi usare uno string builder in Go. Quindi c'è molto spingere verso pattern migliori, diciamo, buone pratiche e pattern. Grazie per la visione.

Jonathan: Ok, bello. Affascinante. Allora, attualmente, come sono le tue giornate di lavoro, dove si colloca lo sviluppo? Hai detto che sei nel settore tech da un po': com'è la giornata? Quali sono le sfide? Quali sono le parti del lavoro che ti piacciono in questo momento?

Isaac: Allora, ho un ruolo di site reliability engineering, che è più o meno simile al DevOps. C'è dentro anche un po' di amministrazione di sistema. Porto un cercapersone in una rotazione di reperibilità da circa un decennio. Quindi le mie giornate dipendono molto dal fatto che sia o no la mia settimana di reperibilità. Quando sono reperibile, è molto stare a guardare il cercapersone, c'è una coda di ticket, una coda di supporto, assicurarsi che eventuali processi in errore o problemi siano diagnosticati e risolti. È circa una settimana su sei, o quante sono in totale nel team in quel momento. E per il resto del tempo sono in reperibilità.

Jonathan: Mm-hmm.

Isaac: Passo molto tempo a pasticciare con l'automazione, quindi è molto identificare processi macchinosi e renderli meno macchinosi. Può darsi che... ci sia una ragione perché accada, ma in genere trovo che finché qualcosa non inizia... quando succede questo problema, dobbiamo eseguire, sai, riparare manualmente con questi comandi e quei comandi, e allora: perché eseguiamo questi comandi a mano? Possiamo scrivere uno script Python che faccia tutto questo al posto tuo? Oppure possiamo migliorare gli strumenti perché non falliscano e intercettino da soli quel problema? E molto è solo cercare di migliorare il quotidiano, come gestiamo i sistemi, in modo che gli esseri umani siano meno coinvolti o non debbano essere così... così profondamente coinvolti per far funzionare tutto senza intoppi.

Jonathan: Quindi la tua giornata... ti piace cercare quelle piccole aree in cui le cose si possono ottimizzare? Quanta parte del tuo lavoro è reagire alle cose e poi, dalla reazione, pensare: oh bello, questa è un'opportunità, e quanta è cercare proattivamente quelle piccole aree? Qual è di solito l'equilibrio?

Isaac: L'automazione mi piace, probabilmente è la cosa che mi piace di più del mio lavoro: poter automatizzare le cose. Non è sempre reattivo. Voglio dire, reattivo può significare che qualcosa si rompe, ma anche: oh, sai, la gente esegue questo comando, ho scoperto che c'è questo comando che tendiamo a copiare e incollare, posso migliorarlo? Oppure vedo qualcuno che modifica un runbook da qualche parte o migliora un comando, e penso: oh, quel comando è piuttosto disordinato, posso riscriverlo da zero? E naturalmente l'attenzione è troppa, deve essere bilanciata con l'appeal, devono esserci parole meno grosse, un linguaggio migliore, quel genere di cose. Devi venirne a capo provando a farlo. Onestamente, tutto nel mio lavoro torna davvero, se ci penso. Sono una persona molto motivata, no, il mio lavoro credo sia lì... dovunque... ma in qualsiasi lavoro che amo, ammazzare il tempo per me, è lì solo per provare a...

Jonathan: produzione, si potrebbe dire.

Isaac: Riorganizzare il codice, notare che ci sono strumenti che sono, sai, macchinosi da usare e decidere di riscriverli o di scriverci dei wrapper attorno. Vedo, sì, tipo vedo modifiche al codice di qualche programma grande e complicato e penso: oh, quel programma è un disastro. Posso entrare e riscriverlo o riorganizzarlo? Oppure creare nuovi strumenti. Cioè, non è sempre riorganizzare, a volte è semplicemente creare nuovi strumenti. Tipo: oh, abbiamo un processo che prevede 20 passaggi, butto tutto dentro un programma. Molto di questo tende a essere... devo in qualche modo scoprirli. A volte li scopro perché mi vengono assegnati una serie di compiti, e poi penso: non voglio eseguirli a mano. A volte li scopro semplicemente notandoli: tipo, sto cercando un pezzo di codice da qualche parte e penso: oh, quest'altro codice qui, che mantiene un altro team, fa le cose male, lascia che lo riorganizzi, o che usi librerie moderne o quello che è, sì.

Jonathan: Quindi molto... semplicemente riuscire a vedere. E quanta libertà hai? Hai parecchia libertà di girare e tipo piombare dentro, ritoccare qua e là? Dev'essere divertente, piacevole.

Isaac: Il mio manager mi dà molta libertà, il che è davvero bello. Non so quanto di questo venga dal fatto che... attualmente non sono in Google, ma non so quanto venga dal mio passato in Google. In Google le persone erano molto aperte a piombare dentro e dire: oh, ho notato che gli altri, sai, mi è capitato di usare questa libreria e si potrebbe migliorare così. Lascia che lo sistemi. Ho lavorato molto, molto brevemente in una startup dove la cultura era molto diversa, molto meno aperta. E nella startup le persone erano molto protettive nei confronti delle loro codebase e il fatto che altri modificassero il loro codice non era ben accetto. Quindi io: oh, c'è un problema con questa codebase, davvero la cambio, per... per quella codebase.

Jonathan: Sì, stai indietro. Ma è interessante, perché... uno immagina che una startup sarebbe molto più tipo: basta che il lavoro venga fatto, e fallo nel modo più economico possibile, sai, ma in realtà forse Google era molto più in grado di gestire questo come concetto. E questo... scusa, ho appena acceso le luci perché noi... al momento niente luci per tutti quelli che ascoltano, a Città del Capo ogni tanto manca la corrente. Proprio adesso mi sto accecando, ma va bene. Ma è interessante, tornando a quel punto sulla cultura delle startup e su come le persone siano molto più, ironicamente, prese dal possesso delle cose e poi magari si autolimitino un po', sai?

Isaac: Sì, non so se essere una startup sia necessariamente legato a essere una cultura del lavoro aperta... era tipo una cultura del lavoro basata sul gioco. In Google, molto di quello che le persone facevano era giocare, nel senso che si divertivano con quello che facevano. Lo facevano perché gli piaceva. Erano molto amichevoli, o molto aperti, al riguardo. Alcune altre culture aziendali sono più... non tanto fare le cose perché ti piacciono, quanto piuttosto: è un lavoro, o questo è il mio codice e io so come funziona. Non voglio che altri ci mettano le mani. Non sono del tutto sicuro di cosa serva per cambiare queste culture aziendali. Ma Google coltivava molto il senso che tutti hanno accesso a tutto il codice. Tutti avete il potere di modificarlo. Andate avanti e fate quello che pensate sia giusto. E poi nel mio lavoro attuale, con il mio manager attuale, anche lui mi ha dato molta libertà. Dice: certo, hai trovato qualcosa da sistemare. Vai e sistemalo. Hai trovato un'area dove le cose si possono migliorare. Io mi tolgo di mezzo. Fammi sapere come posso aiutare. Quindi riesco molto ad autodeterminare gran parte di quello che faccio e, sai, se trovo un'area dove penso: oh, potrei migliorarla, lui dice: sì, bello, vai.

Jonathan: Ok, bene. E tu... l'azienda ha sede sulla costa Est, dico bene? Quindi in realtà lavori da remoto? Credo di ricordare che avevi detto che stavi per trasferirti, e poi è arrivato il COVID ed è finita lì. Come vivi il remoto, la distanza, il fuso orario, tutte queste cose? Ti pesano o...?

Isaac: Sì, mi manca davvero stare in ufficio e interagire con le persone di persona. Quindi c'è questo. Il fuso orario: il mio team è stato molto disponibile con la differenza di orario. Sono tre ore indietro rispetto al resto del mio team. C'è uno standup quotidiano breve che mi perdo. Abbiamo due standup quotidiani per due prodotti diversi. Il primo lo perdo, e il mio team è stato molto bravo ad andarmi incontro, e internamente usiamo molto Slack. Quindi sono molto bravi a tenere un thread Slack quotidiano con i problemi che emergono, così posso restare aggiornato, e se hanno bisogno di qualcosa mi pingano. Io cerco di essere reattivo il più possibile e di rispondere a quelle cose il prima possibile al mattino. Quindi è un po'... il fuso orario non è il massimo, ma non è nemmeno... siamo riusciti a gestirlo piuttosto bene. E poi, al contrario, c'è l'altro lato: sanno di avere nel team qualcuno che è sveglio un po' più tardi. Quindi mi è capitato con alcuni colleghi: sono le 18 sulla costa Est e dicono: oh, questa cosa è rotta. Ehi, Isaac è sulla costa Ovest, Isaac potrebbe darmi una mano, perché lì sono ancora le 15. Quindi funziona in entrambe le direzioni. Sì, il...

Jonathan: Sì.

Isaac: Io... sì, ho lasciato Google nel 2019, scusa, nel 2020. Ho fatto i colloqui nel 2019. Dovevo entrare nel maggio 2020. Avevo programmato di trasferirmi ad agosto, nell'aprile 2020, ma è iniziato il COVID e tutto quanto, l'ufficio ha chiuso, ed era molto: l'ufficio non è ancora aperto, si trasferirà appena riapre. E poi, due anni dopo l'inizio della pandemia, hanno ricominciato ad aprire l'ufficio. E io pensavo: sai, non sono più tanto sicuro di volermi trasferire. New York sembrava davvero entusiasmante, ma c'erano tutte quelle attività aperte, locali e cose del genere. Ma ora che c'è una pandemia, molta di quella eccitazione non suona più così bene. Quindi sono passato a una posizione da remoto dopo due anni di lavoro da remoto.

Jonathan: E tu sei una persona di città o di campagna, o via di mezzo? Perché New York è città. È città al 100%. Non c'è dubbio, mi capisci? Quindi sarebbe stato un bel cambiamento, immagino. Sì. Comunque entusiasmante.

Isaac: Sono cresciuto in una grande area metropolitana, quindi la vita di città non mi è estranea. Attualmente vivo in periferia. Mi piace fare escursioni e andare in bicicletta e cerco di stare all'aperto il più possibile. Quindi mi piace vivere in periferia, vicino a sentieri fantastici per escursioni e ciclismo e tutto il resto. Trasferirmi a New York sarebbe un bel cambiamento. Ma penso che cambiare ogni tanto non sia una brutta cosa. E se a New York mi odiassi la vita, posso sempre trasferirmi.

Jonathan: Non è così complicato farlo. Ma bello. Allora, tu probabilmente, correggimi se sbaglio, passi molto tempo davanti allo schermo, tipo in ufficio, o in home office o quello che è. Tipo, esci tutti i giorni per... come bilanci tutto il mondo dentro lo schermo rispetto a... hai tipo un momento quotidiano in cui dici: devo uscire e fare qualcos'altro?

Isaac: Vorrei. Alcuni giorni, o alcuni mesi, o alcuni anni sono meglio di altri. Nel 2020 ero piuttosto bravo ad andare in bicicletta quasi ogni giorno. Esco quasi tutti i fine settimana. Cerco di fare un'escursione a settimana. Non sono stato bravo, ma sto cercando di andare a fare un'escursione. Dipende dalla stagione. Sono in California. Certe settimane fa estremamente caldo. Abbiamo appena avuto un'ondata di caldo con... oltre 40 gradi Celsius per circa una settimana di fila. Quindi è difficile stare all'aperto. Siamo in California, dove ci sono gli incendi, quindi sai, a volte passano una o due settimane in cui la qualità dell'aria fuori non è del tutto sicura da respirare. Quindi certe settimane è difficile stare all'aperto in California. E poi stare al chiuso durante una pandemia è anche difficile. Quindi di sicuro ci sono settimane in cui sto molto più al chiuso che in altre. Ma mi piace stare all'aperto. Ci sono stati, sai, periodi di sei mesi in cui andavo a fare escursioni almeno ogni due settimane.

Jonathan: e poi.

Isaac: Ci sono stati periodi in cui sono andato in campeggio tipo una volta al mese per, sai, sei mesi di fila. Quindi ci sono periodi in cui sono meglio e periodi in cui sto in casa due settimane di fila.

Jonathan: Sì, bello. E allora Isaac, qual è il prossimo... forse, non lo so, forse non ci hai pensato così in là, ma come saranno i prossimi cinque anni per te? Cioè, hai un'idea, oppure sei tipo: voglio avviare un'attività per conto mio, oppure voglio fare questo, oppure sei semplicemente tipo: ah, mi godo la vita e mi godo dove sono.

Isaac: Prima di trasferirmi sulla costa Ovest, pensavo di avere una presa migliore su come sarebbe stato il mio futuro. Ma aver visto tutto quanto capovolgersi mi ha insegnato che è davvero difficile prevedere cosa succederà nel prossimo anno, figuriamoci cinque. Sono abbastanza felice. Ho appena cambiato lavoro, relativamente di recente. Ho cambiato lavoro circa due, due anni e mezzo fa. Il mio lavoro attuale mi piace molto, quindi non vedo cambiamenti nell'immediato. Sarei felice di restare nello stesso lavoro per i prossimi due, tre anni, cinque anni. Amo vivere in California. Amo poter andare a fare escursioni, andare in bici, in campeggio e tutto il resto. Quindi non mi vedo lasciare la California troppo presto. E non mi vedo lasciare quel lavoro nell'immediato, perché mi piace molto lavorare lì. Quindi sono piuttosto contento e non vedo grandi... non ho grandi cambiamenti in programma, ma è davvero difficile dirlo.

Jonathan: Bello. Ok, allora ho un paio di altre domande su cui mi piacerebbe avere il tuo punto di vista. La prima probabilmente non è quella per cui ti avevo preparato, ma... Allora, se dovessi... Se 10 persone entrassero ora nel tuo ufficio, 10 perfetti sconosciuti, e non sapessi nulla di programmazione, e avessi tipo un arpista e un giardiniere e chi più ne ha più ne metta, quali sarebbero i tre consigli principali che daresti loro per imparare a programmare? Cioè, se potessi ridurlo a: fai questo a tutti i costi, quali sarebbero alcuni di quei consigli?

Isaac: Allora, la raccomandazione numero uno che darei è cercare di trovare un problema che potresti risolvere con la programmazione. Così hai un progetto concreto che ti dà motivazione, senza avere in mente un obiettivo specifico che ti spinga avanti. È estremamente difficile imparare a programmare... come per qualsiasi altra abilità, imparare a programmare richiede parecchia tenacia o grinta. Devi solo continuare a provarci. All'inizio può essere molto difficile. Può essere molto frustrante. Senza qualcosa che ti spinga avanti, è molto facile arrendersi. Quindi, se possibile, avere qualcosa che vuoi davvero fare con la programmazione aiuta molto. Fa tutto parte della stessa costellazione di consigli. È solo che devi... devi continuare a provarci. Aiuta molto essere paziente con te stesso e riconoscere che stai imparando una nuova abilità e che fallirai parecchio. Ho visto persone che provano a imparare a programmare e si frustrano. Dicono: oh, di solito sono bravo nelle cose e questa non funziona subito. E io dico: sì, il fallimento fa parte del processo di apprendimento. E se ti senti a disagio a fallire in qualcosa, puoi avere davvero difficoltà a imparare nuove abilità. Devi essere paziente con te stesso e con il processo, e devi solo continuare a provarci.

Jonathan: Utile. Cioè, direi che è un po'... ho appena capito come funzionano i metodi. E questo è venuto dal lavoro fatto, perché molta della conoscenza... beh, quando le persone parlano di cose, c'è tanta conoscenza data per scontata quando insegnano, soprattutto. Tipo, all'improvviso tutti buttano lì la parola metodi. E io: che diavolo è un metodo? Cosa sta succedendo? Ed è stato solo grazie alla coorte con Go che ho iniziato a capire: oh, i metodi funzionano così. Ma è stato quasi come accendere una lampadina, e ho dovuto immergermi in questo ambiente e in questa terminologia per così tanto tempo che alla fine è penetrata. Direi che è stato uno dei miei più grandi apprendimenti: non cercare di imparare tutto, ma intaccare un concetto semplice alla volta. Perché tutto si collega così tanto che alla fine riesci a mettere insieme il modello mentale, che è davvero importante. Quindi è un piccolo grande strumento. Lo farò sapere alla gente, questa raccomandazione di Isaac: sii paziente, sii gentile con te stesso e intacca un pezzo alla volta. Davvero bello. Ok. Allora l'ultima domanda che ho, e prima di lasciarti andare avanti con il resto della giornata, abbiamo parlato come team di questo concetto della collina su cui moriresti nel mondo tech. Suona piuttosto melodrammatico e pieno di dramma. E l'idea è essenzialmente: qual è l'unica cosa che credi sia assolutamente fondamentale, che consideri una mentalità o una prospettiva immutabile da avere nel tech? Un buon esempio sarebbe, non so, a un livello molto banale, io metto sempre prima le funzioni e poi scrivo il CSS se faccio front end. Quindi funzionalità, poi logica, poi il resto. Potrebbe essere, sai... ne avevamo uno, Rebecca, che gestisce il track di Unison. Diceva: avere un genio con opinioni forti e difficile con cui lavorare... lei preferirebbe avere 50 persone che amano davvero lavorare in squadra e risolvere problemi insieme, piuttosto che un genio che si prende tutta la banda in termini di gestione. Quindi quello era uno dei suoi, e l'ho detto in modo carino, ma qual è la tua collina su cui moriresti nel mondo tech, il tuo non negoziabile?

Isaac: Questo è probabilmente influenzato moltissimo da come Google fa le cose. In Google hanno questo concetto di «readability», dove il codice dovrebbe essere facile da leggere. E molto di quello che faccio quando scrivo codice è cercare di rendere il mio codice semplice da leggere e capire. E ho visto tanto codice, soprattutto nel codice... c'è molta attenzione all'efficienza, ai benchmark e a rendere il codice più veloce. E spesso riconosco che il modo in cui lo faccio non è necessariamente il più efficiente, ma se trovo che il codice è più facile da leggere, preferisco codice inefficiente ma facile da leggere piuttosto che codice super efficiente. Cioè, sai, c'è quella citazione comune, non sono sicuro a chi sia attribuita esattamente, che «l'ottimizzazione prematura è la radice di tutti i mali». E ogni volta che qualcuno dice: oh, come si può rendere più efficiente? Io dico: deve essere più efficiente? Ti è capitato... stai girando in produzione e hai problemi di efficienza? È troppo lento da usare in produzione? Se non hai davvero riscontrato un problema con il codice in produzione, dove ha bisogno di essere più efficiente, perché lo renderesti più efficiente? Così com'è è più facile da leggere. È più facile da mantenere. Altre persone possono capire cosa succede. Perché dovresti rinunciare a codice ben scritto, facile da usare e da mantenere, per risparmiare qualche ciclo di CPU? L'elettricità è abbastanza economica e le CPU sono abbastanza economiche da non dover ottimizzare il codice? Solo per ottimizzarlo.

Jonathan: Sì, fa sempre ridere, perché è una di quelle cose in cui io dico... il nostro programma è stato compilato ed eseguito in 30 millisecondi. E loro: oh, ma l'abbiamo ridotto a tipo 20 millisecondi. E io: non saprei dirti. Non saprei dirti quale fosse più veloce, quale più lento. Sembra veloce. Quindi penso che sia un buon punto. Sono sicuro che mi piacerebbe leggere il tuo codice, ma è fantastico. Isaac, grazie mille per il tuo tempo, per esserti alzato presto e per aver sopportato i distacchi di corrente nell'emisfero sud. E per me che sto seduto nel buio più completo, sono sicuro che per te sia piuttosto comico. Ma grazie mille per il tuo tempo. E non vedo l'ora di rivederti nelle prossime coorti di apprendimento e nei canali di mentoring e in tutto il resto. E grazie per tutto il contributo che dai a Exercism e in generale. Quindi lo apprezzo molto. E sì, grazie mille ancora. E ci vediamo tra un secondo. No, piacere. Stammi bene, Isaac. Ciao.

Isaac: Grazie mille ancora. No, piacere. Stammi bene, Isaac.