Bene e buone feste a tutti, anzi non a tutti ma a te, esatto a te, a te che ci ascolti, a te che sei appena entrato in questa splendida community, a te che sei in questa community dai primi giorni della sua nascita, a te che oltre a seguire GIT BAR settimanalmente hai anche donato qualche birra per supportarci, a te che sei indietro di 30 episodi e non riesci a stare al passo per mancanza di tempo libero, a te che stai sul pezzo e il giovedì mattina ti viene l'orticaria se non esce un nuovo episodio, a te che sei stato ospite in un episodio e da allora hai iniziato a seguirci con passione, a te che sei host o co-host e metti tantissimo impegno in questo splendido podcast, a te che ti viene un infarto ogni volta che apri Telegram e vedi 375 messaggi da leggere nel gruppo, a te che ti leggi tutti i messaggi sul gruppo quotidianamente senza mai scrivere, a te che clicchi sulla freccia in giù per saltare tutti i messaggi non letti per poi leggere solo gli ultimi 3 messaggi, a te che scrivi in continuazione sul gruppo e sei stato anche bannato dal bot per troppa interazione, a te che se non parli di RAL almeno una volta al giorno non riesci a dormire, a te che ci ascolti ma non sei mai entrato nel gruppo Telegram, a te che hai consigliato Gitbar ad altre persone ci ha fatto crescere fino a rompere il muro dei 1000 membri, a te che hai contribuito anche alla realizzazione del nuovo sito web, a te che mentre ascolti un episodio pensi a bello sta cosa la sapevo pure io, a te che mentre ascolti un episodio pensi a wow sta cosa non la sapevo figata, a te che vorresti condividere un qualcosa ma non hai mai avuto il coraggio di farti avanti, a te che sei venuto a condividere un qualcosa anche più di una volta, a te che non rientri in nulla di tutto questo in precedenza, ecco e a tutti questi te che io voglio fare i miei migliori auguri di buon natale e di felice anno nuovo Andrea e Kiki c'è l'ipelli dev super episodio perché questo episodio esce a sorpresa proprio a natale in realtà è uscito un episodio qualche giorno fa ma volevo, volevamo in qualche modo farvi gli auguri di natale un po' come ogni anno in un modo un po' speciale per farlo vogliamo fare una puntata un po' diversa dal dal solito beh bando alle ciance allora che resta da fare resta semplicemente di iniziare il nostro episodio benvenuti su github il podcast dedicato al mondo dei full stack developer i mezzo artigiani mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo l'episodio di oggi è un episodio molto personale infatti voglio raccontarvi di una parte della mia storia una parte della mia esperienza e voglio farlo appunto condividendo con voi alcuni passaggi fondamentali che sono quelli che alla fine mi hanno reso un professionista migliore e voglio iniziare a farlo partendo da questo piccolo oggetto questo è un d20 di dungeons and dragon perché voglio partire da questo d20? tanti anni fa forse 20 una roba del genere andai a un java user group un evento organizzato dal dal juke e incontrai uno che all'epoca mi sembrava uno sviluppatore anziano in realtà all'epoca era giovanissimo ma parlando di 20 anni fa forse adesso ecco è un po' più adulto e io ero curioso volevo capire come si esplora come si cresce come si costruisce una carriera in quella direzione quindi nello sviluppo software allora sai mezzo ingenuo mi avvicinai dal tizio e gli chiesi ma cosa devo fare per costruire una carriera sullo sviluppo software cosa devo fare per poi diventare come te e sto tizio mise in mano la mano sulla tasca e tiro fuori un d20 un dado a venti facce io lì per lì non non non avevo capito il senso di questo dado in fondo avrebbe potuto voler dire milioni di cose ma avrebbe per esempio potuto voler dire a culo dipende dal tiro che fai e lo di 20 o meno capì il senso di questo dado poi dopo tanti anni però siccome questa storia è molto personale io voglio raccontarvela usando in qualche modo un mio alter ego si chiama Javass Turing ed è il mio personaggio di dnd Dungeons and Dragons ed è un ranger umano caotico buono e andremo a vedere appunto il percorso che Javass fa per diventare un senior engineer e durante questo percorso andremo a vedere alcune caratteristiche che si sviluppano per esempio la forza l'intelligenza la destrezza la saggezza la costituzione il carisma che sono le classiche caratteristiche insomma dei personaggi di dnd ma allora bando alle ciance e iniziamo a entrare appunto dentro Javass è dentro la sua esperienza Javass ha appena lasciato il consiglio dei vecchi pensava di aver raggiunto il suo traguardo quello per cui aveva lottato sin da quando era un piccolo cucciolo di uomo ormai è un ranger il consiglio lo ha decretato tutte le prove alla quale gli anziani lo hanno sottoposto sono stati superate ma adesso davanti alla foresta di lyria tutto è diverso quella selva fitta lo spaventa a morte è solo e la notte profonda qua Javass si trova su una foresta che non conosce e affronta la prima sfida che da sviluppatore da ingegner abbiamo davanti a noi che è l'ignotto la paura dell'ignotto quel terrore che ci viene quando ci troviamo davanti a una code base che non conosciamo quando ho iniziato a sviluppare mi sono capitate le cose più impensabili ma negli ultimi anni pur avendo tanti anni di carriera questa paura è rimasta presente e mi è capitato davanti a una code base quella quella sensazione di sudore sulle mani blocchetto sulla testa nodo allo stomaco come per dire ma io questo task non lo finirò mai non riuscirò a chiuderlo io do le dimissioni credetemi questa cosa capita spessissimo e sono sicuro che in un qualche momento della nostra vita della vostra vita è capitata anche a voi beh perlomeno a me è capitato più volte e allora in quest'ultimo anno io ho provato a fare un'analisi più o meno scientifica di quello che succede ho provato a vedere l'approccio alla crescita della carriera da un punto di vista psicologico mi ha preso un annetto questo studio e voglio raccontarvi un po di cose che ho imparato dicevamo javas è nella foresta questa sensazione a questa paura dell'ignoto bene la paura dell'ignoto è una roba che ho scoperto in psicologia affrontata in modo intenso nel senso che è pieno di pubblicazioni io ne ho letto diverse e in realtà la paura dell'ignoto ritorna spesso ma per provare ad affrontare la paura dell'ignoto bisogna fare un passo indietro e provare a capire che cos'è l'ignoto l'ignoto o questa paura dell'ignoto la paura dell'ignoto è un fenomeno conseguente a due elementi due mancanze che abbiamo la prima è la mancanza di predicibilità cioè il fatto che noi non possiamo prevedere quello che accadrà dopo non possiamo prevedere cosa farà quella riga di codice il secondo è la mancanza di controllo che è immediatamente conseguente alla mancanza di predicibilità no se io non posso prevedere qualcosa come posso averne il controllo ecco questi due perni sono i trigger che attivano questa sensazione che ci blocca ci rende improduttivi ed è anche pericolosa se portata a lungo crea ansia ansia cronica e quindi crea delle vere e proprie patologie specie in un contesto in una industria dove noi siamo sottoposti siamo ci siamo sempre bombardati da stimoli ignoti da situazioni da gestire dove l'ignoto la domina e allora come facciamo ad affrontare l'ignoto in modo da riappropriarci della predicibilità e del controllo di quello che stiamo facendo beh la letteratura scientifica dice chiaramente che quello che noi dobbiamo fare è provare a mapparlo questo ignoto provare a in qualche modo identificare cos'è in modo che insomma se noi riusciamo a identificarlo e se è un po meno ignoto no e quindi ci spaventa meno ma andando a fondo negli studi ho scoperto che in realtà gli ignoto non è uno solo ma sono diversi io ne ho identificato quattro e si distinguono appunto per particolari caratteristiche il primo che io ho chiamato cose che noi conosciamo ma deve da verificare quindi non su to be verified sono tutte le cose che davanti a una code base ignota che non conosciamo riconosciamo come simili come qualcosa di familiare queste e queste intuizioni sono guidate dal concetto di consistenza quindi vuol dire che quel pattern quell'elemento che poi la parola pattern ritornerà tra un po' quell'elemento riusciamo a riconoscerlo come consistente con qualcos'altro qualcosa che noi abbiamo visto su altre code base metti che io sto sviluppando su fastify il pattern dei plugin o dei decorator posso averlo visto in qualche altro framework o in un altro progetto che utilizza fastify quindi un elemento che un po' mi rassicura questa consistenza può essere interna o esterna a seconda del fatto che noi stiamo lavorando noi riconosciamo questo pattern come elemento già presente all'interno della code base o elemento presente in altre code base e allora quello che noi dobbiamo fare quando abbiamo dei non su to be verified quindi delle cose che noi conosciamo ma che dobbiamo necessariamente verificare e imparare a chiedere perché perché dietro quell'elemento quel pattern che noi riconosciamo come consistente con qualcos'altro noi stiamo intuendo un significato ma spesse volte quella consistenza non esiste per cui in realtà potrebbe voler dire altro immaginiamo una parola di dominio questa cosa capita a me è capitata spessissimo un altro tipo di announce io ripeterò costantemente announce anche se il mio professore d'inglese mi piglia schiaffi per questa cosa abbiate pazienza ormai sono anni che mi conoscete quindi a me mi scuserete però abbiamo i non announce cosa sono sono le cose che noi sappiamo di non sapere esplorando una code base noi vediamo un pezzo di codice che non capiamo che cipa faccia che cosa ci faccia la quale il suo compito e quello è qualcosa di sconosciuto però noi sappiamo che quel quell'elemento è sconosciuto quindi abbiamo tutti gli strumenti per andare a scavare a fondo e trovare il significato attenzione che anche qua però il rischio qual è il rischio è quello di cadere nei famosi rabbit all quindi andare in fondo scavare scavare scavare scavare alla ricerca di questo significato e poi perdersi in questa ricerca così profonda e soprattutto se noi scaviamo e perdiamo poi il nostro filo abbiamo un carico di informazioni enorme da gestire subito dopo quindi questo crea un carico cognitivo enorme che poi dovremmo andare a gestire per cui sì dobbiamo approfondire ma dobbiamo anche capire il momento in cui questo scavare a fondo non è più produttivo per l'obiettivo che ci siamo posti perché il pragmatismo deve guidare il nostro percorso poi abbiamo gli annons non se che è tutto ciò che noi sappiamo del progetto ma che non sappiamo di sapere sembra una una uno scioglilingua cioè tutte quelle situazioni tale per cui noi stiamo esplorando un pezzo di un progetto non capiamo quel pezzo chiediamo a un collega o leggiamo nella documentazione e poi diciamo cazzo ma è solo questo ma allora lo conoscevo ecco questo è un po più stronzo si manifesta poi sotto forma di epifania alla james joyce no però è qualcosa che dici a e rimani stupito ma in fondo tu non sai di sapere quindi sono elementi che già in il tuo bagaglio e tra un po andremo a vedere come far triggerare l'apertura di questi elementi nascosti per finire poi con gli annons più più difficili quelli più complicati da aprire da scoprire che sono gli annons annons ciò che non sappiamo di non sapere ciò che non sappiamo di non sapere a meno che abbiamo qualcuno che ci metta quella pulce sull'orecchio che ci dia quello stimolo è veramente difficile gestire e solitamente vengono da un concetto di obscurity che cos'è l'obscurity l'obscurity è quella condizione che si ha quando informazioni importanti non sono ovvie questo concetto è spiegato molto bene in un libro che se mi ricordo bene era a philosophy of software a philosophy of software design di john osterhuth sicuramente non si pronuncia così ma ne abbiamo l'abbiamo citato più volte all'interno del del nostro podcast quindi buttateci un occhio e soprattutto avete ancora qualche giorno di vacanza prendeteli in mano perché uno di quei libri che cambia la vita io l'ho senti in un in un episodio del podcast di francesco sciuti mentre parlava con salvatore sanfilippo ed è uno di quei libri che veramente mi ha cambiato il punto di vista nel lavoro che faccio e vi dicevo quindi gli annons annons gli annons annons sono quelle informazioni che non sappiamo di non sapere che vengono dal concetto di oscurità obscurity quindi informazioni ovvie che in realtà non sono poi così ovvie nel codice ma abbiamo degli indizi per identificare questi queste parti abbiamo una serie di red flag una di queste forse quella più importante è la documentazione cioè se un progetto ha una copertura di documentazione molto intensiva in alcune parti un progetto ha tanta documentazione su uno dei moduli per esempio noi abbiamo un enorme red flag che ci dice ehi guarda che in questa parte di codice potrebbero esserci informazioni importanti non ovvie e nascoste naturalmente talvolta è sufficiente leggere gli edr le pierre les show anche per capire un po che tipo di informazioni e dove sono una volta che abbiamo però identificato i tipi di gnoto dobbiamo in qualche modo trasformare il nostro ruolo da un ruolo esplorativo a un ruolo proattivo cioè dobbiamo mettere in piedi la la strategia di esplorazione della code base e per farlo attingo ad alcuni concetti che ormai sono diventati parte di me che porto nel podcast in modo implicito nascosto ma che dalla mia attività di giornalista mi porto appresso proprio perché sono la base di quell'attività datemi un secondo un sorso di caffè e la strategia di cui voglio parlare la strategia delle 5w 1 h che sono le classiche domandine che noi ci poniamo da quando facciamo la terza elementare quando facciamo i temini no chi come cosa quando perché cel chiediamo sempre ecco se noi facessimo utilizzassimo la stessa strategia di maestra pina nell'esplorazione del nostro codice beh riusciremo davvero a esplorare il nostro codice riducendo tantissimo la paura dell'ignoto la prima domanda che dobbiamo porci è cosa e quando what and where da dove partire cosa prendere in mano questa domanda dobbiamo rispondere appena noi vediamo una code base ho chiesto a tanti sviluppatori anche molto schillati molto più bravi di me temper programmer rockstar develo per super senior ninja e alla fine però tutti mi dicono boh in realtà qualcuno mi ha dato delle delle risposte interessanti alcuni dicono parti dal main io con gli anni ho imparato a partire dal package punto json nel caso in cui sto sviluppando in javascript in typescript o dal file delle delle dipendenze del del linguaggio che utilizzate perché io ho iniziato a partire da là perché in realtà è vero che la porta d'ingresso della nostra applicazione è il main però è anche vero che se noi partiamo dal file del package manager noi abbiamo la possibilità in realtà di riconoscere degli elementi che possono essere per esempio delle librerie che noi abbiamo utilizzato prima che sono utilizzate anche in questo progetto dei framework che ritornano che abbiamo già visto quindi sono elementi che noi riconosciamo come familiari e riconoscendoli come familiari ci spaventano di meno dobbiamo tenere presente che la paura dell'ignoto è una condizione la repulsione verso l'ignoto è una condizione che ci viene dalla notte dei tempi e che in qualche modo ci ci serve per difenderci appunto in una situazione di sopravvivenza e che spesso insomma degenera in antisemitismo e razzismo è la stessa matrice per cui riconoscere degli elementi simili ci porta a muoverci con un pochino più di tranquillità all'interno della codebase però in realtà quello di partire dal file di package manager può essere una ricetta ma può anche non essere adatta in tutte le situazioni perché perché fondamentalmente il nostro codice non è un elemento lineare non è un saggio che tu leggi dall'inizio alla fine o un qualunque testo che tu prendi e vai al capitolo e leggi ma è una rete intricata di relazioni dipendenze per cui non possiamo esplorare il codice in modo lineare abbiamo bisogno di una strategia che ci permetta di muoverci in questo intricato ammasso di fili e anche se il codice è fatto bene un po spaghetti lo possiamo visualizzare nella nostra mente e allora un modo interessante in realtà per esplorare il codice viene da uno stimolo che mi ha dato Leo Rossi è uno stimolo molto interessante e parte dal concetto che in realtà il nostro codice è una città anche la città è un intricata fia un intricata ammasso di vie viuzze sentieri veicoli piazze e come esploriamo una città nel momento in cui noi arriviamo beh l'esplorazione della città avviene partendo da un punto a caso il punto dove ci troviamo è in modo insomma a raggera noi andiamo a esplorare prima ciò che abbiamo vicino ci creiamo dei punti di riferimento poi ci allontaniamo un pochino di più e costruiamo la nostra fitta rete di punti di riferimento finché dopo x tempo non abbiamo mappato nella nostra mente tutta la città e se facessimo proprio questo quando esploriamo il codice e se proprio ci ponessimo come ci poniamo quando esploriamo la città ebbe probabilmente anche l'attitudine che abbiamo nell'esplorare la code base è completamente diversa un altro elemento sempre del what e where che ci permette di avere quella tranquillità nell'affrontare l'ignoto quindi a battere la paura dell'ignoto è quello di conoscere bene gli strumenti che si usano mio padre ha per tanti anni fatto il meccanico e mi diceva sempre sai mauro io riesco a riconoscere un meccanico da come impugna la chiave inglese io ti so dire se uno scarpone o se è un bravo meccanico noi per tanti anni ci siamo detti o perlomeno io mi sono ripetuto ma non importa l'editor che usi l'importante il codice che scrivi forse non è così importante abbiamo insomma ho provato a convincermi ed era abbastanza convincente del fatto che alla fine l'editor era un elemento forse quello meno importante no era per esempio molto più importante il framework ma cosa succede se attorno a te è tutto sconosciuto e hai bisogno di qualcosa di familiare una presenza che tu conosci che sai gestire ecco l'editor è la tua lancia la tua arma per muoverti nell'ignoto e per farlo la devi conoscere bene questa cosa l'ho capita dopo tanti anni di prese per il culo da chi usa vim chi usa vim ha riconosciuto che l'editore è la propria lancia e in realtà conoscere gli strumenti ci permette appunto di muoverci con quella tranquillità o almeno riducendo il carico cognitivo perché conosciamo una serie di trucchetti trucchini nell'usare l'editor che ci permettono di muoverci agevolmente anche su ciò che non conosciamo gli strumenti solitamente sono due io adesso vi ho introdotto l'editor ma git è un altro strumento fondamentale quindi dobbiamo fermarci un attimo a conoscere i nostri i nostri editor io da un posto usando vim ma il mio toolset il mio kit per vim non è all'altezza della mia conoscenza di visual studio code quindi vi racconterò due cosine rapidi di visual studio code ma sappiate che queste funzionalità di cui vi parlo ci sono in praticamente tutti gli editor tutti gli ide l'importante è sapere che ci sono e come arrivarci la funzionalità principe nel momento in cui si esplora una code base è senza dubbio la ricerca abbiamo detto che le code base non sono un elemento lineare no per cui come ci muoviamo in questo grafo di relazioni intricate beh lo strumento di ricerca è uno per farlo dobbiamo conoscerlo molto bene e ci sono alcuni elementi importanti che possiamo utilizzare che ci permettono di saltare da un punto all'altro del nostro codice senza doverci muovere manualmente e quindi limitando l'impatto di quella mole di informazioni che verrebbe nel transito del passaggio da un punto all'altro la cosa importante quando si esplora una code base è mettere in mente tenere a mente sono solo le informazioni che contano quindi ridurre tutto il rumore se noi siamo in grado di ottimizzare la serie di informazioni che noi alla quale noi siamo sottoposti nello spostarci dal punto A al punto B vuol dire che noi stiamo ci stiamo muovendo all'interno del codice in modo più fluido più scorrevole ok più liscio per farlo per esempio la ricerca partendo da una selezione di testo quello che noi facciamo comunemente con command shift F su Visual Studio Code ci permette di saltare da un punto all'altro della nostra code base senza perdereci appunto in caterve di informazioni un altro tool che ho trovato utilissimo partendo da una ricerca fatta è quello del elemento precedente e successivo sembra una banalità non saltare all'elemento precedente dei risultati o all'elemento successivo in modo da vederne i dettagli ma calcando F4 su Visual Studio Code rapidamente io mi muovo tra un risultato e l'altro cercando appunto di ridurre il tempo e la mole di informazioni in pochissimi mille secondi quindi in realtà alla fine arrivo all'informazione che mi serve senza perdermi un'altra funzione che non conoscevo fighissima e cercatela se usate Visual Studio Code cercatela sono sicuro che altri tool per esempio so che Sublime Text ha qualcosa del genere ce l'hanno e praticamente se noi andiamo nei risultati di ricerca di Visual Studio Code e clicchiamo apri nell'editor nella lista dei risultati ricerca avremo una pagina di editor così come quelle dove scriviamo il codice con i vari blocchetti dei risultati di ricerca dei vari file ma la cosa veramente figa è che possiamo aumentare o ridurre le linee di contesto quindi quante linee prima del immaginiamo che di aver cercato un particolare nome di variabile la variabile pippo ok e avrò tre file solitamente i risultati ricerca mi mostrano la riga dove c'è pippo del file A del file B e del file C ma che informazioni io ho? Io ho bisogno di più contesto ecco c'è questa funzione nel search editor di Visual Studio Code che ci permette di inserire il numero di righe prima e dopo che vogliamo vedere del nostro risultato quindi di questi tre file non vedrò solo una riga per file ma vedrò che ne so 5 6 righe in modo da mettere in un contesto quella variabile pippo e capirne di più questo è fondamentale quando si esplora la codebase così com'è fondamentale sapere che le ricerche sono le nostre pietre miliari cioè sono quegli elementi che ci aiutano a identificare dove siamo è una cosa che possiamo fare con Visual Studio Code è quella di salvare i risultati di ricerca se io faccio mela s comand s mela sa un po di anni 90 se io salvo i risultati di ricerca a quel punto in qualunque momento della mia esplorazione posso risaltare rapidamente a quei risultati quindi diventano un punto che ci aiuta a orientarci e ci aiuta anche a scambiarli con altre persone che lavorano con noi se non lavoriamo da soli a questo punto però la domanda viene viene spontanea ma se io lavoro in un contesto aziendale grande dove ci sono 70 repo e delle con una consistenza condivisa tre repository quindi devo cercare qualcosa in modo orizzontale tra tutti i repository beh ci sono tool come source graph che ci permettono di fare proprio questo nel caso di source graph è un tool a pagamento ma è sufficiente utilizzare la ricerca avanzata di github che pochissimi conoscono per andare a inserire quegli elementi dettagliati di ricerca su più repository buttateci un occhio perché in realtà la ricerca avanzata di github è una una una vera figata quindi arrivati a questo punto abbiamo in qualche modo risposto alla domanda what and where forse ho aperto una parentesi enorme e ci siamo persi ma ritorniamo appunto alle nostre 5w 1h la domanda alla quale voglio rispondere adesso è come la cosa che ripeto sempre è per capire il come fai girare il tuo codice as early as possible il prima possibile sempre il prima possibile metti debugger breakpoint del debugger e console log nei punti dove vuoi vedere il flow in modo che questi console log e questi breakpoint diventino i punti che ti aiutano a orientarti io in realtà nell'ultimo periodo che ho utilizzato viso studio code ho installato un plugin interessante che era un plugin di bookmarking quindi mi permetteva di mettere di segnalibro in alcune parti specifiche del codice con anche una piccola nota e devo dire che l'ho trovato molto molto interessante perché poi avere il segnalibro a destra mi permetteva di saltare rapidamente da una parte all'altra comunque appunto per capire appunto come funziona il nostro codice dobbiamo farlo girare il prima possibile ma se non possiamo farlo girare a tutti è capitato di dover lavorare su una code base dove al massimo si riusciva a far girare i test no perché è complicata perché è un'architettura allucinante perché qua e la non ce lo stiamo a spiegare perché fondamentalmente talvolta l'architettura è fatta di merda che non può essere replicata sulla macchina però per fare questo cosa facciamo per fare questo abbiamo un altro strumento molto interessante sempre dell'editor che ci permette di saltare alla definizione della funzione andare all'implementazione andare alle reference ma soprattutto una cosa che mi ha sconvolto l'esistenza è quella di andare alla call hierarchy alla gerarchia delle chiamate cioè nel vedere un albero che ti fa vedere chi chiama cosa per cui partendo dalla funzione pippo tu vedi chi ha chiamato pippo e poi vedi chi ha chiamato chi ha chiamato pippo e così via in modo da capire bene dove fluisce informazione per cui se con il console log io vedo il dato che passa solitamente io lo uso per vedere il dato che passa quindi il contenuto dei dati le call hierarchy le utilizzo per vedere diciamo la struttura il percorso che questo dato fa pochissimi la usano a me ha cambiato completamente la vita e abbiamo anche risposto a au per cui ciò che ci manca è rispondere alla domanda who e when questa domanda solitamente a questa domanda solitamente ci rispondiamo con una sorta di guessing name no l'indovina chi non so se vi ricordate tra l'altro ho scoperto durante questo percorso che ho fatto proprio per studiare insomma gli impatti psicologici dell'esplorazione della codebase ho scoperto che esiste un indovina chi basato sui personaggi di The Office ed è bellissimo cercatelo perché può essere un regalo di post natale bellissimo comunque capire chi e quando ci permette di trovare chi pingare cioè quelle persone a cui andare a rompere le scatole per chiedere maggiori informazioni appena appunto cercare di allontanare il più possibile l'obscurity da noi per farlo abbiamo degli strumenti sono due fondamentalmente anzi uno l'altro è una visualizzazione ed è semplicemente git git ci dà tutti gli elementi per poterci muoverci muovere agilmente c'è da dire che però se noi avessimo una serie di funzionalità ben integrate nel nostro editor per muoverci rapidamente e non dover spostarci sulla linea di comando ogni volta ci permetterebbe un cambio di contesto un context switch minore un insieme di context switch minore e quindi riusciremo a ridurre e gestirebbe il caricò cognitivo in fase di esplorazione per farlo su Visual Studio Code ma ripeto ci sono strumenti diversi anche per gli altri editor che coprono questo tipo di esigenze c'è Gitlens cosa ci permette di fare passando su una riga di codi e ci permette di vedere chi e quando ha scritto questa riga il classico git blame no ma ci permette anche di vedere cosa è cambiato nella riga cosa ha cambiato ed è fondamentale la stessa cosa ripeto possiamo farla direttamente con un comando git blame passare il numero di riga e il file e a quel punto vediamo chi è responsabile di quella riga e chi andare a contattare se non capiamo tra l'altro blame e penso il nome più brutto che si poteva dare per un comando ma sappiamo che c'era Linus Torvald ed è la persona meno sotto io nel team di sviluppo ed è la persona meno politically correct del mondo quindi ci sta va bene un altro strumento interessante è senza dubbio il git log che con gli opportuni parametri ci permette di avere altrettante informazioni ma una funzione che ho trovato veramente game changer nell'esplorazione della code base è andare a vedere l'history dei cambi di un certo file questo perché in realtà spesso tutti gli elementi che possiamo identificare come obscurity sono arrivati a uno stato di obscurity non sono partiti da uno stato di obscurity adesso sto generalizzando però solitamente nella mia esperienza è successo così no le cose partono si evolvono e si incasinano col tempo se noi riusciamo a percorrere a fare lo stesso percorso che il codice ha preso per evolversi e incasinarsi noi siamo in grado di comprenderne il significato e il senso e l'obiettivo che questo pezzo di codice che poi si è incasinato col tempo voleva raggiungere quindi avere la possibilità di leggere la git history direttamente dall'editor magari cliccando su un certo commit e vedendo le diff di quel file in quelle righe e muovendosi rapidamente tra i vari commit beh veramente credetemi cambia tutto perché si capisce appunto il percorso che la code base ha fatto nell'evolversi oltre che a identificare appunto la persona eventualmente da contattare e la risposta appunto è il why dare un perché alle cose è sempre molto difficile quindi noi vediamo che magari dalla git history le cose sono cambiate però dare capire il perché sono cambiate perché sono andate in quella direzione diventa veramente complicato ma possiamo farlo possiamo farlo se il progetto è stato pensato utilizzando in modo decente e non criminale il concetto di PR ed issue se noi andiamo infatti a esplorare le PR e le issue noi vediamo le discussioni che hanno portato a quella modifica e quindi ne capiamo il senso profondo ma anche qua però spostarci su github cercare il file andare a vedere quel punto preciso nella storia diventa un bordello git lens su visual studio code ci permette con davvero un click e credetemi un click partendo dal codice di saltare direttamente sulla issue o sul o sul sul sull'app request e vedere le discussioni all'interno ed è ed è veramente game changer e soprattutto all'interno delle discussioni vediamo tutta una serie di persone coinvolte in queste discussioni che sono una serie di persone potenzialmente utili per chiedere aiuto ebbene si li ho contati sono praticamente 20 anni che scrivo codice in questi vent'anni una cosa ho capito chiara che un signor ingegnere non è ciò che chi sa tanto perché in realtà tutti i geni tutti i senior tutte le persone che ho reputato veramente brava nella mia vita mi hanno sempre mostrato delle carenze in termini di conoscenza per cui mi son chiesto ma allora chi è il signor ingegnere la seniority cosa ti dà in più la risposta che mi son dato poi con col tempo è che in realtà stiamo parlando sempre di gnotto e la chiave sta là cioè un signor ingegnere è chi sa convertire in modo veloce ed efficiente gli non annunz quindi ciò che non sa di non sapere in un annunz in ciò che sa di non sapere convertendo ciò che non sa di non sapere quindi l'obscurity in ciò che sa di non sapere ha la possibilità di decidere in modo senziente dove approfondire quali argomenti prendere e analizzare nel dettaglio questa capacità di non farsi prendere dal panico davanti a ciò che non sa di non sapere è la chiave principale di tutte le persone con tanta esperienza ma come si fa questa trasformazione tra ciò che non sa di non sapere in ciò che so di non sapere lo si fa semplicemente chiedendo agli altri e mi è capitato tantissime volte di vedere richieste d'aiuto proprio sbagliate no tipo aiuto la navigazione di next.js non sta funzionando cosa vuol dire la prima cosa che dobbiamo andare a fare è saper chiedere aiuto io negli anni ho costruito diciamo il mio piccolo framework personale no per per chiedere chiedere aiuto e che si basa su rispondere tre domande principali cosa voglio sapere e devo avere chiaro in mente cosa voglio sapere con chi sto parlando a chi sto chiedendo e anche qua devo individuare chiara la persona che poi mi risponderà in modo da ridurre il rumore al massimo quando poi sto prendendo la risposta e dove sono e come ci sono arrivato questa domanda in realtà mi permette di dare al mio interlocutore il contesto cioè io so cosa voglio sapere ma come ci sono arrivato dove mi trovo lo devo comunicare con estrema chiarezza in modo da portare il mio interlocutore in quel punto preciso ponendomi queste tre domande in realtà quello che sto facendo è semplicemente rubber ducking quindi sto chiarendo a me stesso i dubbi che ho e spesso mi varebbe da citare un film famoso la risposta sta dentro di noi spesso non abbiamo neanche bisogno di contattare qualcuno ed ecco perché noi queste domande ce le dobbiamo fare prima di contattare qualcuno fermarci chiarirci le idee trovarci queste tre maledette semplicissime domande cosa voglio sapere con chi sto parlando e come ci sono arrivato e come ci posso portare in mente il locutore una volta che io ho chiarito queste questi tre punti e non sono riuscito a darmi una risposta beh a quel punto io ho le mie cinque regolette che mi permettono di raggiungere il mio obiettivo cosa vuol dire quando si chiede qualcosa si interagisce con altri esseri umani e noi diciamo non siamo gli esseri umani più e poi perlomeno io parlo per me un essere umano più empatico del mondo per cui ho capito col tempo che esiste un galateo nel chiedere domande galateo non tanto per essere eleganti ma proprio per ottenere delle risposte utili e l'ho capito ahimè a mie spese dopo tante figure di merda e tante energie spese senza poi avere un risultato la prima cosa che poi è un elemento che vedo ricorrere spesso all'interno del nostro gruppo telegram è il don't ask to ask chiedere frasi del tipo posso chiedervi una cosa e attendere risposta fanno sì che si interrompa il flusso di lavoro del mio interlocutore che deve fermare quello che sta facendo passare al programma di chat di comunicazione l'email slack telegram quello che volete leggere quel messaggio che non ha alcun valore e decidere se rispondere e attendere la domanda questo crea questo singhiozza questa rottura di balle che ci fa partire già svantaggiati cioè il nostro interlocutore ha già perso del tempo ancora prima che noi gli poniamo la domanda capite che il costo è alto un altro elemento è ricorrente che poi la mia seconda regola d'oro è non essere pigro quindi quando si scrive un messaggio io me lo devo rileggere correggere la grammatica correggere lo spelling se il messaggio supporta markdown mettere i back tick in modo che il codice venga formatato e che sia più facile da leggere per mi interlocutore perché se io semplifico la lettura della mia richiesta o la possibilità che il mio interlocutore sia più propenso per darmi una risposta se invece scrivo di merda butto codice in times new roman adesso adesso esagerando però alla fine mio interlocutore dice chi me lo fa fare a perdere del tempo per rispondere a questa roba qua quindi non è essere eleganti ma è cercare l'outcome cercare la risposta e risultato una cosa che è stata poi difficilissima e che la mia terza regola aurea non aspettare solo confirmation solo conferme solitamente quando noi chiediamo aiuto una mezza idea o comunque delle potenziali vie da percorrere ce le abbiamo o intuizioni qualcuna talvolta ce le abbiamo cosa succede che noi a quel punto ci attendiamo una conferma e se la conferma non ci arriva non siamo soddisfatti oppure se la conferma ci arriva o l'indicazione importante ci arriva la riconosciamo come tale poi subito dopo chiudiamo le orecchie e tutto quello che il nostro interlocutore ci dirà dopo fluisce via come un torrente verso il mare ma noi abbiamo sempre un problema quello della noun a non non cioè delle cose che non sappiamo di non sapere se noi togliamo le orecchie aperte anche dopo che abbiamo ricevuto la nostra main information abbiamo la possibilità di ottenere una serie di indizi che probabilmente quasi sicuramente non avremmo valutato proprio per colpa del fatto che la code base per a noi c'è sconosciuta e che ci permettono di trasformare quell'anno un annunzio in qualcosa che noi sappiamo di non sapere o sappiamo di sapere cioè si vede che cambia completamente l'approccio ed è quello che il signor fa spesse volte fa quindi questa terza regola d'oro nel modo di porsi con gli altri è stata forse una di quelle più difficili da superare però che veramente ha generato un valore allucinante altro elemento non porsi in modo passivo aggressivo questa cosa l'ho vista spesso nell'open source atteggiamenti del tipo mi fissate i bug o mi rispondete a questa domanda altrimenti io non uso più questo tool capita tutti i giorni in realtà non è il modo migliore di porsi se si vuole raggiungere un risultato così come non è il modo migliore di porsi iniziando un messaggio con urgente o aiuto perché la cosa è urgente sì ma è urgente per me non per il mio interlocutore quindi un modo un po pressante per per farlo il galateo vuole anche che insomma quando noi riceviamo delle informazioni le condividiamo a nostra volta in modo da creare una rete proficua importante quindi questa è una cosa importante da fare l'ultimo punto in realtà delle mie 5 regolette su come chiedere agli altri è anche questo stato molto doloroso e come come dirlo noi solitamente chiediamo aiuto ma talvolta ci poniamo nel chiedere una soluzione stiamo chiedendo aiuto non stiamo chiedendo la soluzione al nostro problema la soluzione al nostro problema deve venire da noi l'aiuto sono una serie di informazioni tutte le volte che all'interno di una community si individua una richiedente soluzione finita e possibilmente anche scritta in un contesto che non si è condiviso quella persona viene marchiata a fuoco dal bollino del rompiballe che non si vuole nella community perché perché bisogna il tempo del nostro interlocutore ha un valore e noi dobbiamo almeno mettercene il doppio di tempo perché perché il problema è il nostro per cui ricordiamo sempre ricordarci che noi stiamo chiedendo aiuto non la soluzione è stata anche questa molto molto dolorosa da digerire nel tempo così come è stato complesso in realtà la fase immediatamente successiva alle risposte cioè il gestire l'impatto emotivo della risposta noi sappiamo i nostri interlocutori spessissime volte hanno un problema sono poco empatici e le risposte talvolta sono abbastanza tranchant quindi una cosa che ho imparato a mie spese è quella di non interpretare una risposta come un giudizio di tipo personale ma cercare sempre di tirar fuori dalla risposta il valore anche se in modo apparente il valore non c'è vi faccio un esempio quante volte vi è capitato di ricevere come risposta read the fucking manual or search in the fucking web a me gozziliardi di volte ma allora come posso trasformare questa risposta di merda in qualcosa di produttivo beh col tempo ho imparato in realtà e l'ho fatto anche con rasta davvero poco tempo fa di rispondere a questa risposta al posto di andare in un angolo a piangere o incazzarmi con una bestia di rispondere in questa risposta in modo a questa risposta in modo pragmatico con un'altra domanda domanda del tipo ok tu mi stai dicendo che devo leggere il cazzo di manuale però c'è qualche topic specifico vicino al mio problema al problema che voglio risolvere qualche aria quale parte per esempio del linguaggio devo leggere e soprattutto perché devo approfondire questa parte qual è il luck il mio luck che hai individuato questa cosa fa sì che noi vero esponiamo le nostre vulnerabilità ma dimostriamo al nostro interlocutore di essere coscienti delle nostre vulnerabilità e di in qualche modo volerci impegnare il mostrare che noi ci vogliamo impegnare fa capire al nostro interlocutore che noi non stiamo cercando una soluzione ma stiamo cercando aiuto e che siamo disposti a mettere tutti noi stessi alla ricerca di aiuto per cui dice ok questo veramente sta facendo il culo per risolvere la situazione ma sì ma diamogli una mano e quelle poche informazioni che ti dicono perché devi andare ad approfondire e qual è la causa scattenante o qual è la mancanza che devi colmare sono importantissime nella costruzione di una carriera perché talvolta è più capire dove sono i nostri luck che conoscere le cose che fa la differenza e ritorniamo sempre al discorso no del del senior e degli annon annon non annon no e ritorniamo sempre là alla fine è un circolo che che ripercorre la stessa via a questo punto però dobbiamo capire a chi dobbiamo chiedere e ci sono fondamentalmente due barra tre destinatari della nostra richiesta la prima il primo elemento è il want one quindi dobbiamo identificare una persona specifica e chiedere a questa persona naturalmente questo tipo di richiesta è veramente costoso perché sto allocando tempo mio e tempo di quella persona solo per me fondamentalmente ma una banda larghissima perché in realtà possiamo attingere a un gozziliardo di informazioni con il limite l'ulteriore limite che in realtà è super limitato in scala cioè non scala sta roba il mio interlocutore sempre uno se ci sono 70 mauro che gli chiedono informazioni sta roba si impalla essendo così limitata noi abbiamo la responsabilità a respo lo ripeto due volte perché importantissima abbiamo la responsabilità di write it down le informazioni che riceviamo andare scriverle condividerle perché perché appunto fa sì che questo elemento limitato in scala scali quindi fa sì che domani mattina al posto di rompere le balle al mio collega io c'ho qualcuno che gliele ha già rotte prima e l'ha scritto sotto e velocizzo il mio il tempo che mi serve per arrivare all'informazione e creo una sorta di circolo virtuoso no per lo scambio di informazioni possiamo anche chiedere a più persone no che il nostro secondo tipo di interlocutore quindi un tipo di comunicazione one to many questo modo di comunicare è molto più veloce come è ovvio che sia ed è anche diciamo a abbastanza facile trovare all'interno appunto di più persone chi detiene le informazioni chi è il gatekeeper di quelle informazioni no immaginiamo un gruppo slack o un gruppo telegram dove c'è qualcun esperto di una funzione x di di di rast è facile buttare giù il messaggio ben scritto e trovare qualcuno che quella funzionalità di rast la conosce qual è il problema che per quanto sia facile raggiungere chi detiene l'informazione è altrettanto facile ricevere indietro una grande quantità di rumore essendoci più persone le incomprensioni alla domanda o le discoteque tangenti che partono generano un rapporto segnale rumore molto basso e questo fa sì appunto che dobbiamo investire energia nel nell'andare a distillare l'informazione ma se noi riusciamo appunto a farlo con con abilità ecco è abbastanza funzionale per raggiungimento al nostro scopo l'ultimo punto che un po non è un interlocutore ma si presta bene a questo tipo di ragionamento è lo stare nel giro stay in the loop quindi se noi stiamo seguendo un progetto stiamo esplorando una code base nuova leggere feature, PR, issue, eventuali gruppi discord, telegram, slack, le news, il blog della piattaforma o della nostra code base che stiamo esplorando ecco dobbiamo conoscerli a mano a dito perché sono i punti dove abbiamo un sacco di informazione non e ci permettono di non perdere dei tempi appunto nel chiedere alle persone dove i tempi si dilattano a questo punto Javass il nostro ranger umano caotico buono ha fatto il suo percorso nell'esplorazione dell'ignoto ha aumentato la sua forza la sua saggezza la sua destrezza e il suo carisma perché perché ha imparato a cercare dentro le code base ha imparato a salvare le ricerche utilizzarle come punto di riferimento ha capito come il codice funziona e perché e soprattutto sa come trovare l'autore di quel pezzo di codice e come chiedere informazioni ma i problemi di javass sono finiti quindi no tante erano le informazioni che coglieva nell'entricata foresta tante da riempire gli occhi e la testa tenendoli immobili lì fermo al centro della piccola radura ogni dettaglio era diventato una voce nella sua testa voce che sbraitava con le altre creando un assordante frastuono mentre in realtà tutto taceva era forse l'inizio della follia noi pensavamo che diciamo i problemi di javass fossero finiti con l'avere imparato ad affrontare l'ignoto così non è i problemi di javass non sono finiti javass in questo momento è prossimo alla follia perché perché ha raccolto tantissime informazioni troppe informazioni molti di più di quante in realtà il suo cervello possa processare e qua che in realtà emerge un concetto importante cioè la differenza tra ciò che sappiamo e ciò che abbiamo compreso ciò che sappiamo è ciò che in qualche modo entra in contatto con noi noi vediamo qualcosa noi vediamo la programmazione funzionale ok e quindi sappiamo ma capire una cosa vuol dire dividere il concetto scindere il concetto in parti essenziali e farli diventare parti di te vuol dire nel caso della programmazione funzionale di essere diventato un tutt'uno coi concetti della teoria degli insiemi per esempio ed esiste una forte differenza ma allora quello che succede nella trasformazione tra ciò che conosciamo in ciò che comprendiamo si identifica attraverso un processo che genera del carico cognitivo il carico cognitivo è l'insieme appunto di sforzi che noi facciamo per attivare questa trasformazione e può essere definito in tre tipi fondamentali in realtà ho letto una marea di paper però diciamo il paper più interessante sul carico cognitivo i paper più interessanti sul carico cognitivo sono quelli di john sweller e di eddie miller sono paper che risalgono agli anni 50 quindi neanche troppo recenti e che in qualche modo provano a dare una forma a questo tipo di effort nella trasformazione di informazioni tra ciò che conosciamo e ciò che comprendiamo.

Il carico cognitivo come dicevo può essere di tre tipi c'è il carico cognitivo intrinseco che parte della natura dell'argomento che stiamo affrontando per esempio se parliamo di programmazione funzionale il carico cognitivo intrinseco è per esempio la complessità del mondo della programmazione funzionale quindi della teoria degli insiemi di quant'altro complessità che sta nella natura ok così come la programmazione che ne so rust sta appunto è strettamente legato alla complessità di tutto il sistema di gestione della memoria poi abbiamo il carico cognitivo estraneo che è il modo in cui le informazioni sono presentate alle persone viene viene e conseguente dal modo in cui vengono presentate le informazioni ed ecco perché noi dobbiamo scrivere il codice con una certa cura di quello che scriviamo proprio per ridurre questa parte del carico cognitivo la cura la diciamo il impegno che noi dobbiamo metterci nel ridurre l'obscurity rendere chiare le dipendenze rendere esplicite le cose non ovvie ecco viene inquadrato nel carico cognitivo estraneo che è quello che poi ci ha creato tutta la fear of the unknown di cui parlavo prima no quindi la paura dell'ignoto viene appunto dalla gestione di questo carico cognitivo estraneo ma poi abbiamo un terzo carico cognitivo che è quello più interessante in questa fase della nostra discussione che viene definito carico cognitivo permanente ed è il diciamo il risultato del processo di elaborazione delle informazioni di trasformazione tra ciò che conosciamo e ciò che comprendiamo adesso detto così può voler dir nulla ma prendetevi un attimo se state facendo qualcosa fermatevi un secondo e provate a seguirmi il processo che abbiamo per apprendere è un processo intricato che brucia energie e si attiva attraverso l'uso di due elementi fondamentali la memoria di lavoro teorizzata da miller negli anni 50 e la memoria a lungo termine immaginiamo come un registro la memoria di lavoro è un registro del processore e la memoria a lungo termine immaginiamola come come una una ram ok la memoria di lavoro è super limitata veramente piccola piccola può archiviare 7 più o meno due elementi quindi o 5 elementi o 9 elementi che devono essere però strettamente coerenti tra di loro quindi devono avere uno scope super super limitato e soprattutto soprattutto dura pochissimo dura solo 20 secondi vi ricordate che a scuola ci facevano ripetere in realtà le poesie un botto di volte perché proprio perché per rinfresciare questo registro questa memoria ogni 20 secondi affinché i concetti dalla memoria di lavoro si spostino nella memoria a lungo termine la memoria a lungo termine non memorizza informazioni ma memorizza pattern non informazioni esplicite ma lavora attraverso appunto i pattern questo prevede permette di memorizzare tantissimi pattern ed è in continua evoluzione ecco perché vi ho detto che una ram e non ho usato la parola hard disk no quindi c'è un meccanismo tale per cui queste sette informazioni della memoria di lavoro che durano solo 20 secondi e che se io non rinfresco dimentico queste informazioni devono essere portate alla memoria a lungo termine e quindi devono essere create queste sinapsi per memorizzare sto pattern adesso io sto semplificando tantissimo quindi quello che noi dobbiamo fare è cercare di attivare questo processo tra l'altro c'è un bellissimo studio di Giulio Tononi e Chiara Cirelli fatto nel 2005 che evidenzia che questo processo di trasformazione tra memoria di lavoro e memoria a lungo termine si attiva nel sonno perché è il momento in cui le le sinapsi sono più plastiche e via discorrendo quindi è super interessante ma come noi possiamo portare la teoria del carico cognitivo di sueller miller nel nostro day to day work beh la prima cosa che possiamo fare è siccome la nostra memoria di lavoro è super limitata 7 più o meno due elementi e solo 20 secondi dobbiamo fare applicare pareto la regola di pareto in modo più più più più drastico cioè andare a prenderci solo il 20 per cento di quelle informazioni che sono quelle veramente utili lasciando fuori l'ottanta per cento come possiamo fare per identificare all'interno della nostra code base questo 20 per cento di informazioni io ho trovato due piccole strategie ed entrambe utilizzano git la prima è andare a vedere i primi commit tolto tutta la parte di scaffolding quindi di inizializzazione del progetto i primi commit contengono spesso il senso dell'applicazione o del tool della libreria che stiamo andando a esplorare per cui leggere i primi commit ci dà già un'idea chiara di quello che poi vedremo nel nostro codice e per farlo si può lanciare un comando git log reverse col parametro reverse andare a vedere i primi che ne so 30 commit oppure con github è un pochino più incasinato perché non ti permette di vedere i primi commit in modo lineare e quindi io cosa faccio parto da un commit e poi utilizzo la paginazione mettendo a mano il numero di step in cui vuoi verso il quai voglio arrivare che ne so io di solito parto da un commit e poi metto più 200 più 300 per andare indietro di 300 commit e così ci riesco in realtà zio github se ci ascolti ecco implementare una reverse navigation dei commit potrebbe essere una cosa figa e utile un altro modo che abbiamo per concentrarci su quel 20 per cento secondo zio pareto che ci dà veramente valore nell'esplorazione è quello di andare a trovare i punti caldi cioè i punti nel nostro codice che cambiano più spesso per farlo è molto semplice c'è lo si può fare direttamente con git log col comando git log c'è il comandino poi se volete ve lo ve lo metto nelle note l'episodio ve lo invio su telegram che vi permette di avere una lista di punti caldi di hotspot nel codice cosa vuol dire che sono i punti che cambiano più spesso quali sono all'interno di una codebase i punti che cambiano più spesso quelli che hanno più valore implicito quindi quelli dove spesso e volte risiede il senso dell'applicazione poi se noi vogliamo vedere veramente l'evoluzione della nostra applicazione abbiamo tool di codebase visualization come gors o un altro gors o pants c'è un sito bellissimo che è graph my repo che ci permette di avere un grafo di tutte le dipendenze quindi una beard i view nel nostro progetto o se utilizzate fastify piccolo momento marchetta col mio col mio amico manuel abbiamo realizzato fastify overview in realtà tutta la parte core è merito di manuel io ho solo fatto mezza UI che ci permette di vedere appunto l'intricata relazione all'interno di un'applicazione fastify se l'applicazione appunto è grossa e super super utile quindi se usate fastify buttateci un occhio ciao manuel e avere una visione di insieme per esseri umani che siamo comunque visivi come in qualità di esseri umani siamo spesso molto visivi e avere sotto occhio tutto ci aiuta tantissimo beh e comunque tanta tanta roba ma quello che noi dobbiamo capire proprio in termini di approccio per limitare il carico cognitivo è che dobbiamo fare della regola di pareto dell'80 20 il nostro motto il nostro principio base e sul libro a filosofia o software design ci ritorno di nuovo mi raccomando se in queste vacanze di natale non l'avete letto prendevi del tempo e leggetelo c'è un pezzo interessante che dice che la complessità di un sistema non è legata solo alla complessità ciclomatica del codice ma è uguale alla complessità di una parte di quel codice quindi se io voglio stimare una comp la complessità di un pezzo di un modulo devo stimare la complessità del modulo per il tempo o l'insieme delle volte che da sviluppatori ci spendiamo sopra cosa vuol dire che se un pezzo di codice è molto complicato ci aggiungere anche scritto di merda ma funziona ed è incapsulato noi possiamo trattarlo come una black box trattare dei pezzi di codice come black box nel momento in cui stiamo esplorando una code base è l'elemento che ci permette in modo più drastico di limitare il carico cognitivo perché non dobbiamo capire cosa fa quel pezzo di codice vediamo gli ingressi vediamo l'uscita leggiamo il nome del modulo perché è ben incapsulato e sappiamo che questa roba fa la conversione degli ordini da dal nostro sistema sap al formato xml che vuole sap perfetto non me ne frega niente di come dentro ci siano interazioni trasformazioni mapping non mi interessa tutto quel l'insieme di complessità me lo evito cosa che invece mi porterei appreso se non trattassi quel blocco di codice come una black box per cui ecco saper utilizzare le le le function signatures come elementi che circoscrivono della complessità e ci permettono di trattarli da black box è un altro elemento importantissimo io non riuscivo a capire perché nella mia carriera vedevo questi senior che gli dice si ma cosa fa questa funzione o me ne frega un cazzo non mi importa non è il momento il posto dove voglio focalizzare sì va beh ma sei senior dovresti conoscerla no una ceppa conosceva la tecnica per non scavare la perché doveva raggiungere un obiettivo e questo è quello che faccio io oggi no? Altra cosa i test i test ci permettono di analizzare delle parti senza portarci appresso tutta la complessità il carico cognitivo che ci viene dal contesto partiamo dai test unitari no? Cosa fanno i test unitari? Testano un piccolo componente in modo completamente isolato dal contesto quindi se io voglio capire bene il comportamento di quel blocco io mi vado a vedere un test unitario in quel caso io sono libero di tutto a quel carico cognitivo che mi verrebbe invece dal contesto quindi vado in qualche modo a capire come funziona quella quella piccola box no? Che potrei trattare come una black box ma siccome è importante per l'obiettivo che voglio raggiungere mi interessa analizzare e poi c'è che ne so gli end to end test che mi permettono invece di avere una visione un po più ampia mi permettono di vedere i flussi mi permettono di avere tutta una serie di altre informazioni che completano l'immagine ma a quel punto io vi ho detto trattiamo dei pezzi di codice come della black box e allora come poi posso gestire i pezzi di codice che non tratto? Una cosa che ho imparato è appunto a gestire le information leftovers per ridurre il carico cognitivo devo lasciare per forza qualcosa fuori dalla scatola e lo faccio utilizzando una tecnica che è un nome complessissimo ma in realtà è di una semplicità assurda si chiama procrastinazione attiva con rivalutazione pianificata e io il nome glielo ho dato è una roba che faccio da sempre il nome glielo ho dato preparando questo questo episodio e grazie Emanuele per farmi aver scoperto per avermi detto appunto chiarito che quel modo di fare no di rimandare a domani in modo attivo si chiama procrastinazione attiva e c'è un botto di letteratura mi hai aperto un mondo no? Quello che io in realtà cosa faccio? Quello che io faccio è c'è un pezzo di codice non voglio analizzarlo adesso perfetto prima vi ho parlato della funzionalità dei bookmark di Visa Studio Code se sto usando Visa Studio Code metto un bookmark metto la data nel bookmark e poi me lo scrivo nella mia to do list quella data in realtà non è relativa al momento in cui lo prenderò in mano e quindi scaverò a fondo per comprenderne bene il significato profondo di quel blocco di codice ma riguarda il momento in cui io farò una rivalutazione se mi serve o non mi serve in questo caso io si sto procrastinando ma sto ciclicamente facendo riemergere quello che ho rimandato e facendo una rivalutazione di quello che mi serve di quello che non mi serve naturalmente poi tutto questo è scritto è scritto perché la memoria come abbiamo detto è super limitata quindi io mi faccio le mie mappine sulle moleskin e un'altra cosa che faccio molto figa sempre da questo punto di vista proprio per limitare il carico cognitivo è gestirmi un glossario sappiamo che nei nostri progetti l'ubiquitous language è l'elemento guida del progetto e lavorando in tanti progetti dove ci sono gozziliardi di acronimi ci si perde no e quindi avere sempre un glossario a portata di mano è fondamentale io non so quanti di voi leggono romanzi bene a me capitava e capita sempre quando inizio un romanzo di scrivermi i nomi di personaggi e le caratteristiche della quarta di copertina con una matita e di ritornarci costantemente quando sto leggendo i primi capitoli finché il personaggio non è entrato dentro di me la storia non si è sviluppata abbastanza da poter da aver metabolizzato quel personaggio bene faccio la stessa cosa col codice col glossario e questa cosa è veramente game changer quindi con tutte queste queste tecniche per la gestione del carico cognitivo il nostro java sturing il ranger umano cautico buono ha sviluppato nuovi punti forza destrezza costituzione intelligenza perché perché ha imparato a decidere dove mettere le mani quindi quali parti approfondire sa creare la sua mappa del codice che sta esplorando quindi in realtà si sa orientare ha imparato a gestire i leftover quindi attraverso la procrastinazione attiva con rivalutazione pianificata alla possibilità di appunto avere sotto controllo ciò che non sta analizzando e tiene traccia di tutto quindi e questo è il momento in cui javas capisce di essere diventato un signor ma allora ho capito che il coraggio non è l'assenza della paura ma il trionfo sulla paura un uomo coraggioso non è chi non ha paura ma chi convive e conquista questa paura con queste parole di nelson mandela io vi do appuntamento all'anno prossimo a questo punto ci prendiamo qualche giorno per fare un digital detox in realtà dopo i pranzi natalizi forse il detox servirebbe anche un po più fisico oltre che digitale però noi ci sentiamo con la nuovissima stagione di github dopo le festività natalizie e dopo il l'epifania un abbraccio a tutti e buon natale di nuovo ciao ciao a tutti ascoltatori ascoltateci di bar probabilmente un po in ritardo sugli auguri di natale per le feste spero di avere ancora il tempo di poter dire qualcosa allora in realtà avevo preparato tutto un bellissimo discorso articolato l'avevo scritto però pian piano sto rileggendo e mi convinceva sempre meno quindi cercherò di andare abbastanza abbraccio quello che volevo fare è anzitutto ringraziarvi ma diciamo ringraziarvi sia sia come ascoltatori sia come ascoltateci sia come membri di questa community e questo perché per me github è stato tanto è un'esperienza che è partita più di due anni fa ed è partita quasi per gioco ecco possiamo dire per fare il favore ad un amico è partita quasi per gioco per poter continuare quello che lui aveva cominciato e poterli tenere in caldo la sedia ecco diciamo così in realtà che parsi è trasformato almeno per me molto molto molto molto di più grazie a github ho conosciuto amici ho fatto delle esperienze meravigliose e sono cresciuto tanto sono conosciuto tanto sia come persona che come professionista infatti voglio anzitutto ringraziare gli altri ragazzi di github gli ammutinati che in questi anni mi hanno dato tanto ho trovato degli amici e gli devo tanto e voglio ringraziare anche tutti voi che ascoltate github e che fate parte della community di github far parte della community di github credo sia un'esperienza che vada insomma oltre il confrontarsi su un tema tecnico piuttosto che un altro tema una battuta che spesso e spesso mi piace fare che siamo diversi dai soliti asterisco asterisco in italia per non offendere nessuno anche in periodo natalizio ma su ghi su ghi par ritengo affrontare discussioni di ampissimo respiro specialmente nell'ultimo mese mese e mezzo sto vedendo veramente che le discussioni stanno prendendo un tono altissimo veramente sui massimi sistemi delle cose ed è una cosa che mi fa assolutamente piacere perché significa che ghi par è un posto sicuro dove poter parlare di tutto e non solo di di argomenti tecnici certo poi il filo conduttore che ci unisce la passione per questo lavoro e la passione per la per la tecnologia per la programmazione per lo sviluppo software in generale ma riusciamo a fare argomenti anche molto complessi con una discreta qual una discreta quantità di di flame e non è da poco e quindi credo che a me a tutti e credo che possa parlare anche a nome degli degli altri ragazzi di hit bar ci ha dato molto hit bar e ci da tanto ogni giorno e a parere mio personale posso dire che hit bar mi ha aiutato a superare dei momenti diciamo abbastanza abbastanza bui e mia e mi ha dato sempre diciamo quella voglia anche di migliorarmi dal punto di vista professionale infatti è cosa che ora la vogliamo dire tutto il mio ultimo e attuale lavoro e anche e soprattutto maieto di hit bar quindi qui non posso essere estremamente grato a questa community e quindi vi voglio lasciare dicendo che che vi aspettiamo che vi aspettiamo sul nostro gruppo telegram che vi aspettiamo su twitter e brain repo e aspettiamo le vostre mail su info e chioccio la hit bar punto hit e mi piace per una volta essere io quello che ricorda i vari contatti perché proprio è un invito a te mi ci stai ascoltando e non hai mai interagito non hai interagito con noi un po perché un po perché forse c'è un po di sindrome dell'impostore che abbiamo tutti io primis un po per vergogno un po perché magari si pensa sempre di non avere tempo entra nel nostro gruppo a telegram scrivici su twitter inviaci una mail perché perché spesso basta basta veramente poco per far cominciare qualche cosa di grande e dagli aspetti diciamo e dalla futilità in imprevedibile questo è stato hit bar per me rispondere ad un messaggio su telegram e ritrovarmi anni dopo a essere parte di qualcosa di veramente grande e lo dico non con poca diciamo e lo dico senza nessuna vergogna credo che ghit per se veramente qualcosa di diverso ed è grazie a tutti voi quindi vi auguro un buon natale un buon inizio anno e un grande 2023 e per quanto possa contare ci ci potete sempre trovare qui ciao a tutti hit bar il circolo dei full stack developer una volta a settimana ci troviamo davanti a due birre e con bri reppo parliamo di linguaggi e tecniche di sviluppo web di metodologie ed strumenti immancabili nella cassetta degli attrezzi dei full stack della occasione.