Ciao! Questa puntata è un po' particolare perché è una puntata in due parti.Quella che state vedendo è la seconda parte dell'episodio.La prima parte la trovate nel canale di Continuous Delivery qua sopra oppure se ci state ascoltando via podcast come immagino state facendo nelle notte dell'episodio.È una puntata in due parti che abbiamo registrato insieme a molti di voi al Fosdem e dove insieme a Edo, Paolo, Alessio e Carmine e a molti di voi appunto abbiamo parlato di cose varie tra cui anche alcuni argomenti tipo politico riguardo il software.Quindi niente se non l'avete ancora fatto cliccate nelle note dell'episodio per vedere la prima parte e se no buon ascolto.Comunque tranquilli adesso Paolo ha esaurito l'autonomia, l'avevo alimentato per 28 minuti.Posso ancalzare il touch screen? Anzi, do' sto microfono a qualcuno.No, no, non ti preoccupare.Tiro lo pure a cello.Sì, ma lo do' a qualcuno.Tipo.Perché poi la tua platea...Facciamo una domanda così alla platea che fa molto forum.Siamo noi che nonostante il deploy fallito, la CIA rossa, il business incazzato, ci troviamo al github e davanti a una birra tutto ci sembra un po' meno grave.Secondo voi qual è la nostra responsabilità etica nei confronti del software che scriviamo? E' una domanda complessissima, qui io non ho la risposta quindi per questo la faccio poi.Anzi non ho neanche capito la domanda.A te ti vedo etico.Innanzitutto documentarlo.Ti piace vincere facile.E anche farlo funzionare a volte.E quanti story point ci dai alla documentazione? Allora, io devo dirti che vengo da un esame CKA di Kubernetes e devo dirti che la documentazione è tutto, è tutto quello che serve per poter fare questo e se scritta bene, non come...vabbè, meglio non...La scrivo io tipo...Tipo la documentazione di Spring, eh? Dicevo, è fondamentale per esempio documentarlo, il software.Bene, fatto per bene.però questa qui è una responsabilità nei confronti dei tuoi pari, non della collettività, io dicevo responsabilità nei confronti dell'utente finale che utilizza quel tuo prodotto, cioè quante volte vi è capitato, io sono in primis che sto facendo una roba magari...Parla nel microfono scusa, se no si sente la mazza.Prova.- No, allora, no, quello che sto dicendo, io parlavo diciamo di responsabilità nei confronti dell'utente finale, ok? Quante volte vi è capitato...e io sono in primissima, magari sto facendo qualcosa di critica, che magari so che utilizza anche quel particolare tipo di utente, però funziona, non funziona, i test posso scrivere meglio, posso scrivere...ma che cazzo mi frega, ok? Cioè, io sono il primo che l'ha fatto, ok? e secondo me io ho avuto una mancanza di etica professionale per fare questa cosa.Cioè, se il medico si dimentica il bisturi nel paziente, noi possiamo tutti dire qui che è meglio il merda.O che comunque nel fare quella cosa là, insomma, non è stato proprio al massimo.Possiamo chiamarlo pressappochismo.oppure magari l'ingegnere che fa là a casa però poi cade ok perfetto e allora possiamo dire la stessa cosa anche di chi fa il software e poi si rompe dai servizi non fa oppure può essere dire ma me che me ne frega tanto è software rideploy o è web refresh o è tanto perciò sta al kubernetes.Ma questo però dovresti dire che tipo di software, per quale obiettivo? No, secondo me vale per qualunque software.Se il Fagname mi fa una sedia, io mi siedo su questa sedia e si rompe, cado, mi spezzo la gamba.Però vedi, tu lì stai valutando non stai stavolta l'impatto che ha quella cosa sulla tua vita e dovremmo capire quando tu scrivi un software riesci a calcolare gli impatti che quel software avrà sulle vite delle persone io credo che nel 90 per cento dei casi possa come software fai non so se tu lavori a un blog No, va bene, però nel senso è un caso limite anche se sto facendo l'herp per la palestra, il fatto che comunque non funzioni, le persone non si possono iscrivere in questa palestra e possono prendere una grafica.E quindi allora a questo punto stai creando comunque un disservizio all'utente, però questa cosa viene comunque percepita in una maniera diversa, cioè anche da persone del nostro mestiere.Io ho conosciuto colleghi, produttor, scrum master, persone vati della formazione, diciamo "sì va bene, non funziona, ma che cazzo ti frega le fresce?" Cioè, hai capito? Nel senso, il pressappochismo è accettato.Io invece voglio immaginare che non ci siano, io non mi immagino questi ingegneri edili che stanno sotto il ponte e fanno "comunque fatto proprio a cazzo di cani il pilone, vabbè cazzo te frega cade, rifrescialo eh, hai capito? fai niente, lo rifacciamo e se ne va così però, però in realtà i morandi i morandi, vicino a casa mia è successo così, guardavano a roba, chi se ne frega no beh, te l'ha fatta faccia la velina il video ci parla del morandi il discorso, il discorso del genere che me ne frega come lo sviluppatore in Liguria è successo con i morandi Ponte Morandi che controlli non ne facevano, sapevano i fatti, non andava bene, ma chi se ne frega, così via, 43 vittime.Ed è andata bene.Ed è andata bene, perché io ci sono passato più volte su quel ponte, se veniva giù in un altro momento non ne faceva 43, moltiplica.Però secondo me come sviluppatore noi una responsabilità ce l'abbiamo e in parte è tra le ragioni lui.scrivere codice buono nel migliore modo possibile e con i migliori crismi possibili.Però voglio aggiungere una cosa, scusa Sirio se ti interrompo, pensavo a me oggi, io costantemente faccio questo tipo di discussione con mio fratello che fa l'architetto e quello che in realtà cambia tra la mia visione e la sua è che lui ha una visione di immutabilità dell'artefatto, molto chiara, cioè per lui quell'artefatto è quello per cui presuppone un effort iniziale importante.Quando mio fratello fa il progetto col suo pool, si compara ingegneri, le cose, quando si siedono il culetto sulla sedia a fare i calcoli, un per 5, per 3 lo fanno sempre, tanto che è legge, le portate vengono moltiplicate per situazioni fuori dal realistico.Quando noi, adesso, bold opinion, mi sto gasando, quando noi utilizziamo un alibi chiamato agile il più delle volte per supportare l'attesi...Stiamo scendendo in un territorio...Perdonate...La penso come te, vai avanti.Per supportare anche delle tesi con la continua mutabilità del software, per supportare delle scelte fallimentari in termini di design, che devono essere fatte per responsabilità, a questo punto mi dico, siamo ancora dei bambini che giocavano col 386, Adesso il 386 ha una forma diversa, ma non ci vogliamo prendere a livello mentale ed approccio una responsabilità di un certo tipo.Adesso l'agile va bene, il nostro artefatto è mutevole, però è mutevole a patto che il design sia fatto per prevedere un minimo futuro.Almeno un minimo cazzo! Scusate, mi sono...ho una pastiglietta? No, eh...Guarda, io ho una di Postgres.Io comunque, io lo capisco quello che tu...Io capisco quello che te dici, Mauro.Però il problema è...Troverò...il mio Scrum Master mi manderà una testa di cavallo sotto la casa.Lo accendi tenendo premuto qua.Ma, però, c'è sempre una cosa che vorrei aggiungere.Che mentre se tu fai una casa e crolla e c'è uno sotto, la tua responsabilità è evidente quando tu progetti una casa che non deve crollare.Ripeto che se te fai un modulo Wordpress che converte i jpeg in png non hai la stessa responsabilità, non puoi avere lo stesso tipo di...Se io lo uso e sto facendo un software critico devo avere la stessa cazzo di responsabilità.Ma siamo passati in un altro ambito però.Se sto facendo il mio sito devo avere la responsabilità limitata all'impatto che questo sito sta facendo.Se sta facendo open source discutiamone.Ma è come dire che tu quando costruisci la cucetta del cane devi avere la stessa possibilità che quando costruisci la casa e non è così.No però fai male la cucetta del cane, fai schiattare il cane di mia moglie e poi ne parliamo.Va bene adesso al di là delle battute però è ovvio che l'impatto è diverso.Si ma fai una valutazione.Però però capisci che questo tipo di lassismo io lo sto vedendo dappertutto e mi è capitato anche di lavorare in ambienti critici dove sono entrato per cercare per lavoro per cercare di sistemare la situazione e ho visto i mostri i contromostri gli arci mostri.Ma li abbiamo visti tutti certo infatti.No no no.Non ho mai visto.Anche noi abbiamo lavato in ambito pubblico.Noi in linea di principio mettiamo a posto i mostri.Esatto.Cioè come se lo facciamo di più è prendere.Come? È una mission.Però è lì è facile vedere l'impatto.Tu dici sto facendo un servizio pubblico dove le persone devono mettersi in coda per ottenere un servizio fondamentale allora quello lì è mia responsabilità.Se quella roba lì non funziona sto facendo un danno magari enorme delle persone.Ma allora lì hai la responsabilità e lì secondo me la legge interviene e giusto che intervenga anche in fase di progettazione, architettura del software, però non puoi portare lo stesso grado di attenzione e responsabilità a qualunque software.Come dire faccio il risotto per me e faccio il risotto da crac.Mi fucilano se lo faccio sbagliato.Però sono d'accordo con Sirio sulla responsabilità, questo non per questioni di critiche e quant'altro, ma proprio semplicemente perché noi operiamo in un contesto di condivisione e poi Andrea che parlava di documentazione, per me, in generale per noi in Spark Fabric, ma questo perché continuo a dirlo tutti quelli che entrano quindi se se lo dimenticano poi glielo ripeto, però ci siamo tutti d'accordo, vale la legge del Boy Scout, lascia il posto meglio di come l'hai trovato e questo vale dove il posto, il sotto della documentazione, questo al di là proprio della questione degli impatti più o meno problematici che possono avere a livello sociale è proprio per la questione che io sto lasciando una cosa che ho preso, posso prendere quando mi pare comunque, che è già capitalizzata, è già creata da qualcuno e la mia responsabilità è pensare al prossimo che arriva che non vuole trovarsi in un posto, visto che tu parli francese, completamente smerdato, no intendo francese, non vuole trovasi in un posto che cacchio entri e devi metterle galosce, entri e dici ok ho capito dove stanno le cose mi sembra pulitino poi magari non è esattamente pettinato però posso metterle male di quelli di là so dove sono girato e mi viene voglia di lasciarlo così se non meglio perché se entro in un posto dove per fare una contribuzione di due righe devo stare sei settimane capire dove sono girato la faccio perché se no è una vera e poi quando arrivo con la con la pr questa roba qua fissa un problema che fa funzionare questa roba al triplo delle performance, ah, fighissimo, sta sei settimane a decantare in botte e nessuno la guarda, è la prima e l'ultima volta che faccio una contribuzione a quella roba, a meno che non ne vada della mia vita, perché per il resto della mia vita me la vivo altrove, no? Perché se invece abbiamo questa accortezza, sicuramente facciamo un favore innanzitutto dello stesso ecosistema in cui mettiamo le zampe tutti i giorni.Questo proprio sfondi per me d'accordissimo.Questa è una responsabilità sociale nostra nei confronti nostri.Tolta la politica, tolta gli interessi, tolto tutto.Bellissimo mi hai triggerato un'altra domanda, apriamo un altro trigger di flame.Però vuoi la parola? Quanto si sovrappone con la parte etica? Anche sul software etico? nel senso io posso fare un software per armi o qualsiasi cosa insomma che non sia per missili per esagerare, può essere anche pubblicità aggressiva oppure qualsiasi sforzo esamico cioè quanto si sovrappone la parte etica perché anche quella cioè nel senso sì io io aggiusto cose, magari aggiusto software che non è etico o per me non è etico.Certo, allora secondo me in linea di principio...non è che l'hai chiesto a me effettivamente però...ma mi rispondi...mi rispondo, scusami infatti perché mi guardavi negli occhi e ho avuto la tendenza a curare...no no ma...non è che l'ho fatto così...no, secondo me sono due piani etici, cioè uno è il piano...perché se stiamo facendo software, stiamo comprando di open source, ma in generale se io sto facendo una cosa secondo me è mio dovere etico farla bene e consegnare al prossimo che arriva qualcosa che sia come detto adeguato.Possiamo chiamarlo deontologico.Sì, è un dovere deontologico più che etico perché poi forse sicuramente non è un dovere morale, non è che varia da lì là, però ed è etico avere cura dell'artefatto.Poi se opero in un ambito, quindi se opero bene, eticamente bene, in un ambito che fa eticamente male, a mio parere, i casi sono che o cambio ambito se posso, perché poi lo sappiamo benissimo che la vita è la vita, però io non saboterei o non me ne sbatterei di fare il mio lavoro male per qualcuno che o mi paga, non so se esistono sistemi open source per la guida dei missili, sarebbe interessante, magari, - Anche l'Italman...- Però non escludo che codice open source...- ...un prodotto piuttosto che un altro rispetta le richieste del, diciamo, del cliente o...- Sì, sì.- Ma magari non quelle dell'utilizzatore finale, perché l'utilizzatore finale magari vuole un prodotto...- Però posso provocare? Siamo anche un'industria un po' fortunata da quel punto di vista, o almeno io mi reputo fortunato.- Beh, possiamo scegliere un sacco rispetto alle altre.- Perché rispetto ad altre industrie, rispetto ad altri lavori, molte situazioni possiamo anche rifiutare.Adesso sta un po' cambiando la situazione però fino all'anno scorso, a me è capitato più di una volta di rifiutare contratti per lavorare sul mondo del gambling o fare push back di qualche società che realizzava software per armamenti italiana.Ho già detto il nome a un altro nemico sotto a casa.Però questo non è open source, fermati qua, ti prego.però c'era del tanto codice open source dentro, tanto, credimi perché mi hanno spiegato lo stack e mi hanno chiamato per quello stack, quindi alla fine mi chiedo cioè mi dico da questo punto di vista siamo fortunati però c'è una provocazione che mi ha triccherato Paolo giusto? Io qui non mi faccio faccio cagare però noi siamo una serie siamo mediamente una borghesia moderna possiamo perdonate mi chiamerete compagno Mauro alla fine di questo episodio però ci possiamo reputare possiamo reputarci una borghesia moderna nel contempo spesso sospendiamo il tipo di giudizio che stai dicendo e lo sospendiamo molte volte, almeno in ambito internazionale, questa è la mia prospettiva, vi prego contraddicetemi, ditemi che non è così perché almeno dormo meglio la notte, lo contraddiciamo perché guidati da un elemento a tre lettere chiamato RAL.Io vedo molti dei miei colleghi che dicono si ha cose abberranti in nome della RAL, in nome del Dioral.Guarda, intanto che prendi il microfono tu hai aperto dicendo "No ma perché dobbiamo farlo, qual è il motivo?" e volevo dirti guarda 99% delle volte RAL, si che è la fine.Che poi appunto...- Il pagliotto li portavo a casa.- Infatti, sì beh ma poi dopo il pagliotto c'è tutto il resto, capito? - Allora noi ci siamo scontrati settimane su questo, su questo discorso.- La cosa più grave è che non hanno l'indenità quella tipo se lavori alla Philip Morris, siccome lavori in un settore di dubbio scopo diciamo allora di dubbia moralità - Hai l'indenità prima di stomaco - C'hai l'indenità si, te guardate allo specchio la mattina te danno altri sordi in più - Ogni uomo ha il suo prezzo - Ragazzi cioè nel software sta cosa ancora non esiste e è brutto perché si fa veramente finta di non vedere cioè se tu lavori a Leonardo e fai i missili e li mandi in testa i nostri amici palestinesi questo succede, te dicono "ah no no va tutto bene, te paghiamo i..." Guarda io credo che esista, ci sono degli ambiti dove chiaramente sei in una in un sistema moralmente eccepibile, dall'altra parte la difesa per esempio C'è gente che per fortuna da un certo punto di vista che lavora nella difesa e si chiama difesa.Poi è chiaro che ci sono dei guerrafondai che fanno un casino però giustamente dici guarda che missili so che sono cose brutte però siccome le cose brutte avvengono e il mondo non è inerentemente bello e giusto quindi io sono anche orgoglioso di poter lavorare questa cosa che speriamo di tenere sempre come l'airbag nel cruscotto della macchina.Come il deterente nucleare dicevo.Ma adesso...Aspetta un attimo, prima di cambiare, nell'open source, visto che parliamo di open source, visto che siamo a FOSDEM, quando tu rilasci open source un tuo software, come fai a sapere come poi verrà usato quel software e anche se lo saprai, fai a impedire che venga usato visto che fino a prova contraria l'open source può essere utilizzato per qualunque...Non lo faccio, modalità medici senza frontiere, io quando faccio open source entro in modalità medici senza frontiere, curano tutti.Esatto, ma qui allora però il discorso etico mi cade.No.Parlavamo di missili...A bomba atomica so conti, si si so tutti i conti, è un foglio di carta.Esatto, esatto, esatto, per esempio i fisici che hanno lavorato, i matematici che hanno lavorato alla bomba atomica, si sono posti con questo problema, però d'altra parte hanno costruito teorie e hanno costruito calcoli sulla base di teorie precedenti che invece non avevano la finalità della bomba atomica.La scienza funziona...no, no, precedenti.precedenti.Allora come facciamo a definire qual è, qual sarà l'utilizzo di una tecnologia che scopriamo oggi o che produciamo oggi o che rilasciamo oggi? Anche i missili di Leonardo, certo però con la stessa tecnologia magari facciamo i razzi che porteranno l'uomo su su Marte.Quindi...A rompere le palle pure lì, pensa! Quindi riusci che l'etica a quel punto diventa discutibile perché si basa sull'utilizzo di una tecnologia, non sulla sua creazione, non sul suo concepimento.No? Su questo...Microfono.Aspetta, vai.Su questo ti faccio un lupo, torniamo alla domanda anche di prima della responsabilità.Se io creo una libreria oggi e dico a chi se ne frega tanto per il mio uso e consumo e domani finisce in software infiniti qual è la mia responsabilità come la calcolo? Appunto non la calcoli, non la puoi calcolare, a meno che tu scriva delle licenze del software - Guarda che siete microfonati, quindi se parlate...- Scusami, ho la generica...- Volevo dire...- Parlando non si sentiva...- Se tu riesci a produrre, o scrivere una licenza che entra nel dettaglio di come quel software può o non può essere utilizzato, allora questo lo puoi fare.Allora, questo discorso lo puoi fare.Però, se sei semplicemente il Don't Be Evil di Google, cioè allora è talmente generico che dice "Vabbè, non fate delle cose cattive con questo software".ma che cosa vuol dire? Che poi cancellano pure.Che poi cancellano, però capisci che è talmente generico che non vuol dire niente.E' come il missile, la difesa, non sparare sui buoni, no? Non vuol dire niente.Chi sono i buoni? Chi sono i buoni? Eccetera.Oh, comunque siamo arrivati, siamo partiti dal software, siamo arrivati a parlare di Massimi Sistemi sono super felice di questo sci film.- Non pensavo di parlare di due cazzate, invece no, niente.- Invece niente cazzate.Sembra un film della DC Comics, cavoli.- Ma d'altra parte il Fosdame ci triggera queste questioni filosofiche, etiche...- E politiche anche.E questo fa parte proprio del bello del Fosdame.Ne parliamo l'anno scorso in un'altra puntata pirata così e alla fine uscì un un discorso di quel tipo, no? Ti ricordi? Qualcuno di voi ha sentito l'episodio? - Sì, sì! - No, per esempio parliamo molto della differenza tra free software e open source che ha un confine che è marcato, è visibile ma anche tra gli additi al lavoro i lavori sembrano...- C'è molta dispersione semantica sul termine, l'altro in maniera intercambiabile e tutto quanto.Anche utilitaristica proprio sul concetto, cioè l'uso del concetto proprio perché ci fa comodo definirlo così o definirlo così.Quindi questo è il bello del Fosdem.Quanto siamo? Un'ora e un quarto? Un'ora e un quarto.Bene, tranquilli.- Sì, è vero, è un quarto, è un quinto episodio.- Esatto.- È live.- Si può fare.- È live, quindi...- Che a me peraltro c'è anche il discorso...Volevi chiudere? - No, no, io volevo riaprire.- Ah, volevi riaprire? No, perché poi tu parli di etica.- Io? No.- Se tu parli di etica, mi dovresti riuscire a definirla.E tra l'altro, tra l'altro, l'etica e la morale non sono uguali in tutti i popoli, tutti i paesi, in tutte le società, invece il software è universale.Quindi tu dovesti trovare un modo...Non è vero, gli americani usano tantissimo C#.Che non è universale per niente.Ti spiego, dal punto di vista dialettico mi stava portando in una strada talmente accidentata con degli buchi che io dovevo sviare assolutamente perché se no mi avrebbe mangiato.O semplifichiamo, e allora c'è il don't believe all, o se no se vogliamo andare nella complessità della situazione allora dobbiamo metterci nei panni delle persone che vivono in cultura diversa della nostra, che devono usare magari i software che schiviamo noi, che prendiamo di principi diversi, e allora cos'è etico? Guarda, io da questo punto di vista ho la mia esperienza personale, io vivo in una famiglia multiculturale e per esempio ho tanti amici che fanno del software bancario che segue le regole della sharia e capire e riuscire per me, entrare in quei meccanismi è stato veramente faticoso, ma anche solo, l'ho detto qualche volta, mia moglie è musulmana, anche solo proprio cercare di costruire una comunicazione al di là proprio è stato molto faticoso, però alla fine genera valore.Sa cosa dal punto di vista di software? Io ho scoperto delle cose, dei meccanismi, delle dinamiche che possono essere condivisibili o meno, ma sono completamente diverse dalla mia e mi hanno aiutato proprio ad aprire gli orizzonti.Ti hanno arricchito, certamente.Ti possono arricchire.Alla fine noi siamo l'insieme e le connessioni che facciamo tra tutti questi elementi.Noi siamo quella risultante.O almeno parzialmente, perché se no anche la coscienza, che cosa potremmo rimanere.Ma se finiamo a morire vado a vivere con lui.Ma dicesti che volevi svoltare? Sì, no, in realtà mi stava, mentre parlava, perché parlavamo di responsabilità ancora prima di parlare di etica, pensavo anche alla responsabilità che noi abbiamo verso, quando parlavamo di qualità del software, verso gli upper levels, verso il management.Noi parliamo sempre del debito tecnico, gestire il debito tecnico, piuttosto che la documentazione.Ma questa roba non si fa da sola.E noi possiamo essere bravi quanto vogliamo, ma abbiamo degli allocamenti di tempo.Allocamenti, ragazzi.Questa è la neolingua di Mauro Moro.Io ti ricordo che sono andato a letta alle due e alle quattro sono partito.Cosa hai andato Ho la mia giustificazione.Potremmo scrivere qualche commentazione su questo.Ma si può accadere in argomenti tipo blockchain, RAL, Angular versus React? Blockchain! Sull'intelligenza artificiale.In realtà l'intelligenza artificiale ha GPT, ci ruberà il lavoro.Parliamo di...No, no, però invece secondo me questa cosa è altrettanto flame generator, ma da un punto di vista diverso.Cioè che responsabilità abbiamo noi verso il management è evidenziare l'importanza di questi elementi che non hanno o almeno non dimostrano un immediato impatto verso le classiche KPI del business.Cioè scrivi documentazione, va bene, sì, quanto ci vuoi mettere a scrivere documentazione? Se la scrivi bene talvolta prende più tempo che scrivere il software.E alla fine il management ti dice sì va bene ma noi deliberiamo software, non documentazione.Per capire che quella documentazione è importante deve capire che ci deve essere il turnover del team e quando vai a onbordare i nuovi membri del team ci capiscono un cazzo e al posto di essere up and running con lo scrivere codici e essere operativi subito appareno quattro mesi.- C'è neffetale.No, mi avuto.- Ma questo, questo, cioè intanto, abbiamo qualche chance di poterlo far capire all'upper level.Prima cosa.Seconda cosa, che strumenti abbiamo per farlo capire? E terza cosa, qual è il campanello d'allarme che ci deve portare a dire ok, questo posto non è per me, non le dimissioni.- Scusate ma...la RAL? No, che...a che ora abbiamo l'intenzione di chiudere questa cosa da mattina? - Mezzogiorno.- Mezzosera.- Lo prendo l'aereo per tornare a casa.- Mezzogiorno.- E' le 7 di sera, quindi...- Il problema è se poi...- Betta, betta.- Il problema della Red Flag è, fin tanto, che ti ascoltano.momento in cui non ti ascoltano più.Ma hai strumenti per farti ascoltare perché io ho vissuto, cioè io ho messo i panni di entrambe le cose.Ok.Io ho messo i panni dello startupper che doveva deliverare per forza qualcosa perché doveva fare, doveva capire, validare l'idea, doveva iniziare a tirare un po' di soldi perché come come disse il buon Matteo Collina dall'albero delle banane.- La documentazione l'hai scritta, non è stato questo? - Io? - Comunque la facevi scrivere.- Dovete parlare in microfono, se no non si sente la vostra.- Allora, in quel caso, in quel caso...- Dicevo, la documentazione la facevi scrivere o la scrivevi? - Allora, in quel caso io ho vissuto un conflitto interiore.- Oh la madonna, è proprio una...- No, credimi! - Ma se l'hanno terapista? Ha causato un brucione? Quella è la risposta.E la cosa che viene perché è in esistenza.Quella è la risposta perché non è il mestiere del manager fare questa cosa.Sono i diversi che devono parlare anche se...Lo so, però è il manager che alloca il budget.E quindi cosa fai? Non ci può entrare il manager.Quali sono gli strumenti che tu, tecnico, tu delivery architect, tu CTO, tu responsabile tecnico del progetto, hai Per sederti al tavolo degli stakeholder, dove la parte tecnica è uno degli stakeholder.Certo.Guarda...Quali sono gli strumenti dialettici che utilizzi nel tavolo? Ricatto! No, guarda, guarda.Secondo me, secondo me Sirio ha preso una cosa fondamentale.Quando smettono di ascoltarti.Allora, io ho fatto un talk all'OIAD, ma poi l'abbiamo rifatto giovedì in ufficio, un po' stringato, no? sull'agile, che oggi è corporate agile perché l'agilità è diventata progressivamente una parolaccia e sono d'accordo, ad agilista della seconda ondata oggi non faccio fatica a parlarne perché ti guardano male, e c'hanno ragione.Io sono contemporaneamente manager e informatico perché comunque sono uno dei soci di Spark Fabric quindi gestisco una parte dell'azienda e dall'altra parte però ho sempre l'animo informatico, sono tutti informatici fortunatamente e poi nel weekend mi diverto scrivendo codice.Noi continuiamo a considerare i manager come gente che non ascolta o gente che va in qualche modo convinta del fatto che devono guardare anche noi, noi siamo un male necessario.Allora, prima di tutto, più in alto è il manager e più vincoli ha.Infatti la tua domanda è assolutamente pertinente.Quando eri tu a gestire la cosa, l'hai scritta la documentazione o sei andato a validare? e tu dici "ho vissuto un conflitto interiore" certo perché il mestiere del manager è vincolato verso i soci, i founder, cioè i founder quelli che mettono i soldi, il fisco, lo stato, il regolatore, le persone che lavorano in azienda, le RAL, appunto, no, cioè il manager deve fare tutto per tutti, poi diciamo "eh ma il capo arriva tardi, gli vuoi concedere almeno quello, questo povero Cristo? Poi il povero fa se no, però Cristo.Quindi, quando è che un manager si merita...innanzitutto il manager merita sempre ascolto, perché se vogliamo che ci ascolti noi dobbiamo ascoltarlo.A volte noi siamo lì a dire "no, ma sto software deve funzionare così per gli utenti".Ragazzi, c'è anche l'organizzazione che lo paga, questo software, che ha delle mire, e magari non è detto che l'utente che non conosciamo e che quando lo conosceremo diventerà un rompipalle tremendo, sia veramente così meglio del manager con cui invece che il nostro collega con cui abbiamo a che fare, perché noi idealizziamo l'utente finale spesso, mentre invece con lui lo conosciamo, sappiamo quando ci rompe le scatole, quando è simpatico, con chi se la fa in ufficio e quindi abbiamo tutta una superficie di concettualizzazione d'attacco che non ci permette di idealizzarlo, ma anche l'utente in fondo è una persona e appena comincia a lamentarsi ti sta più sulle palle del manager che ti dà una mano prima.Quindi a volte l'organizzazione va ascoltata come uno degli stakeholder e a volte, ragà, bisogna lavorare al meglio possibile dove è possibile la parola fondamentale.Se tu dai ascolto veramente e ti interessi a capire quali compromessi devi prendere, io nella mia esperienza personale, che non è esagerata, dall'altra parte persone incapaci di ascoltare e di venirti incontro, che non vuol dire farti fare tutto quello più buono a divinirti incontro, non ne ho trovate tante.De solito comunque se sei bravo a creare rapporti umani, i rapporti umani ti tornano indietro, anzi diventi una persona incredibilmente affidabile a cui loro parlano per capire, perché non vogliono fare male.In generale, rubo una cosa che ha detto Marco Provaglio, per chi lo conosce, non ci sono buoni e cattivi, il sistema tende a preservare se stesso e a difendersi dal cambiamento, e il sistema non è una roba complottista.I sistemi sociali sono sistemi emergenti, nel termine di teoria della complessità, presentano comportamenti complessivi che sono più della somma delle parti, come un organo del corpo è più della somma delle cellule, a funzioni che la singola cellula non ha.Il sistema sociale, che è l'impresa o la fondazione o il gruppo di persone, il gruppo di quelli che si mettono qua a fare questa ha comportamenti complessivi diversi dalla somma dei singoli.E quell'entità che noi non consideriamo aliena o del tutto impersonale ha un suo modo di comportarsi e cerca di preservarlo, come noi preserviamo noi stessi.Quindi il dialogo, l'ascolto, il fatto di mettersi con la skin in the game, dire "ma io lo farei, se io con questa cosa ci mangio da solo", parlando di RAL, se questa data la devi dare da indietro, ce l'investo settimane a fare la documentazione perché magari domani assumo uno che mi dà una mano e deve capirlo, forse no, forse la metto sul mercato, tento a monetizzare così assumo quello là e poi gliela spiego e poi ora che gliela ho spiegata quello, gliela spiego quell'altro, poi siamo in trenta e non ci capisce un cazzo nessuno, è così, però è così.Io vivo un mondo del genere tutti i giorni, nel senso non che non c'è comunicazione per l'amore del cielo, però su una cosa in cui ci ha messo mani chiunque, chi più, chi meno, tutta gente che per altro buona parte conosco, anche quella che c'era prima, però adesso si vede dove è stata fatta la documentazione a modo e dove no.Io che sto entrando in quel sistema lì, tante volte ho personalmente, lo dico appetamente perché l'ho spiegato anche ai miei manager, al capo direttamente, poi noi siamo piccola azienda, quindi siamo meno di 10 da tutti.Io a volte perdo più tempo a capire dove mettere mani, tra virgolette, monolite PHP 5.6 e vi ho già detto tutto.Ok? - E' davvero questo uomo, qualcosa di forte.Ora capisco molte cose di te, Sirio.- Molto forte, credimi, a volte molto forte.Però faccio più fatica a capire dove mettere le mani a poi scrivere quelle dieci righe di codice che fanno la cosa.- È più difficile leggere i codici che scriverli.- Ma non c'è un modo, a volte non c'è un modo, cioè se qualcuno avesse scritto quelle tre righe di commento solo per la funzione...- Certo.Come stavi ragionando? È come cercare di entrare nella testa di quello che stava facendo, non ho capito cosa fai, non ho capito perché.Esatto, esatto.Ma poi nel grande è perché hai fatto questa cosa, poi nel piccolo si rivela anche in cosa fa sta cosa.Come la fa.E quindi dove dovevo metterci le mani.Quindi sono sfondato un portone gigantesco con me fa proprio...però su quello è anche la mancanza di standard mi fa fare una scusa? e anche qui sfondi un portone non è solo la documentazione, la documentazione viene, serve però gli standard facilitano invece i sviluppatori sono tutti lasciati in maniera selvaggia un bottone che fa questo e lo fai come vuoi vuoi e chi arriva dopo lo fa in maniera completamente diversa e ogni bottone è diverso da quello precedente, sfido chiunque a scrivere documentazione.Sì, ma anche perché poi devi leggerla comunque, quindi poi diventa comunque un carico cognitivo, no? Non è la documentazione da sola non fa.No.Si diventa proprio.Adesso dirò una cosa che è abbastanza controversa, ma secondo me la documentazione deve essere il minimo possibile perché è un costo e c'è un...diciamo la peggior cosa che si può avere è una documentazione che è decoupled dal codice e descrive un qualcosa che non è più la realtà.Noi diciamo come azienda siamo un team molto grande e quel che facciamo è avere la necessità di avere un'approvazione anche da persone appartenenti ad altri team per fare in modo che sia chiaro che una certa feature sia autoesplicativa nel codice e quel minimo necessario di contesto sia presente sia nella PR e sia nel commento di Git perché poi alla fine è un casino riuscire a manutenere in sync la documentazione col codice quindi la nostra filosofia è farne il meno possibile e avere come responsabilità per i vari reviewer di dire "io sono co-responsabile del codice per cui ho premuto approve e merge".Cioè non è una responsabilità del singolo che scrive, è una responsabilità collettiva il codice che c'è.- Un commitment condiviso, ed è giusto, è giusto perché è una proprietà di tutti.Comunque è vero, cioè buona documentazione, non tanta documentazione.- Non serve scrivere...- Il minimo possibile, perché è un costo, è un costo estremo non serve non serve scrivere delle epopee di omeriche per documentare una funzione, a volte basta la mente hai detto bene un commento fatto bene nella major quest, puller quest, chiamala come vuoi un commento di commit neanche tutti la storia di commit, magari nel tuo salvare le cose hai avuto 100.000 commit, questo mi ha fatto pensare a Codemotion una volta ero con te Mauro, forse qualcuno, che eravamo insieme a te mi parlava dicevo quando hai una storia di commit su un'unica major quest di 100 commit hai perso il concetto del commit squascia e via.Squascia scrivi bene quello che stai facendo.Il commento a funzione non serve a metterci 40 righe di codice però mi dici questa funzione ha questi parametri di questo tipo.Ma quelli li leggi dal codice però.No, ma guarda.No, l'intenzione è nascosta.L'intenzione devi livellare.Perché nella documentazione della funzione poi ci puoi tirare fuori la documentazione anche in modo automatico e già ti salvi una buona parte del lavoro di automotivazione.Ah, ok, ok, PHP 5.0.Della reference.Ricordati, Isac.Cioè, quella reference lo fai, anche in Python lo fai sto coso qua.Anche scrivere il numero di una issue nel CodeCommit vuol dire che puoi andare a vedere che cosa avevano chiesto e quindi interpreti quello che vedi in funzione della necessità di business.Noi lo facciamo sempre per dire.Allora qua, vabbè poi andiamo in chiusura, così facciamo un wrap up.Volevo ancora dire che la documentazione deve spiegare, diciamo, il goal e non il come, perché il codice deve essere autosplicativo.Voglio mettere enfasi sul fatto che noi abbiamo diversi team che randomicamente vengono scelti come reviewer e nell'app pull request c'è la lista di chi ha provato e quindi se qualcuno ha mergelato del codice che nessuno capisce diciamo le persone di cui fare blame non è una ma sono n e obblighiamo ad avere questa diversity proprio per fare in modo che tu quando stai facendo review magari impari qualche approccio che magari diciamo non hai comune perché fa parte del silo scognitivo del team in cui lavori e allo stesso tempo se fai una cosa che è strana da una persona esterna ti si chiedono "ma com'è che fai questa cosa?" quindi, come dire, c'è anche una questione di uniformazione sul come si scrive il codice e l'evitare di scrivere quelle cose che per te sono banali e quando qualcun altro se le ritrova a leggere dice "wow, questo è veramente strano".Posso dire una cosa? - Poi chiudiamo.- Hai ragione, ti do ragione al 100%, però io non voglio, non vorrei almeno, quello che sto cercando di fare negli ultimi anni, non vorrei essere un po' troppo discepolo di Uncle Bob, nel senso che va bene tutto quello che ha detto e guarda, credimi, lo sottoscriverei con il sangue.Ci sono delle condizioni, e per quello voglio far fare Bubble l'Apple dipende.Ci sono delle condizioni, per esempio, mi è capitato di lavorare in contesti dove la performance era il driver principale, dove scrivere codice autoesplicativo talvolta non è possibile.Perché? Perché devi seguire alcune ergonomie particolari del linguaggio, del sistema che stai utilizzando.Per cui sì, hai ragione, in molti casi si può applicare in altri casi no e poi mi voglio ricollegare rapidamente giuro rapidamente al concetto della documentazione e di quello che mi hai detto tu quando ero manager io non sempre ho fatto a fare la documentazione ma quando non la facevo fare io facevo un risk assessment dove spiegavo e dicevo ho preso questa scelta trasferito in lato ingegneristico sarebbe un edr quindi scrivevo un decision record dove spiegavo che ho preso questa decisione perché in questo contesto ci sono queste variabili, io sono anche un manager, in quel caso ero il CTO e anche il CEO della società, sono anche un manager, devo raggiungere questo obiettivo, mi duele perché da ingegneri mi verrebbe da dire test driven development, ma no, non posso farlo, questa è la situazione attuale.Rivediamola poi.la vita è fatta di compromessi, figura di un'industria.Andremo proprio in chiusura e peraltro, tra l'altro, visto che parliamo di open source e siamo al FOSDEM, proprio la responsabilità condivisa, no, direi, ci portiamo a casa questo, non è l'IT open source, nei progetti open source, la responsabilità condivisa, se no non c'è un povero Cristo in Nebraska che deve mantenere da solo tutto uno stack.Il famoso Cristo in Nebraska.- No, o l'info, no, o l'inchiera.- XKCD.Condividiamo, esatto, condividiamo anche una responsabilità e aiutiamoci, ed è per questo che tante persone sono qua, ma anche per aiutarci a portare avanti insieme stavolta, perché sennò, povere, ti lasciamo da solo il titolo di XKCD a tenere in piedi la baracca.Quindi, insomma, responsabilità condivisa, anche mi porterai a casa questo hashtag che metterei nella puntata di oggi.Io volevo tornare a casa più leggero, invece mi tocca caricare questa responsabilità che cazzo.Nel viaggio di ritorno che comunque sarà lungo e faticoso e impervio, in quante ore devi tornare? No, queste volte sono 4 ore e mezza più un'oretta per arrivare a casa.Tutto sommato, ma durante questo tempo pensa agli alti concetti che abbiamo espresso durante questo simposio.Ok, perfetto.Io ho finito le parole.io ho finito le parole intanto le cazzate stanno prendendo la finestra stanno prendendo la finestra non ci permetterà più di fare queste cose l'anno prossimo sarà anche colpa tua ricordatelo in chiusura io volevo ringraziare tutti voi perché in questo specie di meetup qualcuno ha detto che ricordavano altri tipi di meetup in altri tempi però boh non lo so io non ho parole Vi voglio ringraziare perché avere, e l'ho già detto l'anno scorso, ma vedervi faccia a faccia e discutere con voi fuori dal meccanismo del podcast, parlando di cose che hanno per me, per Edo e per tutti credo, un'importanza che va oltre quello che facciamo tutti i giorni per lavoro.È un onore.Quindi vi voglio davvero ringraziare di cuore per questo.Grazie.Io ringrazio anche te che mi hai coinvolto in questa avventura.Piccola nota tecnica, in realtà questo episodio, come lo pubblicheremo? Credo che pubblicheremo, faremo un mix.Credo che faremo un mix, no? Cioè che una parte...Le parli singole.Eh? Le parli le dispari.Il canale destro! L'idea...Allora, intanto...Devi metterli su insieme perché li senti uno di colore di ratto.L'idea potrebbe essere quella, ma poi vediamo se sarà tecnicamente fattibile, di caricare un pezzo di un episodio da una parte su un canale e un pezzo dell'episodio su un altro canale in modo da proprio umergiare le community.Potrebbe essere un'idea.- Eh? - Oppure tipo primo maggio visto che...- Esattamente, non in ordine cronologico ovviamente, poi dovrai essere tu a ricostruire.- Per questo io voglio ringraziare Carmine perché l'idea era la sua.- Grazie Carmine.- Grazie Carmine.- Solo se riusciremo a farla bene, se non riusciremo a farla bene...- E col cazzo! - ...Carmine ti darà il cazzo! - E ti porti a casa questa responsabilità che tutta tua e col cazzo che condiviso ok? A meno che tu non abbia suonato questo commerciale, neppure in caso vorremmo partecipare ai proventi.Quindi grazie a Gitbar, grazie a Continuous Delivery e noi ci vediamo al prossimo episodio di Continuous Integration.Ciao! [Applauso] [Musica] [Musica] declaro vostro nome
