*musica* Siamo noi quelli che leggendo il codice cercano lo stronzo che ha scritto quello schifo Ma ahimè, lo stronzo è me medesimo e l'ho scritto giusto ieri *I'm sorry* Siamo quelli che santificano il nuovo framework javascript preferendo segretamente jQuery Gli stessi per il quale il testing è importante, infatti la nostra codebase ha solo due test e flakey pure Siamo noi quelli che il tuo linguaggio fa cagare, ma il mio è peggio.Quelli che la chiarezza nei comment message prima di tutto, e dentro ce l'appella tutti i santi."Se non bestemmi io guarda" Quelli che in call parlano per 5 minuti prima di accorgersi che il mic è muto.Quelli che non si può fare di default, diventa velocemente un tutto e possibile se hai le risorse, tempo e budget illimitato.Siamo noi quelli che l'AI va regolamentata, mai visto questo nuovo modello che disegna gatti in ifunambuli? Quelli che il dipende e unisci gratis la prigione.E quelli che la RAL...no vabbè, fa già ridere così.Siamo quelli che fanno lo slalom tra le specifiche che cambiano costantemente.Ormai rassegnati che la definition of ready è solo una più illusione.Quelli che si sentano dire "ho un'idea per un'app" ed è subito l'ennesimo social come Instagram, ma meno.Siamo noi che nonostante il deploy fallito, la CIA rossa, il business incazzato, ci troviamo al GITBAR e davanti a una birra tutto ci sembra un po' meno grave.Bene e benvenuti su GITBAR, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.In questo episodio un po' atipico voglio innanzitutto salutarvi e dirvi che stavo un po' riorganizzando i prossimi ospiti, i prossimi episodi quando scrollando su LinkedIn ho visto che il buon vecchio Livio mi taggava su un post e perché non rispondere? in realtà anche perché il post di Livio è super interessante e tocca secondo me un punto centrale che ha senso fermarsi un attimo per analizzare.Si parla di qualità e di analisi e di iterazioni e qua entra un po' in gioco il mio essere boomer, no? e il mio cercare di approcciare alle cose con un po' meno entusiasmo e un po' più di lucidità in termini di sviluppatore.Ed ecco perché credo che abbia molto senso quello che Livio dice e credo anche che però il fatto di non fare analisi non può essere giustificato in alcun modo.In nessun modo.L'analisi è il centro, l'anello principale del nostro lavoro ed è il motivo per cui probabilmente non ci si può sostituire con entità senza il pollice opponibile, disponibile, nel senso il valore del nostro lavoro dal mio punto di vista è 70-80% analisi, 20% scrittura del codice.Una cosa che ho sempre fatto fino a qualche anno fa è sempre stata quella di partire con uno di quegli attacchi emotivi.c'era un'idea, c'era un progetto, la prima cosa che ho sempre fatto era aprire l'editor del codice.Ma questo non sempre conduce con un risultato che ha senso o spesso porta a un numero di iterazioni molto alto, che secondo me potrebbe semplicemente essere evitato pensandoci su, dedicando tempo a ragionare e che oggi Siamo spesso disabituati a ragionare quando scriviamo codice.Perché? Perché la tentazione è quella di andare giù e iniziare a scrivere righe di codice.Il mio alter ego però, in questo caso, può rispondermi e dirmi "Sì, vabbè, ma io ragiono con l'editore aperto e scrivendo codice".quando in realtà mi sono reso conto, almeno per quello che mi riguarda, che quando scrivo codice o ragiono con l'editor aperto, quello che succede è solo un'interazione di tentativi.E non sfrutto appieno il flusso, il flusso della logica, il flusso del pensiero.Questi tentativi però, ahimè, Essendo fatti con l'editor aperto, sono più lenti del solo pensiero.E questo Livio l'ha detto nel suo post, no? Pensare è molto più veloce.Sono più lenti e il tranello è che nei tentativi noi tiriamo dentro anche elementi che non sono necessari per validare il nostro pensiero, il nostro flusso di pensieri, il nostro step di ragionamento.e quindi il tempo si dilata.E allora, non abbiamo tempo di ragionare, ma sviluppiamo, utilizzando un approccio iterativo a tentativi, a me suona come "non ho tempo di ragionare, per cui spreco tempo ragionando con un altro fattore di rischio".Lo so che forse sto portando all'estremo il punto, però secondo me è un po' così, nel senso che io non ho tempo di ragionare eppure ragiono iterazioni facendo anche.Una cosa che invecchiaia ormai, qualche anno faccio invece, è quello di chiudere il computer, prendere i miei bei requisiti e a quel punto fermarmi a ragionare, magari con un pezzo di carta o anche senza pezzo di carta se conosco bene i requisiti e li, insomma, li governo, ma fermarmi libero a ragionare.E la cosa divertente è che spesso lo faccio lontano dal computer, lontano dal mio studio.Lo faccio magari il fine settimana, lo so, non dovrei lavorare il fine settimana però.Lo faccio il fine settimana.E una cosa che sto facendo sempre più spesso è quello di sedermi in macchina, mettermi nelle cuffiette un po' di musica e fare due, trecento chilometri così, mentre ragiono.Magari portando la famiglia al mare.Tanto la bambina dorme in macchina, mia moglie si guarda le sue cose, io con le mie cuffiette per due, tre ore ragiono, sviluppo, snocciolo.nei dettagli il problema.Anche perché spesso quello che si fa con l'editor aperto, l'analisi che si fa con l'editor aperto, non è un'analisi del problema, ma è l'analisi della soluzione.E questo è un elemento importante, secondo me, da capire.Con l'editor aperto noi siamo portati a buttare giù una soluzione e iteriamo sulla soluzione.E spesso non è un approccio legato all'analisi del problema.Se invece io mi fermo e penso al problema ancora prima della soluzione, e questa cosa a me personalmente viene più facile lontano dal computer, lontano dall'editor, lontano da qualunque altra fonte di distrazione, a quel punto il ventaglio delle potenziali soluzioni mi si apre tantissimo, no? Nel senso ho un ventaglio di opzionalità che è completamente diverso.E questo secondo me è uno degli snodi principali.Per cui, secondo me, dobbiamo spogliarci della giustificazione del dire "non ho il tempo di pensare e quindi mi metto subito...non ho tempo di fare un'analisi approfondita quindi mi metto subito a scrivere il codice".Dall'altra parte, secondo me, dobbiamo invece dire Non ho tempo da perdere iterando, scrivendo codice che poi cancellerò subito dopo, in un processo creativo.Proviamo a sviluppare il processo creativo in mind, nella mente, in una fase di riflessione.Devo dire che l'inizio non è stato semplice per me.E questa cosa mi ha aiutato.Io ho individuato questo processo in realtà quando tornavo...tornando in Sardegna.In Sardegna io tendo a preferire la nave dell'aereo e ho una notte intera dove mia moglie e mia figlia dormono per pensare completamente scollegato dal computer, che lascio in macchina perché ho troppe valigie appresso, e da qualunque altra distrazione, con magari il mio tacquino.E a quel punto io sono costretto a pensare alla soluzione.Sono forzatamente costretto a non usare...a pensare al problema, scusate.Sono forzatamente costretto a non usare il computer.e questa cosa l'ho trovata molto, molto proficua per quanto mi riguarda.D'altro canto Livio porta però con sé anche, e ci sottopone anche un altro problema fondamentale, quello di farsi prendere da mille orpelli, mille feature aggiuntive mentre si sviluppa o mentre si analizza.Quando ho detto prima fermarsi a riflettere sul problema e non sulla soluzione, parlavo proprio di un approccio che presuppone un'analisi precisa del problema, la conoscenza precisa del problema, e quindi la conoscenza dei suoi limiti, dei suoi contorni.La definizione dei contorni di un problema, secondo me, è quello che fa la differenza in un approccio diretto al prodotto.Capire bene come identificare il problema e definirne lo scope è, secondo me, l'elemento...gli inglesi direbbero "pivotale", elemento centrale dello sviluppo di un prodotto stesso.Per cui, se noi partiamo tutta la nostra parte di analisi direttamente dal problema, dobbiamo aver già fatto la definizione dello scope, aver già identificato cosa genera valore.Questo ce l'abbiamo gratis con l'approccio che presuppone la partenza dal problema.Perché? Perché non siamo, avendo già identificato il problema prima di iniziare il flusso di pensieri, non siamo tentati rispetto a avere un ragionamento code driven o development driven, siamo in qualche modo forzati a pensare sul problema centrale, a ragionare intorno al problema centrale.E questo è importante.tutte le volte che ci si apre poi un filone di ragionamento, una potenziale feature aggiuntiva, quello che io ultimamente faccio è semplicemente tenere traccia con un paio di parole chiave e ritornare e dedicare magari a quel filone aggiuntivo un altro viaggio in macchina o un altro po' di tempo di riflessione, se ha del valore.Perché una cosa che forse sempre più spesso ci dimentichiamo è che noi, alla fine dei conti, dobbiamo generare valori di business e dobbiamo farlo con una certa lucidità.Se non lo facciamo, non c'è ragione per cui delle persone debbano pagarci.Per cui, insomma, secondo me l'elemento è, o almeno il mio approccio qui è, concentrarsi sul problema, identificare il problema, definirne i contorni.Non abbiamo ancora pensato a una soluzione.Poi magari una soluzione ce l'abbiamo, però abbiamo definito il problema.Abbiamo buttato giù il problema e abbiamo anche, magari, no? definito il suo valore di business.Formalizzato, scritto in qualche modo, anche due righe sono sufficienti, no? Però dire "questo problema è incontrato da le persone che utilizzano questa applicazione oppure che hanno questo caso d'uso, le persone sono in questo contesto" e dobbiamo agevolare questo tipo di cose.Una volta formalizzato il problema, noi abbiamo una linea guida per iniziare la nostra riflessione.La riflessione sul problema, smontare il problema ai minimi termini.Una volta che il problema è smontato ai minimi termini, in realtà, viene quasi automatico visualizzare delle potenziali soluzioni.Buttiamo giù le soluzioni e per ogni soluzione magari interiamo con un processo di ragionamento.proviamo a visualizzare il codice o lo sviluppo, l'approccio, ancora prima di scrivere.Siamo esseri umani, la visualizzazione è uno degli elementi che sappiamo fare meglio.Ed è anche l'elemento che forse ci stiamo sempre più dimenticando, perché non alleniamo quella che è l'immaginazione, il flusso di pensieri.Questo perché siamo distratti da mille cazzi, social network, mille stronzate.Però, secondo me, una volta che abbiamo fatto tutto sto processo di visualizzazione, allora iniziamo ad avere degli elementi che iniziano a emergere, degli elementi che sono tipo intuizioni, no? E riusciamo chiaramente a identificarli.Buttiamoli giù e a quel punto iteriamo, diamoci magari time boxando, iteriamo sulle intuizioni.Una volta che abbiamo pressoché identificato due o tre approcci, magari a quel punto ha senso fare dei documenti tipo IDR, dove diciamo approccio 1, questi sono i vantaggi che ho pensato, approccio 2, questi sono i vantaggi, punti di debolezza, bim bum bam che ho pensato.A quel punto ha senso fare un bello spike per sbattere la faccia con i limiti tecnologici, i limiti del linguaggio, i limiti dei framework, ma questo solo dopo che ho pensato a una soluzione.Perché se il framework mi mette dei paletti e mi dice "ho il linguaggio, questo non può essere fatto con questo linguaggio", Probabilmente il problema spesso non è legato all'idea, se abbiamo investito tanto, ma forse è perché vogliamo mettere, stringere i bulloni con un martello o mettere i chiodi con una chiave inglese.E questo si apre nel momento in cui, questa opportunità si apre, nel momento in cui ci diamo il tempo per pensare.Lo so, ho blatterato per praticamente 15 minuti su delle robe tipo il nono Simpson, come vecchio rantista da strapazzo, però io credo che, insomma, questo sia diventato anello centrale del mio modo di approcciare le cose adesso, in tarda età direi.Scherzi a parte, io ringrazio davvero Livio per aver lanciato insomma questo post che mi ha spinto a lasciare un messaggio vocale.Probabilmente tanti avranno detto cose più e anche molto più velocemente rispondendo al post LinkedIn, ma io volevo fare a modo mio, insomma, con un episodio, anche se ristretto, insomma, un episodio podcast.Nelle note dell'episodio vi lascio il link a Livio, al post di Livio e tra qualche minuto, il tempo di trovare una piazzola di sosta per fermarmi, ringraziamo chi ci sostiene, chi fa sì che il nostro podcast possa arrivare alle vostre orecchie con una birra virtuale, invitandoci una birra virtuale.E' buon! Ormai sono praticamente arrivato a destinazione.Ero alla ricerca di una piazzola di sosta ma non ne ho trovata.A quel punto finisco il video arrivando a destinazione.Questa parte del video è per ringraziare chi ci sostiene nonostante la nostra presenza poco assidua a questo periodo.Però vogliamo comunque ringraziarvi per la fiducia che ci state dando nel sostenerci.Intanto devo ringraziare Lorenzo Jovino che ci invita tre birre scrivendo "Ho iniziato ad ascoltare Gitbar dalla puntata 1 nel 2023, sto recuperando, con la speranza di essere eletto in una futura puntata come donatore di birra".anticipo e in realtà ahimè PayPal taglia il messaggio quindi non possiamo finirlo di leggere per cui se Lorenzo vuoi inviarci il messaggio anche via via via telegram ci farebbe super piacere Intanto grazie Lorenzo per le tre birre.Abbiamo anche il buon vecchio Livio che la settimana scorsa ci ha inviato un messaggio scrivendo "Ciao Mauro, ciao Muttinati, spero stiate bene.Le solite tre birre, come spero, siano di stimolo per continuare a fare puntate anche se capisco che gli impegni lavorativi..." E poi PayPal "Ah, ahimè, di nuovo ho tagliato il messaggio, cosa mi fa arrabbiare PayPal, mannaggia voi".a voi.Livio anche tu per favore inviami un messaggio su telegram così nella prossima puntata la lo leggo.Intanto voglio super ringraziare Lorenzo e Livio perché nonostante tutto continuate a supportarci grazie di cuore e io qua dal fiumiciatolo vicino a casa mia volevo ringraziarvi di nuovo e darvi l'appuntamento a maybe settimana prossima.Quindi un saluto, un abbraccio e ringrazio nuovamente Livio per avermi tirato in questa conversazione che mi ha costretto a fermarmi un attimo, a riflettere e poi a rispondere.Ciao ciao, alla prossima!
