Bene e benvenuti su Gitbar.Ormai le vacanze sono un vicino ricordo, ma ormai un ricordo, e noi ritorniamo alla nostra consueta routine.Quindi il giovedì c'è sempre l'appuntamento per la nostra chiacchierata davanti a una birra e oggi davanti a una birra abbiamo un ospite speciali io lo so che Andrea non ha preparato l'introduzione infatti ho visto i suoi mega occhi giganti nel frattempo Luca e Leonardo ridono ma tu lo sai come come nostro solito chi ci porta un amico deve presentarlo quindi lascio la parola a te Andrea.Benvenuti su Gitbar il podcast dedicato al mondo dei full stack developer i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo Bene bene ciao a tutti, cosa dire l'ospite di oggi è un grandissimo amico conosciuto molti molti anni fa tramite il Pug Roma in tantissime conferenze nazionali e spazi per l'Italia, incontrato, sempre un piacere fermarsi con lui a parlare, prendere una birra e a dire cagate insieme.Appena conosciuto del pogrom è partito immediatamente per andare verso gli Emirati Arabi seguendo altri amici come ad esempio Nadaline o Davidino, poi sembrava che volesse tornare ma invece se ne è riscappato a nord Europa e ad oggi si trova in Dazon e quindi vi presento Cirpo, a.k.a.Alessandro Cinelli.Ciao a tutti, per me è una scoperta sapere che siamo amici, è una figata, no scherzo, grazie a questa presentazione comunque ci vengono a dire che non sono scappato da nessuna parte, ma con internet non puoi scappare da nessuna parte alla fine, quindi è sempre un piacere comunque cercare di partecipare e di sentirci anche col pubblico nazionale.Certo, certo.Grazie ancora dell'invito.Dovendo riassumere il tuo percorso professionale in poche parole, come ce lo racconteresti? Poche parole? Facendo...ok, ho iniziato...facevo economia e poi un giorno ho scoperto Linux nel 99-2000 grazie a un amico smanettone, ho iniziato a smanettare con Linux e ho successo a trovare un primo lavoro come sistemista, ma ai tempi, cioè fare sistemista in una volta e forza, con il sysadmin ai tempi era configurare la rete di una piccola azienda apposta, queste cose qua, quindi chiaramente le opportunità, non c'erano, non c'erano le opportunità dal punto di vista sistemistico eccetera, quindi ho approcciato di più la parte di programmazione, già come sistemista smanettavo un po' con PHP e da lì praticamente ho abbracciato appieno il linguaggio e di conseguenza anche le community eccetera, dove ho incontrato anche Andrea, tra l'altro del PHP User Group di Roma e da lì poi alla fine mi sono sposato un po' più verso JavaScript, anche quando mi ha detto Andrea, prima sono stato in a Dubai facendo un sacco di PHP, ma quando ero a Dubai in realtà abbiamo spostato tutti i nostri monolite su un po' di microservizi, più o meno microservizi con OJS e da lì ho sempre avuto più ruolo di leadership e gestione di supporto alle persone, dipartimenti o team.Alla fine sì, a livello tecnologico sono sempre intorno a JavaScript, Go e queste cose qua.Il mio percorso? Sì, sono stato come sviluppatore, poi alla fine c'è la parte più sociale che mi piace molto, quindi quasi in maniera, non dico naturale, però quasi alla fine mi sono speso più sul supportare persone individui e team, quindi ricoprendo ruoli da lead o head of engineering e in questo momento sono ad adasone e gestisco appunto la supporto la parte di developer experience con un team distribuito tra spagna regno unito e olanda.Io ti seguo da un po di tempo devo dire e ti seguo anche quando ti seguivo anche quando eri in Namshin negli Emirati.La cosa che mi aveva colpito all'epoca era il vostro blog tecnico dove documentavate in modo preciso tante cose ed era veramente figo per una persona che voleva avere dei punti di riferimento su PHP e non solo perché su quel blog avete documentato parte della transazione verso Node.js ricordo.A livello di Tim, che ruolo ha avuto quel blog in quell'esperienza particolare? Guarda, innanzitutto, appunto, come ha detto prima Andrea, c'è stata un'altra persona, che per me tra l'altro è stata tuttora fondamentale nel mio percorso di crescita, che è Alessandro Nadalini, che era appunto il, penso, alla fine era il DPO di Tecnologie di Anamshi.E abbiamo portato un po' quello spirito che avevamo col Pugro, cioè con lo spirito di condivisione e quant'altro, perché secondo noi nella parte del processo di crescita di uno sviluppatore in generale, è fondamentale la parte di condivisione, che può essere scritta, può essere verbale, però questa è fondamentale.E soprattutto, se vogliamo vedere in maniera meno romantica, perché dobbiamo anche vedere quell'aspetto, è anche un modo di esporsi, un modo per cercare di trovare anche altre persone che comunque condividano appieno il tuo modo di lavorare, il tuo modo di interagire.Secondo me questo è stato un elemento fondamentale.C'è da dire che però a NAMSCI siamo sempre rimasti piccoli nel senso a livello di team di sviluppo.Siamo partiti bene, eravamo una decina, ma al massimo penso siamo arrivati a una ventina, non di più.Quindi era proprio lo spirito di gruppo, far capire anche le persone, anche gli altri del team, che comunque oltre al lavoro hanno comunque spesso una specie di passione e secondo me è stato fondamentale a livello culturale.Perdonatemi il mio italiano, lo so fa schifo, ma non sono più abituato a fare discorsi lunghi in italiano, quindi se ci entra qualche inglesismo, non sono di Milano, però purtroppo mi riesce più facile.Di Brescia! Di Brescia, Pota, esatto.Non ti perdo.Quindi quel blog lo conservo ancora, mi sa che c'è un repository da qualche parte, è stato molto formativo per me, per te e per tutti gli altri.Ma non solo, c'era anche la parte open source, abbiamo lasciato un un sacco di nuovo open source che al momento penso sia anche obsoleta.Però è stato un mezzo più che altro interno per poter per crescere il team e le persone.Assolutamente interessante.È un po' lo stesso spirito col quale noi alla fine facciamo il nostro podcast, che è quel dare che in qualche modo comunque ti ritorna.Vuoi perché sedimenti meglio alcuni argomenti, voi perché costruisci delle relazioni, il ritorno è su un pacco di...oppure per restituire, cioè ragazzi, io immagino che anche voi qua lavorate tutti con tecnologie open source, giusto? Cioè in qualche modo anche se io magari non sono un nome italiano a caso, Matteo Collina che rilascia librerie come se non ci fosse un domani e quindi ha un impatto magari più visibile, più preponderante su tutta la comunità Node, per esempio, mondiale.Comunque, chiunque di noi può fare la sua piccola parte, giusto? Quindi alla fine, anche secondo me, il concetto di give back, di andare indietro, è fondamentale.Se tutti siamo in questa chat, probabilmente abbiamo avuto i nostri mentori, abbiamo avuto i nostri gruppi, i nostri meetup e le altre persone che ci hanno fatto crescere.Stessa cosa vale per me.Nel tuo percorso professionale sei passato dall'essere sviluppatore a rivestire delle cariche di leadership.Quali sono gli snodi di questa metamorfosi, se metamorfosi si può chiamare? Riesci ad identificare quei passaggi professionali, quelle prese di consapevolezza che poi ti hanno detto "ok, il mio ruolo non è più quello di scrivere solamente del codice, ma di occuparmi anche di altro".Sì, è stata una lenta...come si può dire...in realtà secondo me sono arrivato un po' tardi a riconoscere che a me stesso probabilmente dovrei spingere più su questo lato, sul lato magari appunto di leadership, sul lato manageriale, sul lato di servant leadership.E' una cosa che ripeto spesso, nel senso che penso che in Italia, parlo dell'Italia perché chiaramente sono rimasto in Italia fino al 2012, non so esattamente come siano state le altre realtà, le altre community, gli sviluppatori nel resto del mondo, ma nella mia esperienza dal 2008-2009, quando ho cominciato a partecipare, andare a conferenze e poi anche organizzarle o anche meetup.C'è stato un lavoro incredibile da parte di tanti sulla presa di coscienza di chi è lo sviluppatore, cos'è lo sviluppatore, del potere che abbiamo e tutte queste cose.E in quanto siamo fighi in un certo senso, in quanto anche fighi nel senso che alla fine quello che facciamo tutti i giorni ha un impatto incredibile.Chiunque di noi probabilmente in questa chat, in questa conversazione, se si licenzia oggi, domani mattina ha sicuramente un altro lavoro, magari non il migliore, però sicuramente.Quindi siamo anche un po' privilegiati da questo punto di vista.E quindi c'è stata molta enfasi sulla figura dello sviluppatore e secondo me a volte abbiamo un po' esagerato, nel senso che quasi come se lo sviluppatore fosse l'eroe di turno e tutto il resto attorno in realtà non serva tantissimo.Quindi secondo me io ho sempre capito che mi mi è sempre piaciuto interagire con le persone.Banalmente anche organizzare conferenze, meetup, tutte queste serie di attività che comportano uno sforzo.Le facevo sempre mega volentieri, non ossessione, però sai quando sei talmente preso e talmente contento di quello che stai facendo che anche se sei stanco comunque hai l'adrenalina e vai avanti.Così, questa è la mia esperienza, ma come penso di tantissime altre persone.Quindi questo aspetto sociale, questo aspetto di lavorare per gli altri, per gli individui, c'è sempre un po' stato.Quando ho cominciato a avere i primi ruoli di leadership, soprattutto a livello di gestione di team, di supporto di team, mi sono accorto che mi piaceva e come lavoro mi riusciva anche abbastanza bene.E quindi alla fine lì ho capito che forse non sono più i tempi di quando avevo vent'anni in cui ricompilavo 450 volte al giorno il kernel e stavo in piedi fino alle 5 di mattina, che mi danno certe emozioni.Le emozioni, le soddisfazioni le prendo da altre parti adesso.E quindi da lì c'è stata una presa di coscienza.Quando vedi che il collettivo, il gruppo, il team che l'ha sviluppato riesce aggiungere certi obiettivi ed è quello che ti dà la carica per poter dire "che figata, andiamo avanti, cosa facciamo dopo?".Lì mi ha fatto capire che sì, per me scrivere codici è ancora importante ed emozionante.Infatti, anche se sono manager in questo momento, comunque cerco sempre di scrivere qualcosa, di potermi aprire una pull request almeno due alla settimana.Però però il mio focus è un altro al momento e mi dà comunque gioia e penso di portare comunque valore.Sì, assolutamente sì.Credo che in qualche modo...Scusa, non mi sono mai svegliato la mattina e ho detto "cazzo, dovrei fare l'engineering manager".E chiaramente è stata una cosa più...E dopo il contrario, magari mi sono svegliato un giorno e ho detto "ma sai che forse dovrei investire più su quel aspetto piuttosto che l'altro, perché comunque alla fine mi piace, che serva e ha comunque valore, anche se non scrivo più milioni di righe di codice o faccio presentazioni esclusivamente sulla parte tecnica o architetturale.Rispetto a quello che stavi dicendo, ti volevo chiedere una curiosità, perché è una domanda che mi sto ponendo costantemente.Pensi che l'immagine dello sviluppatore, da immaginario collettivo, quindi nerdi, un po' borderline, un po' edgy come figura.Esiste ancora e soprattutto ha avuto un impatto in quella che poi è una figura professionale che cerca in qualche modo di spogliarsi di questo tipo di rappresentazione? Secondo me c'è ancora, ma sta cambiando, nel senso che c'è un po' più di presa di coscienza sull'aspetto dei supporto agli individui e ai team.Non ancora abbastanza, mi piacerebbe che lo stesso bordello che si faceva dieci anni fa a livello di conferenze, a livello di meetup, a livello di blog, a livello di qualsiasi materiale, a punto di vista tecnico, sul ruolo dello sviluppatore, ci fosse oggi sulla parte della leadership e la parte del manager.Sta cambiando secondo me, però se tu vai a pensare tipo a Elon Larry Page, Bill Gates, sono ancora i nostri idoli, l'inus Torvalds, gente che comunque stava nel proprio garage a scrivere toni di codice, alla fine sono diventati mega milionari se ne è successo.Ma anche se vai a vedere gli idoli di oggi, io penso, non so, pensiamo tipo degli sviluppatori, come Dan Abrahov, tutta gente che comunque ancora viene messa sul piedistallo e ha ben ragione, ma dietro? Cioè sicuramente ci sono altre persone che comunque supportano, fanno in modo che queste persone emergano e spesso queste persone non si conoscono e la gente non pensa neanche che esistano.Comunque in questo in questo breve inciso che hai fatto abbiamo fatto fare uno sforzo di immaginazione esagerato, cioè mi hai fatto immaginare Linus Torvald, Engineering Manager e credo che c'è una contraddizione in termini così grande.Ma per esempio, non so, quanti di voi sono familiar, quanti di voi conoscono il concetto degli OKR, Object Key Results.Avete sentito ancora la parola OKR, no? Sentito dire, ma...KPI...vabbè, sono tutti questi...KPI, sì.KPI e OKR sono leggermente diverse da...gli OKR sono leggermente diversi da KPI, ma il concetto è lo stesso, avere dei modi per misurare e fare in modo di portare avanti i progetti con organizzazione e quant'altro, o qualsiasi cosa.sono diventati famosi in tempi perché sono state le prime cose che Google e Larry Page, che si chiama Sergio Embry, hanno utilizzato quasi sin dall'inizio a Google.Quindi era per rinforzare il discorso che non è solo persone geniane, non è che da soli hanno messo in piedi tutto questo impero.Ci sono altre figure dietro, ma sconsiglierei per esempio Elon Musk come capo del sordo umano o manager o quantità.Sì, il loro ruolo credo che sia diverso, sia quello di catturare l'attenzione e mettere un...sono l'elemento personaggio che crea la storia, la storia in cui quando ci si approccia un marchio che può essere anche il kernel di Linux della situazione però si deve credere perché ormai tutto funziona così.Probabilmente anche un concetto di attitudine nel senso che l'attitudine che si trova su se stessi o anche un mentor che ti dice guarda secondo me tu hai questa attitudine ti fa andare verso la direzione della leadership o verso la direzione di continuare al coding, allo speaker, al presentatore e a stare sempre in prima linea sul piedistallo della cosa Y o Z.E tra l'altro vorrei aggiungere che stiamo facendo dei danni enormi, abbiamo fatto anche dei danni enormi e continuiamo a farli, perché spesso la parte di sviluppo del codice, di coding, diciamo, e la parte di manageriale, gestione delle persone, soprattutto, sono due cose completamente diverse e ancora oggi hai un single developer che è bravissima e cosa fai? La promuovi a lead.No, non è automatica la faccenda perché sono due lavori diversi.Probabilmente lei potrebbe essere, lei o lui, potrebbe diventare un buon lead, ma non è automatico il passaggio.ricominci da junior.Oppure hai già delle caratteristiche che hanno fatto già emergere certe tue caratteristiche che dicono ok bravissimo sviluppatore secondo noi hai anche dato delle delle dimostrate comunque di avere delle delle delle delle delle delle sì delle delle parti di leadership, ok, però non è automatico.Uno può rimanere senior engineer a vita che va benissimo, non c'è nessun problema, non c'è una rincorsa alla promozione alla scalata.Ecco, dovremmo adeguare anche gli stipendi, secondo me, ma questa è un'altra problematica.Però occhio a promuovere gente a ruoli di leadership quando… A parte l'attitudine penso sia anche importante la formazione, perché molte cose se non le hai nate le puoi comunque apprendere e imparare, soprattutto come gestire un team o in generale insomma fare quel passaggio da programmatore a tech lead.Però per me è molto più naturale, in un certo senso sicuramente puoi migliorare, l'empatia può essere diciamo "improved", migliorata.Soprattutto dal punto di vista dei soft skills, secondo me alcune cose non le puoi imparare da zero, sostanzialmente.Devono esserci comunque dei segnali, devono esserci comunque delle… devi essere portato, secondo me, per poter… Se sei portato ti è sicuramente più facile e poi… Anche perché… …poi comunque è la persona che fa la differenza.anche perché lavorare con le persone non è come lavorare con un compilatore che non ti fa compilare il pezzo di codice, cioè gli effetti, le sfumature rischiano di essere molte di più e fuori dal tuo controllo, no? Se ci pensi tu dici ok stai scrivendo del codice, vuoi provare una cosa? Va beh sti gazzi, provi, fai girare i test, mandi su CI, CI ti dice è bella lì, a posto, CI ti dice non va bene, se tu devi comunicare con una persona non è che dici "ah cazzo ho usato l'approccio sbagliato, rifacciamo" no, è "it's done, it's done" cioè nel senso, questa è una cosa molto, cioè purtroppo alcuni elementi che, alcune cose che usi durante lo sviluppo, il TDD non lo puoi fare con le persone purtroppo.Con brute force attack ci provi finché non fa quello che dici o non succede quello che vuoi e poi hai una denuncia per mobbing soprattutto.Andare a costruire la relazione con gli sviluppatori e la vita dello sviluppatore all'interno poi del team ci costringe ci porta nel nostro percorso a parlare di dev experience no perché uno dei compiti fondamentalmente di un lead è riuscire in qualche modo a percepire, sentire, accogliere le esigenze degli sviluppatori per lavorare in un ambiente non solo umano ma anche tecnicamente a misura l'uomo.Io ricordo una frase che mi disse un vecchio impresario edile e lui mi disse "vuoi sapere la qualità del lavoro che ti fa la tua impresa edile? Guarda che strumenti usa e come li ripone.E un po' questo vuol dire vuoi capire come lavora il tuo preciso team? Guarda un po' il contesto in un'ottica di dev experience come si trova a lavorare perché la sensazione nel quale si trova il contesto in cui si trova a lavorare in qualche modo si riflette nella codebase dico giusto Cirpo? sì sì la developer experience secondo me è una parte fondamentale oggi giorno nel senso che nel senso che alla fine abbiamo una pletora di strumenti e c'è sempre la richiesta di spingere spingere focalizzarsi sul pattore di monofocalizzazione, su come portare valore al cliente finale eccetera e la developer experience è come tu l'esempio dei curatori del fatto che comunque qualsiasi strumento sia in avanga che arrugginita la puoi usare però chiaramente non riuscirai probabilmente mai a realizzare qualcosa di qualità nelle stesse tempistiche.La developer experience sostanzialmente è questa, cioè fare in modo che un team o l'individuo, lo sviluppatore abbia gli strumenti necessari per potersi focalizzare il più possibile, in maniera più efficiente possibile, a portare valore al cliente finale senza perdersi troppo in tutto quello che sta a contorno, che ne so, invece usa la vanga a scavare con le mani per esempio, in questo senso.Sì, io ho una domanda che ci arriva da Carmine che non è potuto essere qua perché ha avuto un piccolo problema da risolvere però ci ha tenuto a lasciarci una domanda da farti e la domanda è quando si parla di Dev Experience quanto c'è di tecnico e quanto no e soprattutto questo contesto e su quali effetti incide sulla mental health, sulla salute mentale e psicologica del lavoratore? Se vuoi ti rispondo a questa domanda prenderla un po' alla larga se vi va bene, nel senso che vi posso raccontare un po' com'è il team di DX, Developer Experience di Dazon, per così riesco a farvi capire esattamente qual è la mia idea di Developer Experience cosa vuol dire essere un sviluppatore e una developer exclusive.Va bene? Perfetto, spara! Ok, allora, il team di VX ad Azon siamo in 12 al momento distribuiti tra Lamser, Madrid e Londra.E siamo partiti in round pick, dovevamo in 3 o 4, per validare un po' l'idea, capire un po', costruire il team.E qui c'è la parte fondamentale.Costruire un team non è banale, Ok, e qui ritorna anche il discorso dell'engineering manager.Tu puoi avere anche 8 Andrea, 8 Andrea nella stanza, gente fichissima, simpatica, esperta, ma non hai un team, hai 8 Andrea, hai 8 persone in una stanza.Cioè, tu hai la parte di creazione delle dinamiche, del lavoro di squadra, eccetera, che non è banale.E questo è il primo punto.Il secondo punto è che il team di The Exiters non fa un po' colo a tutti, no? Cioè, l'idea di dire "Caspita, ad andare a lavorare in un team in cui vado a creare tool per altri.Spesso dici "non ho prodotto di mezzo, non lavoro sul prodotto finale di Dazone, quindi non ho più il project manager, il PO, eccetera".È vero, ma c'è un problema.Se tu vieni a lavorare in DX, sei tu il PO, sei tu il PM.Perché c'è la parte del team di Developer Experience.Io come manager, diciamo, che supporto un po' il team e gli individui, ma ogni sviluppatore non scrive solo i codici.Chi più chi meno alla fine deve preoccuparsi di gestire piccoli progetti insieme agli altri, avere l'ownership anche di un progetto.Quindi pensare alla Rodma, pensare anche ai ticket.E una volta che comunque rilasci qualcosa, chi sono i nostri customer? Sono gli altri sviluppatori di The Zone.Quindi non è che c'è il CIRPO, io o c'è un'altra persona che va e fa l'annuncio del prodotto, colleziona feedback, va a parlare, fa i testi, fa la testing, no, lo fa ogni singolo sviluppatore in DX.Quindi essere un DXer, almeno per quanto riguarda il mio team, tra di me non è per tutti, perché ci servono queste caratteristiche in cui alla fine devi essere aperto, devi essere comunque capaci di comunicare e voler comunicare, voler portare avanti un prodotto in un certo modo.Come già ho detto, però, la figura dello sviluppatore non è unica e questo è stato uno dei sbagli che ho fatto in passato.Non possiamo definire cos'è uno sviluppatore.Dipende, è un essere umano e come tutti gli esseri umani sono diverse sfaccettature.In questo caso, serve uno sviluppatore che abbia anche questo approccio, approccio al prodotto, approccio alle persone.Se uno non ha questo approccio, non è che c'è qualcosa di sbagliato.Assolutamente no, va benissimo.Non vuoi essere coinvolto nel prodotto, non vuoi concentrarti più sulle righe di codice, eccetera.Probabilmente ci sarà un team, un'azienda che ha posto per queste cose.In DX, dal mio punto di vista, non c'è, perché devi ricoprire anche altri ruoli.La maggior parte del tempo scriverai codici, sicuramente, architettura, tutto quello che vuoi, ma c'è molta parte di comunicazione, di pianificazione e quant'altro.Ha senso? Assolutamente sì.A molto senso e posso aggiungere una domandina a questo tuo concetto? Nel senso ovviamente la persona che lavora in un team così strutturato ha bisogno di delle caratteristiche molto particolari.Molto spesso ovviamente questi sviluppatori che affiniscono un team del genere vengono, che prima lavoravano su un prodotto.È capitato a uno di tuoi ragazzi nel momento in cui ha cominciato a lavorare nel tuo team ha palesato l'esigenza di dire "eh, però mi manca un po' il prodotto".Come hai gestito questa cosa? Mi manca il prodotto, mi manca il fatto che ci sia qualcun altro preposto, diciamo, o abbia la responsabilità di gestire determinate cose.Allora, Innanzitutto voglio comunque dire che non tutti nel mio team sono gente che è mega esaltata nel gestire backlog, eccetera.Assolutamente no.C'è gente che magari ha proprio voglia di gestire di più, gira, fare le roadmap, eccetera.Quindi, in un certo senso, cerchiamo di bilanciare.nel senso che ci sono magari persone che fanno di più alcuni aspetti dello sviluppo software, e altre meno.Però tutti a un certo punto comunque contribuiscono.Anche lì, si ritrova al discorso di prima, siamo tutti diversi, magari cerchiamo anche di fare emerge di più, di dare alle persone quello che...non riesco a parlare l'italiano...cerchiamo di comunque di fare… - non worry, don't worry - il discorso è che non è che anche tutte le persone del mio team non è tutto uguale, c'è chi ha più, magari c'è quello che gli piace più gestire il debito tecnico, c'è quello che gli piace più invece fare il vision, quindi quello che facciamo è cercare di distribuire un pochettino, però tutti più o meno fanno un pezzettino di qualcosa, e poi appunto dal punto di vista strategico cerchi di bilanciare in modo di ottenere il meglio da chiunque.E questo è più onere tuo, diciamo.Scusa? E' più onere tuo bilanciare.Sì, esatto, fare in modo che le cose siano bilanciate.In DX abbiamo questo concetto di rota, rotazione.Tu, sviluppatore ad azone, se vuoi puoi fare richiesta al tuo manager e entrare in contatto con noi e venire a lavorare con DX per un mese, due mesi, tre mesi.Perché questa cosa? Perché noi facciamo dei tool che spaziano, può essere qualcosa da command line, può essere frontend, può essere una dashboard, può essere in JavaScript, può essere in Go, però a volte capita visto che lavoriamo per altri sviluppatori che non abbiamo conoscenza del dominio super mega atturata.Quindi avere i nostri customer, gli altri sviluppatori che lavorano con noi, bomba! Quindi abbiamo questo In questo concetto di rotazione, di solito lo usiamo anche quando magari abbiamo disponibilità di assumere altra gente nel team, lo usiamo anche come, non per il periodo di prova, ma per entrambe le parti.Ed è capitato che ci sono stati due sviluppatori che, bellissima esperienza, però il fatto di dover gestire, che ne so, non avere un agile coach nel team, il fatto di non avere un PM, di non avere un PO, il fatto che il PO comunque possano cambiare sul progetto, è una cosa che loro non piaceva.e ci sta.Queste imperferenze, no? Cioè nel senso...sì, è stato fatto presente, però il discorso è che per come lavora il team, la nostra mission, la nostra vision, i nostri valori sono quelli.Cambiamo, evolviamo, però alcune cose difficilmente cambiano perché snaturerebbero la natura stessa del team, quindi è del tipo "grazie, arrivederci", senso in maniera cordiale gentile.Tra l'altro sembra quasi paradossale perché pensare di lavorare in un team di EDX dove i tuoi customer fondamentalmente sono i tuoi colleghi in questo caso, ti può mostrare, far finta di dire "Ehi, guarda, basta, finirai di lavorare con gli utenti, ormai inizierai a parlare con gente che parla la tua lingua e ti concentrerai solo sul tool, in realtà come ci stavi dicendo è un miraggio questo perché poi entri in un contesto dove invece il confronto e il rapporto umano è necessario perché devi gestire praticamente tutta la fase, tutte le fasi di realizzazione della feature.Ma non solo, c'è un feedback continuo anche.Tutti gli strumenti che facciamo hanno comunque, sai, la lebelina sulla destra, feedback e queste cose qua.E noi all'inizio di settimana leggiamo tutti i feedback.Abbiamo anche lasciato il supporto su di Excel, quelle più utilizzate.E spesso a volte va di essere frustrante, no? Quando magari c'è un problema hai 50 sviluppatori che ti bombardano.Ti deve piacere questa cosa, sostanzialmente.Io avevo una domanda.La mia domanda iniziale era se esiste un numero minimo, secondo te, di sviluppatori, diciamo, di dimensione dell'azienda per cui ha senso poi iniziare a mettere un un team di DX e se nel caso l'azienda fosse piccola, se è una cosa che un singolo sviluppatore può dire "guarda io mi occupo di fare DX" cioè se è una cosa che può portare avanti anche uno solo è un team chiaramente piccolo.La DX, è assolutamente figo dire DX, molto cool, ma è sempre esistita.Non so se è una frase che ho detto io, probabilmente no, però mi è piaciuto talmente come l'ha fatta mia e mi scuso se magari è stato qualcun altro a dirlo prima.Tutte le aziende hanno un developer experience, non tutte le aziende hanno un developer experience team.Sono due cose diverse.Alla fine il developer experience ce l'hai.Quando è che ha senso fare un team? Dipende molto dal contesto dell'azienda.Io non mi sono messo a parlare di come lavora Adazon, non voglio farvi la pippa, però in realtà il discorso è emerso perché ad Adazon siamo 500 in engineering, più o meno, stiamo crescendo, una settantina di team.Molto carino il discorso di ogni team, diciamo, è responsabile dei propri servizi, sono tantissimi gradi di libertà.Andiamo con il mantra, il motto "you build it, you own it", cioè l'architettura, la messa in produzione, il supporto, qualsiasi cosa.Quindi la figura del team di DX è nata perché ci siamo accorti che mancava un pochettino il collante per i vari team.L'ADX, ad as on, non è che noi imponiamo standard o diciamo come dovete lavorare, no.Noi creiamo tool, creiamo documentazione, creiamo guideline, creiamo tutto ciò che pensiamo possa migliorare la vita quotidiana dello sviluppatore.Come prendiamo decisioni? Raccogliamo feedback, guardiamo dati, controlliamo le chat, poi arriva magari delle richieste dirette.Per esempio noi siamo in 12, sembra un team enorme per una piccola e mezza azienda, sì, ma per un'azienda come DaZone non lo è.Non è che lavoriamo su tutti i tool, lavoriamo sui tool che pensiamo che abbiano un impatto maggiore sul numero maggiore di persone e team.Se il team Pippo vuole fare un proprio tool, lo possono fare.L'unica cosa che le chiediamo è "Team Pippo, ce lo fate sapere, perché magari noi, di EX, sappiamo che il team Pluto ha probabilmente le stesse necessità, quindi favoriamo lo scambio.Per rispondere alla tua domanda, Leonardo, come hai detto prima, la developer experience c'è in qualsiasi azienda.Se sei in un'azienda medio-piccola, puoi essere anche in un'azienda di 4 persone, 10, 20, e si nota che si perde tantissimo tempo a fare cose ripetitive.Che ne so, non lavoro più nel mondo delle web agency da anni, però supponiamo, torniamo indietro.Nelle web agency succedeva la classica cosa, i siti erano fatti più o meno con lo stampino, no? Più o meno, ok? Se alla fine tutte le volte ci impiego due giorni a rimettere sulla infra, a ricreare lo stampino, è un problema.La developer experience dovrebbe automatizzare questa cosa.Cosa fa la web agency? Deve tirar su un nuovo team di developer experience? No, fa un working group temporaneo, un team temporaneo, una persona, due persone che vogliono risolvere questa problematica.Un'altra cosa che è abbastanza comune, developer experience è anche l'onboarding degli sviluppatori.Anche se non è un team di developer experience, probabilmente ci sarà un team temporaneo che dice vogliamo risolvere l'onboarding, abbiamo assumo un buoto di gente e l'onboarding non funziona.Ok, perfetto.Gino, Paola, Jeanette, perfetto, volete risolverla? Mettetevi insieme e invece di lavorare sul backlog normale del vostro team, curate questa cosa.Perché magari sono anche le persone che hanno subito la bad experience inizialmente, che sono e dicono "non c'è resto, facciamolo noi".Quello è il top.Di Exa, Adasona, adesso sta lavorando proprio sull'onboarding per migliorarlo e nel mio team di ex le due persone, sono in quattro poi si gira chiaramente, però le tre persone, le quattro persone che lavorano più spesso al progetto, due di loro sono quelle che sono appena arrivate tre mesi fa, altri non vogliono lavorarci, ve li dico "aspetta sono arrivato da solo un buon anno e mezzo fa, dall'onboarding, ok sicuramente come manager non vado a investire e o a cercare di convincere troppo queste altre persone che lavoreranno anche loro perché comunque di far girare devono tutti contribuire però chiaramente magari dai ownership più alle persone che hanno questo fuoco dentro che vogliono risolvere questo problema.Sì tra l'altro proprio su questo volevo farti una domanda.Come nasce una feature DX in DAZN? Allora, chiaramente hai una sorta di gerarchia, no? Può arrivarti il business banalmente se il mio svp di platform viene da noi e dice "ragazzi c'è da fare questo tool" chiaramente in generale siamo molto data driven, cioè è veramente difficile che arriva la persone, tu le fatti questa cosa e non ci spieghi perché.Cioè nel senso, questa è un'altra delle cose che mi piace molto a DAZN o specialmente magari in platform dove lavoro.DX lavora nel reparto di platform con Cloud e Sarit e queste cose qua.È difficile che uno venga a chiedere "fai questo perché ce l'ha detto il capo", ok? Quindi è anche difficile spesso dire "no, non lo facciamo" nel senso che probabilmente è una esigenza.Spesso a volte magari reagiamo, ma che ne so.Due settimane fa abbiamo dovuto creare un tool perché ha da suonare il concetto di hypercare.Siamo tutti in supporto, però quando ci sono dei lanci particolari, che ne so, la serie A o un nuovo country, eccetera, su degli eventi particolari, siccome è tutto in real time, vuoi che le persone siano in hypercare, cioè nel senso guardino l'evento, perché così possono reagire in maniera più veloce.Non c'era uno strumento decente per gestire questa cosa, c'erano Excel, PowerPoint che giravano e hanno detto "ok, ragazzi, potete creare una cosa che renda più facile la gestione di questa, degli hypercare".Fatto.Nel senso, in due settimane abbiamo cambiato un po', cambiate la probabilità e si è messi a lavorare.E quindi questa è una richiesta che viene dall'alto, diciamo.A volte invece sono micro cose che vengono anche da noi o da altri sviluppatori.Da noi interno al team, per esempio, non so come sembra la vostra azienda, però si cica la comunicazione è importante, sono d'accordissimo.Ma puoi scrivere tutte le mail che vuoi, puoi mandare tutti i piccioni viaggatori, puoi fare tutti i blog post di Staterra, che ci sarà sempre qualcuno che non l'avrà letta quella comunicazione.Un'azienda come Dazon, soprattutto in cui è tutto abbastanza decentralizzato punto di visione dello sviluppo.Se il team ha un servizio X con una dipendenza Y e quella dipendenza deve essere deprecata, è responsabilità di quel team di deprecare quella dipendenza.Non è che arriva quelli di platform e te la tolgono.No.Quindi cosa succede? Che noi chiaramente di platform pianifichiamo a monte, comunicazioni, anche due o tre mesi di anticipo, come al solito, c'è sempre qualcuno che non legge.Che arriva il giorno dopo.Quindi cosa succede? Quando magari, che ne so, rilasci un servizio o magari già hai deprecato qualcosa, come sempre nelle chat di Platinum, nelle chat anche di DX, "oh ragazzi non funziona più questo, hai letto questo blog qua?" "Ah grazie".Poi la gente non legge neanche i thread, perché i thread comunque continuano.E quindi, se sei bombardato per una settimana con questa cosa, un giorno uno dei ragazzi, penso fosse Yogi, se non mi ricordo chi, ha detto "mi è venuta un'idea".Siccome la maggior parte degli errori ce li hai in CI, quando continui la integration, dice "facciamo che tutti gli errori possano in qualche modo essere editati".Quindi quando c'è un errore, ti appare un pop-up che dice "se è la prima volta che vedi quell'errore, tu sviluppatore puoi scrivere la soluzione".In modo che Andrea, che arriva il giorno dopo e ti guarda le vacanze e non sapeva di questa depressione, quando fa partire la sua build, dice l'errore, viene fuori il pop-up e ti dice "forse perché non hai cambiato questa cosa".Quindi hai questa roba qua che è un pop-up, è veramente semplice, con tre bottoni tipo "contribuisci" di quello che è stato il problema, cerca su Google, praticamente quindi prendi, copia l'errore e te lo fa su Google, una terza opzione che non mi ricordo.Sta a Cover Flow, c'è sempre sta a Cover Flow.Esatto, una roba del genere.Quindi anche questo deve avere experience, è una cosa piccola, ma l'impatto che ha avuto è incredibile perché non dico che non ci chiami più per il supporto, però si è abbassata tantissimo questa cosa qua e anche lì crea un circolo in cui ha un approccio molto open source.Il primo livello di supporto l'hai già segato.Esatto, ma il concetto anche per rispondere alla domanda che era Leonardo che mi ha fatto la domanda, è anche che chi decide cosa, chi decide su cosa lavorare.Spesso sono i customer stessi, gli altri sviluppatori.E a volte io rispondo anche, soprattutto quando il problema secondo me sono due pull request lontane, ok? Two pull request away.Guarda, questo è Ripple.Se vuoi aprire due pull request.E a volte capita così, cioè nel senso, spesso e volentieri, anche perché noi non possiamo gestire tutti i progetti, se no saremmo in maintenance mode dalla mattina alla sera.Abbiamo tipo una cosa come 70 repository in DX.Quindi c'è anche questo concetto di rendere la cosa molto open source, lavorare molto bene sulla documentazione, sul feedback, fare in modo che chiunque possa contribuire ai nostri progetti e questa è una delle chiavi della DX.Quindi chi sono i nostri stakeholders? Questa è la domanda.Tutti! Chi può contribuire alla roadmap? Tutti! Poi c'è sistema di votazione in priorità, cioè nel senso, sono stato dipingendo come il paradiso, abbiamo cazzi e mazzi anche noi, non è che tutti contribuiscono, non è che sono tutti simpatici, carini e coccolosi, però l'approccio sembra che stia funzionando.Certo, ti faccio una domanda magari banale o stupida, ma secondo me nelle piccole realtà questa questione torna.Team di DX sta sviluppando dei tool ad uso interno immagina no il tool del pop up nella build con l'errore c'è o hai trovato una tendenza a abbassare la qualità del codice proprio perché si tratta di un tool interno e soprattutto come evitare di cadere in questa tentazione? La prima domanda è perché devi evitare? È più importante un codice scritto a mena dito o un qualcosa che fa felice i tuoi customer? Dipende se devi mantenere proprio il codice.Certo, però noi come sviluppatori, mi includo e metto anche dentro me stesso, a volte siamo troppo attenti al codice, secondo me.Il codice che scrivi oggi probabilmente non è più in produzione fra un anno.Allora, io ho 41 anni, mi avevano venduto la programmazione di oggetti classica, Java, PHP, modularizzare l'utilizzo.Ah, l'ORM, che figata, posso cambiare, switchare database quando voglio.Io voglio ancora trovare una persona, o non una, perché una la trovi sempre, 100 persone da MySQL a un certo punto ha deciso, dopo un anno e mezzo, di passare a Postgre o viceversa.E l'hanno fatto cambiando solamente un modulo.Esatto.Lo so che è un po' provocatorio.Scrive il codice di qualità? Il lavoro deve essere di qualità.Il discorso è che a volte, secondo me, non viene preso il contesto, Mauro.Dipende anche da che prodotto vai a realizzare.Se è un prodotto di finance eccetera o qualcosa che comunque ha un impatto sulle vite delle persone, secondo me bisogna sicuramente stare mega mega attenti.Nelle questioni dei tooling interni in DX non c'è neanche tantissima pianificazione perché continuiamo a reagire, reagiamo continuamente ai cambiamenti.Per esempio, adesso stiamo scrivendo il podium boarding.Ci hanno chiesto la roadmap e abbiamo detto che la roadmap non esiste.Nel senso che c'è più o meno una roadmap, però è chiaro che non è dettagliata.Lo facciamo ogni sei settimane.Abbiamo questo ciclo che si chiama "Bet Model".Ogni sei settimane decidiamo su cosa lavorare.Perché abbiamo visto, soprattutto negli ultimi anni e mezzo, che non ha senso fare Steam per noi, non ha senso pianificare troppo in là.Ovviamente abbiamo i nostri OKR, i nostri obiettivi di quadrimestre, quarter, ma non avrebbe senso andare a fare una predicazione così super certosina perché spesso dobbiamo reagire ai cambiamenti esterni.Abbiamo il nostro ineguida, sappiamo dove vogliamo andare, siamo nelle tematiche principali sulle quali vogliamo investire, abbiamo i nostri OKR, però siamo molto leggeri da questo punto di vista.Quindi tornando al discorso del codice, noi con i tool interni, la maggior parte dei tool interni, possiamo anche permetterci di rompere le cose.Quindi la prospettiva cambia.Chiaramente abbiamo la Dazon CLI, abbiamo anche le pipeline di front-end, abbiamo alcuni prodotti che quelli devi essere super mega careful, attento.Ci sono queste cose qua, ma tutti gli altri tool, tipo se il tool di onboarding, la interfaccia grafica c'è un pixel storto, la forma non funziona più per qualche senso il problema, va bene, cioè nel senso la mettiamo a posto subito.Quindi dipende anche cosa intendi per qualità.Io mi concentrerò più sul valore che sulla qualità.Sono due concetti che spesso vanno insieme ma possono essere anche disgiunti.Assolutamente sì, valore che poi in qualche modo devi anche raccontare in qualche modo al management poi per giustificare l'investimento in quella direzione.Secondo te, a livello...Scusi, vi interrompo, Dx facciamo partita in tre, perché tutti dicevano "figo, figo", però dicevano "che cazzo è?".Cioè Dx di due anni fa e Dx oggi sono due team diversi, ok? Perché comunque il business cercava di capire, ok? Chiaramente il business non era subito sold, come si dice venduto.Alla fine sono contento anche di non essere partito in dieci subito, sono contento di essere partito in tre o quattro per far vedere il valore e come lavoriamo e a un certo punto hanno detto "andate, andate bene, portate il valore, ci fidiamo, la trust c'è".Come si è riuscita a costruire quella consapevolezza nel management? Hai utilizzato dei messaggi particolari, delle KPI esplicite che mostravano la butola, la produttività aumentata o cose di questo tipo? Oppure non so.Sì, allora una delle scelte che avevo di svolta è stata che abbiamo ancora tuttora, anche se stiamo migrando a GitHub Action, usiamo Drone ancora tuttora, che è un sistema di CI, e molta gente non era contenta.Abbiamo fatto una survey interna, ma c'era la gente proprio incazzata, poi lo sapete anche voi, no? Quando siamo arrabbiati noi sviluppatori, cioè non ce n'è per nessuno.Alla fine abbiamo detto "Buona, andiamo in hackathon mode tre settimane" e abbiamo rifatto l'interfaccia e a un certo punto vedi che le lamentele sono scese.Abbiamo introdotto il concetto di feedback, abbiamo un servizio chiamato RMS, Rate My Service, in cui puoi dare feedback e votare, come se chiamavano, vai a cerchire ristoranti e cose del genere.più che le stelline.Stesso concetto.Il business ha visto che gli sviluppatori continuano a parlare e ad interagire con i Dx e sembra che siano anche felici.Queste sono state le chiavi che hanno, o anche banalmente il 2Daper che parlavo prima, cioè adesso vai in una pagina e tutte le informazioni che ti servono e già tra loro magia, non so più 20.000 Excel file, capito? Quindi è facile traviata e misurata in questo modo.Un'altra cosa, dovete fermarmi se no vado avanti a parlare all'infanto.Vai, sereno! Una cosa che abbiamo fatto per esempio l'anno scorso è ho, alla fine dell'anno, e adesso sto cercando di farlo in maniera più costante, ho cercato di tirare fuori i dati dalla chat di DxSupport.DxSupport è una chat su Teams, noi siamo Teams come Slack.E praticamente ho tirato fuori i maggiori contributor, ok, so parte la richiesta parte un thread chi è che risponde per primo chi è e a mia sorpresa nei primi dieci non ci sono tutti i dieci nei primi dieci al quarto al quinto posto sono due persone che non sono i dieci sono altre persone dell'azienda che ovviamente conoscono meglio alcuni aspetti che contribuiscono aiuta supportano tutte queste cose sono dati a supporto che poi andare al business dire "ciccio", nel senso che questo sta creando un sacco di engagement, questo sta risolvendo un sacco, sta togliendo un sacco di problematiche a livello di supporto, eccetera.E quindi, alla fine, l'altra cosa di cui noi abbiamo parlato è che la VX può avere un impatto culturale.Lavori sui tool, ma l'impatto è a livello culturale, perché i tool determinano anche la tua cultura aziendale, no? Cioè se tu fai dei tool in un certo modo, o fai in modo che chi usa i tool intrancisti in un certo modo, hai un impatto chiaramente anche sull'engineering culture sostanzialmente.E anche questo è stato abbastanza evidente.So che Andrea ha una domanda, però prima di passagli la palla mi piace evidenziare questa cosa.Una parte dei tool che ci hai raccontato rappresentano una particolare tecnica poi di management, comunicazione all'interno dell'azienda che è proprio la comunicazione push piuttosto che pull, nel senso che tu stai inviando le informazioni ai dev piuttosto che costringere il dev ad andarla a chiedere a tizio a Caio a Sempronio ed è particolare che in qualche modo ritorni la cosa.Si non funziona sempre così, la parte in cui vai a fare change, vai a fare pull, hai fatto questa cosa eccetera eccetera, c'è ancora.Penso che sia un problema problematica di qualsiasi gruppo di esseri umani.È minore e chiaramente questo, dal punto di vista dell'impatto, si vede anche perché comunque va risparmiando una serie di costi.Però sì, la direzione è quella.C'è tanto lavoro in DPR che non c'è solo il tool, no? Nel senso, tu puoi fare un tool e se nessuno sai che c'è quel tool lì? Nessuno te lo usa.La parte social, la parte di via raggio di marketing, chiamala come vuoi, c'è.Chiarissimo, chiarissimo.Io, Ciro, te volevo fare una domanda un po' più ampia.Prima ci parlavi ovviamente, realizzate diciamo piccoli prodotti interni, tool, ma parlavi anche di linee guida, quindi ipotizzo anche di buone pratiche.E quindi mi chiedevo, quanto è complicato a far comprendere ai colleghi di sviluppo sul prodotto, che lavorano sul prodotto, quanto è importante adottare queste pratiche, quanto è importante adottare queste linee guida per portare avanti lo sviluppo con quella tecnologia o quell'altra, e nel momento in cui bisogna fare opera di convincimento, fare in modo che queste cose non che vengono calate dall'alto ma diciamo fare in modo che insieme si riesce a capire, a far passare il valore di queste linee guida o buone pratiche che la DX espone.Si ci chiedono osmosi, passare le cose un po' per osmosi, c'è il senso, quando si dice "lead by example" vale anche in questo caso, nel senso io, mio team può rompere le scatole quanto vuole, ma se le persone non vogliono essere coinvolte, non ne vedono il beneficio, puoi fare tutte le presentazioni che vuoi.Quindi il discorso è dare il buon esempio, sostanzialmente.Cioè, per esempio, quello che abbiamo fatto noi è, noi abbiamo il nostro template per ogni repository di VX, ma non abbiamo mai detto a tutti "dovete usare questo template per fare i repository, perché tra l'altro io non posso avere l'arroganza di sapere quali sono le reali necessità di quello specifico team.Quindi è molto più far vedere agli altri.Secondo me l'impatto più importante che abbiamo avuto fino adesso è sugli altri team di platform.Se tu pensi CloudSRE, Gnolis, Manettoni, in effetti di di Exdick, noi che siamo il team degli emoji, che spesso sono i nerdoni.Ci sono un po' più ammorbiditi, hanno avuto un impatto anche a livello di comunicazione fra platform e il resto del prodotto.Per quanto riguarda gli altri dipartimenti, cerchiamo di fare un po' più lavoro magari sui principal così, nel senso cercare di parlare direttamente con loro in modo che influenzino il resto.Però a volte ostinarsi a cercare di fare cose perfette o far andare in certo modo non servono a nulla.Alla fine magari potete aspettare, dare il buon esempio e via.Quindi se non c'è adozione ciccia.Se non c'è adozione è un buon feedback, se non c'è adozione vuol dire che non si capisce nessuno.Magari l'idea migliore del mondo ma se non è...Non era il momento giusto.Non è il momento giusto però...Abbiamo già parlato per un po' e si inizia a sentire l'arsura, ma qua su Gitbar come ben voi potete sapere questo non è un problema, anche perché ogni settimana abbiamo degli ascoltatori che molto gentilmente ci offrono una birra da bere e quindi questo insomma aiuta a portare avanti l'episodio.Quindi, come nostra consuetudine, in questo momento li ringraziamo.Voglio iniziare ringraziando Sam Barza.Sam Barza che ci ha offerto ben 5 birre.Wow! Col messaggio "Grazie di tutte queste ore in vostra compagnia, non so perché ho aspettato così tanto".Grazie a te Sam per supportare il nostro podcast.A seguire poi c'è un'altra donazione di una birra fatta da Alberto.Alberto che ringraziamo tantissimo e quindi grazie alle donazioni di Alberto e di Sam alziamo i nostri bicchieri al cielo e ci facciamo una bevuta prima di continuare con l'episodio.Io ho una domanda, poi ragazzi naturalmente se avete qualche altra domanda sparate pure non deve evitare che faccia io tutte le domande, le mie domande sono mediamente stupide quindi No, la mia domanda è l'impatto della Dx in termini di dev retain, cioè di tenere degli sviluppatori nel team e in azienda.Scusami, puoi ripetere? Che impatto ha la DX nel cercare di tenere il più possibile gli sviluppatori in azienda? Al momento non so risponderti, è una cosa su cui stiamo cercando di lavorarci.Infatti non è ancora ufficiale, ci stiamo labbrando sopra, però probabilmente ci sarà un nuovo team.Come vi ho detto prima, Dx si occupa di tooling, però abbiamo visto che comunque c'è un impatto importante anche a livello della culture, eccetera.Quanto è venuta Pingasone, che penso in qualsiasi azienda, che puoi avere i reparti di HR, recruitment, bravissimi, gente eccezionale, gente anche che lavora in coms, cioè il reparto di coms, per esempio, da zone.Gente eccezionale, però noi ingegneri siamo una bestia completamente diversa.Cioè, nel senso, è un mondo a parte.Nel senso, che ne so, magari in qualsiasi azienda, magari chi al di fuori dal reparto di engineering fa un evento e gli ingegneri dicono "ma che cos'è sta cosa? Ma sì, ma noi facciamo le nostre conferenze, eccetera".Quindi, una delle cose di cui stiamo discutendo è di ex a un impatto a livello culturale però la missione più sui tui e molti dei miei ragazzi dicono sì bello la questione culture eccetera però non vogliamo focalizzarsi su questo quindi l'idea è che creche espanderemo la di exit a 360 gradi che non è solo tutti ma anche in genere culture quindi probabilmente sarà sto lavorando per vedere se avrò i fondi per avere un team che si chiama di ex engagement che il concetto è lo stesso c'è un punto di riferimento che sostanzialmente si occupi più di iniziative interne ed esterne dal punto di vista dell'ingegnere in calcio, come nonboarding e tutte queste cose.Sempre tecnico, però le persone di questo team sono persone che, tipo un'Andrea, no? Tipo voi, cioè persone che hanno già un piede nella community, sanno organizzare, parlano con gli sviluppatori e queste cose qua.Quindi al momento per rispondere alla tua domanda, Mauro, non saprei dell'impatto.Posso dirti che secondo me ha un impatto, ma non saprei quantificarlo.E poi c'è un altro problema.Comunque il mercato è talmente dinamico in generale.Tipo a Londra la vita made in uno sviluppatore in un'azienda è di 18 mesi, due anni e già...wow, cazzo, due anni! E perché ti pagano molto bene in azienda che ci stai due anni, se no...Esatto, quindi alla fine...poi adesso il mercato del lavoro sta cambiando di nuovo completamente, quindi è difficile.Quello che vorremmo fare è… LM: il concetto di onboarding è davvero fondamentale a questo punto.AC: esatto, l'onboarding è davvero fondamentale.La nostra domanda è che probabilmente ci concentreremo su questo aspetto e cominceremo anche a raccogliere dati.Cioè, nel senso, i dati che abbiamo sulla gente che magari va via ce li abbiamo, perché sono le exit interview, queste robe qua, però magari fare qualcosa di un po' più di mirato e avere più dati sul… Il fatto è che anche se domani dovreste eseguire X engagement o cominciare a raccogliere i dati, quindi ci sono dei cambiamenti su un veramente lungo periodo, non un mese con l'altro.Quindi al momento non saprei risponderti.Io penso che abbia veramente un impatto di un certo tipo, anche perché per esempio vorrei un team che possa occuparsi non solo nel tempo libero, come stanno facendo molti ragazzi, come faccio io, sulla parte open source da zona, diverse cose open source.Facciamo collaborazioni, per esempio, con tantissimi gruppi esterni, tipo Code First Girls, tutte queste cose fighissime.Però alla fine è un pochettino più su base volontaria al momento, quindi non c'è una gestione, una governance.Quando ci sarà una governance magari le cose miglioreranno anche, avrò più dati di supporto e potrò dire "sì, c'è stato un impatto", "no, non c'è stato nessun impatto".Carmine so che...Beh, dovrei giustificare la tua azione giustamente.No, ma credo che comunque un'influenza è innegabile, un'influenza di questo tipo di attività nel retain e anche nella PIL che poi l'azienda crea verso i developer e tra l'altro sta diventando e diventa sempre più più complesso fare il recruiting.Fatto bene! Si è una menata assurda! Allora, in realtà io avevo una domanda, mi sono imbucato dopo e ho fatto una domanda per rompere le scatole a tutti.Però secondo me era il momento giusto di farla.Stavi prima del fatto che Dx fa i tool e comunque aiuta gli sviluppatori nella loro vita di tutti i giorni, ma secondo te può rientrare tra i compiti del team di Dx per migliorare la developer experience quella sì di fornire tool, di fornire strumenti, eccetera, eccetera, ma anche di poter fornire delle linee guida e delle informazioni che non sono propriamente tecniche.Mi spiego peggio.Allora, immaginiamo che ci sia il team XYZ che sta lavorando su qualche cosa e magari ci sono queste persone giù che sono appena entrate e hanno fatto l'onboarding.Il fatto comunque che il team di X possa fornire sia gli strumenti, ma anche della documentazione, non so come posso dire, il bigname della roadmap e del prodotto per poterlo conoscere prima e avere una visione chiara di quelli che sono i prossimi sviluppi per quel prodotto, comunque per dare degli strumenti agli sviluppatori per avere una conoscenza sia tecnica ma non tecnica per poter anche sviluppare e magari avere delle nuove idee su quel prodotto anche sapendo ciò che non succede dal punto di vista tecnico.Allora la risposta breve mia è no.Nel senso non è compito da ADX o meglio non è compito di Exit ad Azone.E ribadisco che ad Azone, e io spero rimanga così, è l'unico motivo per cui sono ancora lavorato da tre anni ad Azone, è il fatto che c'è molta libertà e responsabilità nei team singoli.Se noi cominciassimo ad andare a dire "team, dovreste fare così, fate così, eccetera.Alla fine ogni team ha la propria identità.E poi, non so, l'ho detto anche prima, io non posso sapere esattamente come lavora un team, che cosa si va a focalizzare, eccetera.Quindi noi siamo a supporto.Sì, possiamo fare delle linee guida, ma se ho ben capito le linee guida di cui tu parlavi sono molto specifiche.Sì, era per assistere ogni singolo team in quello che fa.Ci sono anche altre ruole, ad esempio il principal engineer.Il principal engineer è una persona che è sostanzialmente molto esperta tecnicamente, che può lavorare cross team.Quindi dal punto di vista tecnico penso che sia la responsabilità del principal o dei principal portare avanti questa cosa.Poi c'è già il coach o il scrum master e penso che sia più compito di questo.Poi anche le figure di staff engineer, volendo, nei team, che è sempre tecnica ma con dei tratti di leadership e quant'altro.Se no, il team di Reacts dovrebbe essere 50 persone.Non so se riesco a rispondere alla tua domanda.ho capito, diciamo la seconda domanda quindi che ti faccio, ma mi sa che sono già risposta, quindi non c'è nessun filo diretto tra queste persone diciamo nelle figure di leadership o non tecniche e il team di Axel? No, lavoriamo costantemente con loro, perché noi potremmo ricevere, ne so, 20 richieste in un bot di lavorare a 20 cose diverse.La prima cosa che facciamo è che controlliamo i nostri dati, quello che abbiamo, le informazioni poi ci confrontiamo tantissimo con tutte le figure di leadership e dire "oh, ma che so, esempio banale" Dasone è suddivisa dal punto di vista engineering per customer experience, quindi ha engagement e mobile, che è un dipartimento mobile, engagement è tutta la parte di engaging e web, poi ha leading group su console e tv, Poi è Playback che è il playback.Poi è Growth che acquisisce la retention, per esempio.E, quello che è successo tre settimane fa, il VP di Growth ha detto "sarebbe bello se investissimo su scaffolding e templating per i servizi".Sì, è una cosa che Dx ne parla da due anni, non è mai partita come cosa.Alla fine si è parlato al VP level e gli altri VP hanno detto "sì, è una bellissima idea, ma nei nostri reparti non facciamo un micro service, un nuovo micro service ogni settimana, quindi in realtà oggi come oggi non abbiamo questa esigenza.Questa esigenza viene da Growth, che è già un reparto bello grosso, sono già i 100-120, quindi in questo caso è molto più una collaborazione, c'è tanta collaborazione tra DX e di altri, non è che "ah, abbiamo bisogno di questo prodotto, perfetto DX, queste sono le specifiche, ci vediamo fra due mesi", assolutamente no, è un continuo, una continua collaborazione.Quindi per rispondere un po' alla domanda Carmine, alla fine si influenziamo alcune cose ma è più una collaborazione più che un fai così, fai cosa.Ok è una contaminazione contigua.Esatto, questo è quello che mi ha affigato, a me pesantissime queste cose.C'è gente che magari, tranno al discorso anche all'inizio che aveva fatto Mauro, era che a gente non piace questa cosa, vogliono più certezze, vogliono più cose più più pianificate o il context switch, proprio non lo digerisco.Di ex il context switch non è quotidiano ovviamente perché non è sostenibile, però non facciamo sprint da due settimane, non avrebbe senso per noi.Ci costruirebbe troppo come overhead far sprint e pianificare uno sprint banalmente.Dobbiamo fare sprint da sei settimane perché sappiamo che in sei settimane vorremmo rilasciare alcune cose, sei settimane ci sembrano abbastanza buone, in quelle sei settimane riusciamo anche a invocare eventuali altre richieste e quant'altro.LM: Una domanda.Il team è ricordato, è formato da diverse persone, diverse teste, diversi programmatori che hanno background diversi e tutto.Succede, è successo o può succedere che non si ha un accordo sul come risolvere un determinato problema o una determinata esigenza.In quel caso, come ci si comporta? Si comporta come un qualsiasi altro team che lavora su un prodotto o c'è qualche differenza per lavorare su un prodotto? Allora, penso che il nostro team sia abbastanza diversificato, nel senso che non hai tutti leader, comunque hai dal junior al principal, passando da staff, passando da senior, passando da mid.La caratteristica è che tutti, anche dal junior, hanno l'ownership di qualcosa.Chiaramente il junior ha magari un learning circuit di qualcosa di un po' più semplice, almeno per me, per noi, per chi ha esperienza da gestire e chiaramente più vai in su.Quindi tu come responsabile del progetto sei responsabile sia a canto che della scelta tecnica, però è ovvio che poi vai più in su, nel senso che se sei junior e arriva il principal, o arrivo io che magari sono anche responsabile, sono l'ultimo responsabile del prodotto, dico "guarda, secondo me non va fatta così", posso avere l'ultima parola.La figata è che l'ultima parola in due anni e mezzo l'ho usata tre volte.Perché? Perché la chiave è "mi è capitata tre volte, devo intervenire".No, facciamo così.Boom.Che è stato un po' roll back adesso, non interessa.Tre volte in due anni e mezzo non è male, questo fa anche capire che c'è molta discussione.Settimana scorsa, per esempio, uno dei ragazzi aveva proposto di usare Aurora serverless.In quel meeting c'erano due principal, c'era uno staff engineer e c'ero io.C'è stata un po' delle discussioni, non tutti erano convinti su usare Aurora RDS serverless su AWS, perché non l'avevamo ancora fatto e sembrava un po'...Però alla fine la decisione è stata "ok andiamo".La settimana scorsa c'erano dei problemi, però non è che il team può essere lamentato "ah ecco io l'avevo detto".No, è stata una decisione di un team, ok.Vogliamo tornare indietro, nel senso che vogliamo riconsiderarla o cerchiamo di andare avanti e aiutandoci a vicenda? La seconda.Quindi in un certo senso è molto più una conversazione e di nuovo il discorso di Mauro, la qualità, il codice eccetera.Quando la booties più sul valore.È più facile anche dal mio punto di vista prendere decisioni.Quando hai un team in cui puoi tranquillamente in ambiente safe, come dici in italiano? Sicuro? Puoi fallire? Va bene.È sbagliato? Bella lì.Cosa hai imparato? Ho imparato questo.Perfetto, ottimo.Questa è anche una cosa secondo me una figata un po' della DX, quando non hai veramente il prodotto sul collo, no? Cioè, nel senso, abbiamo deadline, attenzione, che è il paradiso.Però, per esempio, dà la possibilità anche a gente di emergere.Per esempio, uno dei miei ragazzi non voleva di troppo più leader, ha spinto un po' troppo sull'acceleratore, secondo me, in questa fase iniziale del progetto, avendo un po' degli effetti non bellissimi sulle altre due del gruppo e noi abbiamo parlato, cioè nel senso e abbiamo detto la situazione era drammatica, l'avevo notato, però non volevo intervenire, volevo che le cose emergessero e oggi abbiamo fatto una chiacchierata e ci ha detto "Cirpo, non lo so, non sono sicuro di quello che ho fatto"."Guarda, bravissimo, secondo me avresti dovuto fare in un altro modo, però hai imparato?" "Sì, perfetto, buono, andata".Quindi è veramente importante le dinamiche, le dinamiche di team, perché se io dico o se il principal dice "no, questo non va bene" non la prendi sul personale, sul tuo eco.Ringrazio, è un feedback, è un gift.Conflitti, menate, ci sono, non è che tutto è splendido, però secondo me è veramente come imposti i letti.Non so se ti ho risposta a domanda, Luca? Sì sì, mi hai risposto molto bene.Se fa parte della normalità, comunque parte del lavoro, dire ok, sbagliare, oppure qualcun altro che dice no, prendo una decisione perché sta sopra di tali livelli di responsabilità.Cambiando invece, diciamo, tema o punto di vista della developer experience all'atto pratico.Immaginiamo che domani vieni da te un'altra big company, e si dice "senti Cirpo, visto che sei una bestia, da da solo stai facendo un letto, stai facendo benissimo, secondo me anche noi abbiamo bisogno di un team del genere, questa è la mission, ci piacerebbe questa nuova sfida, tu accetti, imbocchi, e quali sono le prime cose? Cioè, Mettiti nei panni, nei domani, che con la tua esperienza vorresti consigliare a qualcuno per cominciare a fare developer in maniera seria, all'interno della tua company, da dove iniziare? Dove andare a guardare? Quali sono le prime cose fondamentali per migliorarla dentro la mia company? Prendi due o tre junior, fai delle sessioni individuali con le persone.Perché individuali? perché se sono individuali si sentono molto...cioè se sono uno sono tre volte obbligati a parlare, a esprimersi e comunque si sentono comunque in un ambiente protetto.Parli, hai una serie di domande, nel senso, cosa è che adesso dovrebbe essere migliorato nel tuo quotidiano appunto di risultato sviluppatore e lo fai a una serie diversa di seniority sostanzialmente, cioè cerchi di raccogliere il più possibile lo spettro.È ovvio che se hai 500 ingegneri non puoi parlare 500 persone all'inizio di un anno.Quindi il problema è che vai a campione sostanzialmente.Campione puoi essere la seniority, puoi essere ruolo, puoi essere dipartimento, eccetera.E in base a quello raccogli.Poi magari fai delle sezioni un po' più collettive e quindi lì fai emergere quale sono le cose che andrebbero magari migliorate.E anche qui potresti magari mandare una survey, ma perché io consiglio di farlo faccia a faccia anche in video, perché devi sbloccare alcune cose.Facciamo anche noi i sondaggi, ma alla fine il trucco sta nel riuscire a capire, a fare che le persone si fidino di te, a creare questa fiducia.Una volta creata la fiducia, hai il problema contrario, rimbalzare un attimo.Però se non è quello puoi avere anche il miglior DX del mondo che alla fine se non crei un nuovo rapporto con le persone non sarà mai esattamente...perché anche il problema in un'azienda grossa o in una zona media, le problematiche, le sfide sono...il backlog di DX potenzialmente è infinito.Cioè noi abbiamo il problema di dire "ok, cazzo lavoriamo settimana prossima? Non te preoccupa".Il problema è "cosa non lavoriamo settimana prossima.Quindi in questo senso la prima cosa è capire esattamente cosa deve essere sotto e il consiglio che ho e mi rallaccio alla domanda che prende Leonardo, cioè in un senso iniziate, se volete iniziare a developer experience con un team, iniziate veramente come Baby Step, non create neanche il team di DX, create un team temporaneo e vedete come va.Ed è andata così.Io sono andato dalla zone che facevo parte del core team, il core team sostanzialmente era più che altro sulla parte di pipeline di front-end, e poi da lì è stato creato Dx, ma piano piano.Nel colloquio, la prima cosa che vorrei capire, prima di entrare a vuoto, è qual è la vision della di chi mi sta assumendo e perché pensano anche se non hanno dati.Una domanda ancora io.È mai successo? Secondo me a volte ci sono alcune cose che sono intrinsicamente difficili per natura per noi dev.specialmente magari quando si parla di performance o bisogna fare determinate cose in modo particolarmente difficile.Ma è successo in quel caso si abbassa l'arma della DX dopo averci sicuramente provato magari.Ma è successo che è una cosa che si sa che si deve migliorare e lì non ci si riesce e si dice "va bene, questa è intrinsecamente difficile".SB: sì, abbiamo fatto una cosa che secondo me, spero che risponda alla tua domanda, se non sto rispondendo interrogo di subito, se no parto nel mio pippone.C'è una cosa che abbiamo fatto che sono particolarmente orgoglione e sono veramente contentissimo che l'abbiamo fatta, però sono mega triste.Perché sono mega triste? Perché nessuno la sta usando.E quindi tu dici "ca**o, questa cosa è una figata, perché la gente non la sta usando? Prende perché non è momento giusto.Quello che abbiamo fatto è che, tra il discorso di prima, i da zone, i team sono abbastanza liberi eccetera e dipendenti.Il problema che abbiamo avuto è, bella lì, esce una nuova libreria, un nuovo servizio, tac, dopo due settimane e tre team che hanno scritto la stessa libreria in javascript per connettersi a quel servizio.Il pro e il contro di avere, cioè non c'è una soluzione a questa cosa.O centralizzi tutto e hai i propri di dipendenze, o se decentralizzi, hai il problema di reinventare la ruota, che lo puoi accettare, è un costo che puoi accettare.Quindi quello che abbiamo fatto noi, abbiamo fatto questo progetto chiamato DIST, DAZN Inner Source, contrapposto a Open perché Inner perché è all'interno di...e qui praticamente hai questo portale in cui hai tutte le librerie, tutte le cose che ci sono su GitHub di DAZN, in modo per facilitare la ricerca e non...abbiamo creato questa interfaccia è molto carino come catalogo perché comunque ci buttiamo anche dei dati che github non ha oppure raccoglia che ne so conoscete volt per esempio? sì ok volte questo è il servizio di SQL management ok c'è anche questo problema abbiamo entrato a volt dopo tre settimane quattro librerie non c'è il sapore di interfacciarsi a volt tutte più o meno simili quindi alla fine se io arrivo e voglio io ti voglio utilizzare questa libreria quale capro scelgo? ci sono diverse cose, quanti progetti la usano, chi sono i maintainer, i maintainer sono ancora in azienda e tutte queste cose.Ci sono un sacco di dati correlati a questa cosa qua, la scelta.E' bellissima un'idea.Al momento nessuno lo sta usando come vorremmo e e lì dici in Bresciano "potà!" - Ce l'ho provato! - Ce l'ho provato! In il discorso di prima, nel senso, non fai troppe grosse pianificazioni, eccetera, perché alcune cose servono una roba del genere, sicuramente serve, però se la gente non la usa, perché la gente non la usa? Boh, perché magari in questo momento sono tutti in delivery mega mode, non lo so.Quindi temporaneamente abbassi l'arma oppure osservi? Temporaneamente abbassi l'arma, il servizio è ancora su e dici "buono non ci investiamo, ci sono un sacco di ticket, un sacco di idee che abbiamo su dister, il problema è di dire "ok ma nessuno sta usando questo tool" Quando si lavora sul prodotto, solitamente dalla mia esperienza ho visto dei PM fare delle sessioni con degli utenti tipo nell'utilizzo di tool, secondo te questo tipo di attività che ne so fare una sessione di pair con pinco del team Y ha senso per un engineer di DX che deve trovare qualche feature o avere il punto di vista verso un esigenza? Allora, anche a senso, lo devi fare.Uno dei primi prodotti che abbiamo rilasciato è stata la dashboard di deploy per i micro front-end e that's all.Non c'è una dashboard, non funziona il deployment interface per il back-end, perché sono tutti i microservizi, eccetera, ogni team, non ci serve questa roba qua.Ma per i micro front-end il concetto è diverso, perché l'artifatto che vai a produrre in realtà è tutto insieme, no? Quindi lì per quello che c'è una questione di avere un'interfaccia grafica per poter fare questa cosa qua.Quello che abbiamo fatto è, abbiamo praticamente scritto tutti i front-end di DAZN e abbiamo fatto una giornata di workshop in cui loro disegnavano e loro prioritizzano, loro sono i nostri clienti, giusto? Cioè nel senso sapranno meglio loro come andranno a deployare, come vogliono deployare la loro roba, che dati vogliono prendere.Quindi secondo me è un must, nel senso adesso stiamo lavorando sull'onboarding, abbiamo 500 persone abbiamo detto, 70 team, che mi sono messo a parlare con 70 manager, per dire con 50 o 40 manager.Abbiamo deciso di iniziare con platform, quindi abbiamo 5 o 6 manager di platform, abbiamo parlato con loro, cosa vi serve, ok, come è il vostro onboarding process.Poi abbiamo fatto noi sempre di DX un altro workshop con i new joiners negli ultimi 8 mesi, qual è stata la vostra esperienza? Cioè capisci che sono tutta attività molto da prodotto, produttore, PM, eccetera, però lo facciamo noi, ingegneri, sostanzialmente.E poi l'altra cosa invece che non abbiamo parlato è che rilasci per esempio la frontend deployment dashboard, dopo un mese oppure una settimana, "ah ma voglio quella feature", "ah ok perfetto, scusami ma non abbiamo tempo, vuoi venire con noi a lavorare due settimane e la facciamo insieme?" Oppure fai un APR.Per esempio una cosa che è stata fatta, non so se pubblichermo un blog post.C'è praticamente, sono delle parti che sono tutta l'architettura Microfrontend, però c'è la parte principale in cui c'è praticamente il catalogo e il player e l'altra cosa si chiama Sports Data, non so se avete mai usato MyDasono o una roba simile.Quando tu guardi per esempio un evento live, magari arrivi dopo e vuoi vedere dove era il gol o il cartellino rosso, sulla timeline ci sono queste cose.Playback, catalogo e questi dati, in realtà sono 3-4 tipi diversi, sono diverse librerie, però in realtà quando dovrebbero essere lasciate, le dovrebbero essere lasciate tutte insieme sostanzialmente, quindi creava un po' di problematica a livello di dipendenza, cioè il player doveva aspettare il catalogo eccetera."Quindi la tua chip vogliamo fare in modo di spezzarla, dobbiamo fare delle modifiche all'equipment dashboard" Bella lì raga, state lavorando voi su questa cosa, facciamo un team temporaneo in DX e 2DX vi supporta, 2DX probabilmente lavoreranno costantemente con voi, ma voi uscite dai vostri team e dedicate il tempo a fare questa roba qua.Quindi funziona un po' così.Sì, credo di sì.So che...Carmine? Sì, sì, in realtà credo che me l'hai praticamente servita su un fiatto d'argento, ma quindi nel senso noi stiamo parlando comunque del team DTX e mi sembra una grandissima figata e mi sembra anche di capire che può essere anche un posto dove magari si può fare innovazione, sperimentazione un po' più liberamente rispetto magari ad altri team.Secondo te potrebbe essere utile diciamo come proposta quella magari di far fare X tempo di X a diversi sviluppatori anche di altri team per fargli imparare o fargli capire come sviluppare dei prodotti che siano quanto più vero per friendly possibili, un po' la stessa stregua di...Non so se sei arrivato dopo della chiacchierata, quando hai trovato il concetto di rotazione.No? Sì, probabilmente sono entrato...Ok, rispondo parzialmente a tutto il domani, nel senso che sì, c'è il concetto che la gente se vuole può, o se abbiamo bisogno banalmente, magari ci vengono da noi e dicono bisogna fare questo tour e noi diciamo "ve lo facciamo, però avremo bisogno di queste due o tre persone che magari, tipo il discorso prima dei templating e scaffolding di growth, il progetto parte, ma parte con loro, quindi avremo due o tre persone di growth che lavoreranno con noi.E questo risponde a un parziale di domanda, perché l'altra domanda è molto più anche sul teaching e learning, giusto? Sulla parte del learning e il teaching in realtà non è una cosa che non l'abbiamo mai vista in questa ottica, non è una cosa che promuoviamo, ma anche perché no.Non è una cosa su cui dico "no", ma non è uno dei primi motivi su cui uno potrebbe trarre rotazione.È successo con un ragazzo che, per esempio, è arrivato a The Zone, doveva andare nel team di player, però non mi ricordo quali fossero i motivi.Il team non era pronto ad accoglierlo, che magari erano sotto consegna di cose eccetera e quindi giusto per fare anche cose interessanti è venuto a noi i primi due mesi.Una delle cose che vorrei fare, io però non dito troppo in giro perché non me l'avevo ancora provata, è che secondo me quello che dovrebbe succedere è che tutti gli ingegneri di Dazon, quando entrano in Dazon, nel primo mese devono fare almeno una settimana in platform.Perché secondo me questo può essere molto informativo perché chiunque nel loro percorso, nella loro vita da zone come ingegnere, in qualche modo entrerà in contatto con DX, con SAP e con Cloud.Fare una settimanina, fare quel concetto tipo open source, first issue, qualunque cosa di cui secondo me è una cosa che vorrei spingere, perché questo secondo me è il prossimo livello, anche a livello di mentoring, teaching, eccetera.No, no, diciamo, ti avrò fatto questa domanda perché almeno a meno una situazione del genere farebbe comunque piacere, perché sento comunque che potrei imparare magari anche, secondo me, un concetto anche di sensibilità in quello che scrivo, perché sto scrivendo qualcosa che deve essere utile ad altre persone e non ha, diciamo, come fine quello di realizzare quella feature del prodotto, insomma.Almeno secondo me ci può essere un tipo di sensibilità diversa anche nello scrivere e nel progettare qualcosa, sostanzialmente.Sono sull'accordo, però parliamo di nuovo come dire, sono solo 50 persone, sono tutte idee fighissime, sono tutte cose che sarebbe bello farle, ma bisogna anche capire un po' il contesto.Ottima osservazione.La mia ultima circo riguardo le misurazioni.Siete un'azienda molto data-driven, mi piace molto questo approccio, e è molto difficile farla secondo me in questo campo, in questo ambito.Meglio, devi avvalere obbligatoriamente degli strumenti utilizzati internamente, mi viene da pensare.Vedi Github, Gira, Teams, eccetera, eccetera, per raccogliere dati, e sui strumenti stessi.Quello che mi chiedevo è, ci sono dei KPI, dei nomi dei KPI, dei tipi di KPI che è importante cercare di andare a vedere in ognuno di questi per tirar fuori delle misure? >> LM: Allora, come dissi, non usiamo KPI ma usiamo KR.un secondo ti vado a leggere esattamente quali sono gli OKR.Ti potrebbe interessare se ti elenco i nostri OKR di questo quadrimestre? Spara, perché no? Allora, New Developer Time to Productivity reduced by 30%, ok? vorremmo che tutti i new joiners, il tempo richiesto per essere produttivi sia ridotto del 30%.Cosa vuol dire essere produttivi? Anche quello abbiamo un dubbio da definire.Per noi, per noi essere produttivi vuol dire che la persona che è arrivata nel team abbia è il tempo trasverso.Cos'è la produttività in questo caso? è il merge di una pull request in main.ok ok ok sarebbe figo dire produzione perché sarebbe la cosa migliore però anche qui cioè di ex non può dettare.Certo perché la produzione è più veicolata dal owner che dice quando deve andare online quella feature, non è detto che vada online.C'è anche questa libertà, in un senso che è difficile, grossa, chiaramente l'impatto sui tenti, chiaramente c'è il produttore che dà la green light, però a livello anche di micro servizi così non è.Però diciamo, non sapendo esattamente come tutti i team lavorano, se per esempio abbiamo un nuovo joiner in DX in cui noi decidiamo cos'è la produttività, per me la produttività io voglio che un nuovo joiner merge su main il primo giorno, per esempio.Però non posso imporlo a tutti, capisci? Quindi qui hai una misurazione, perché noi abbiamo già i dati su github di quando uno ha joinato all'org e di quando uno ha aperto una pull request e di quando uno ha fatto il merge.Quindi non lo fai univoco, però poi vuoi dire "ok, come faccio a dire che ha migliorato dal 30%?".Beh, se per quello specifico team o in generale si è abbassato vuol dire che il bimbo aggiunto poi in prodotti scopera abiliti e software in dazione engineering e ribadisco abbiamo un voto di roba no e non so se lo conoscete è fighissimo si chiama backstage è un prodotto di spotify che adesso open source noi siamo anche contributo adesso ho letto l'articolo la settimana scorsa è un praticamente è un esame un death quarter nato come un API catalog e si è espanso, possono fare migliori di migliori di plug-in, lo stiamo adottando anche noi.E per esempio il nostro OKR per questo quarter è che il 100% dei servizi sono importati in backstage, l'80% degli ingegneri può filtrare e vedere i propri servizi con backstage.Queste sono le nostre, siamo data driven, abbiamo i dati di questa L'altra cosa che stiamo facendo, se volete faccio un po' di promozione, se andate su www.medio.com/dazon-tech c'è un articolo sul fatto che stiamo migrando a GitHub Action, uno delle OKR è che in questo corte ci saranno 20% in più di repository che si sono spostati a GitHub Action e come team, come DX, vogliamo che 80% dei nostri repository migrati a GitHub entro la fine del quarto.Poi abbiamo un obiettivo un po' più personale, che è "Improve Operational Maturity of DX Services", che vuol dire che dobbiamo fare almeno una Threat Modeling Session, tiri giù qualcosa a caso e deve essere risolta, e la Production Readiness Review.Quindi siamo data-driven, quindi non è così difficile secondo me capire i dati, è capire quali sono i dati più importanti, che è diverso.Ti ho risposto, spero.Sì, sì, perfettamente, grazie.Molto molto interessante.Wow, guardavo i tempi di registrazione e siamo lunghissimi.Mi sentite? Ragazzi, mi sentite? Sì, sì.Ho un ritorno orribile.abbiamo perso Mauro, eccolo lì.Dicevo siamo andati lunghissimi ancora due minuti di orologio per il nostro famoso momento dei Paese dei ballocchi, il momento in cui ognuno di noi, in particolar modo i nostri ospiti, condividono un libro, un talk, un video, un software, a qualunque cosa ha catturato la loro attenzione.Cirpo, hai qualcosa per noi? "E conduco nel paese dei balocchi" "Ah, il paese dei balocchi" Sì, è una roba che è un po' nerd, però non è relativa al codice o alla DX, eccetera.Mi piace cucinare e avevo visto questa serie, non mi ricordo se è su Netflix, si chiama "Salt, Fat, Acid, Heat" sulla cucina, sostanzialmente.C'è questo libro, che si chiama "Salt, Fat, Acid, Heat" "Mastering the elements of good cooking", in cui praticamente hai i quattro elementi, il sale, il ciccio, il grasso, l'acido e il calore, e ti spiega un po' come combinati.È un po' nerd, ma neanche troppo.È un bello grosso tra l'altro, perché saranno almeno 500 pagine, però è figo, nel senso che è una piacevole lettura che si può fare.Volevo dare qualcosa di diverso, un po' più culinario, visto che è ora di cena, qua adesso.Anche in Italia.Io posso andare con il mio.Io porto un libro che si chiama "Deskbound", che è una specie di manuale per fare correttamente alcuni esercizi di stretching, ma non solo, anche come camminare, specificatamente per chi passa la giornata sulla scrivania.Quindi va a risolvere quei problemi che abbiamo tutti.Io ho iniziato sfogliarlo, parla un sacco di teoria, poi ci sono tantissimi esercizi, uno lo deve leggere tutto, dice "mi fa male il collo" e cerca gli esercizi per il collo.Però è super interessante e, non so perché, ma nella mia bolla di informazioni l'ho sentito parlare già tre volte in dieci giorni, per cui ho detto "lo porto anche qua, almeno si alimenta la bolla".Puoi ridire il titolo di nuovo, per favore? "Deskbound".Ok, grazie.Sì, poi questi link dei balocchi sarà possibile trovarli ovviamente nelle note dell'episodio di Hitbar, quindi ora vado col mio che, visto che, diciamo, come sempre non me lo preparo, arriva così all'ultimo il balocco, abbiamo toccato temi anche riguardo al mentoring, leading eccetera eccetera e quindi vi vorrei consigliare questo diciamo sito di conference che è leaddev.com dove organizzano un sacco di conferenze molto interessanti, workshop eccetera eccetera su questa tematica.Io ho seguito per la prima volta quest'anno in primavera una loro conferenza e sono rimasto davvero molto affascinato e quindi ve la consiglio vivamente.Quando vieni sulla Lodro, ci andiamo assieme.È veramente figa come conferenza, soprattutto perché le persone che stanno dietro sono… Forse una delle… Scusa, ti interrompo.No, no, hai fatto benissimo.È una delle prime conferenze in cui… L'ha chiamata Lead Dev e probabilmente, secondo me, l'ha fatta un po' come specchietto della Lodro, perché in realtà è molto di più sulla leadership e le manager.C'è Camille Fournier, che è quella che ha scritto "The Manager Parts".C'è...non ricordo più come si chiama...- Luke Peccato.- Ma è veramente figo.Sombramente è veramente figo.Sì, sì, io dovevo andare nel 2020 a Londra, ho preso biglietti tramite l'azienda, poi ovviamente è scoppiato il Covid, è saltato tutto, e quest'anno diciamo si sono rinnovati lanciando il brand "Together" online.Ed è stato davvero molto, molto bello.Prego, Carmine.Allora, io porto un talk che si chiama "How I learned to stop worrying and love doing less".A parte di aver fatto il mio inglese influenzato, praticamente è un talk che dovrebbe essere, almeno io sono riuscito a trovare il video solamente dalla Devroom community dell'ultimo l'ultimo Fosnem che vi invito comunque a vedere tutta, ed è praticamente questo talk dove viene spiegato come gestire le tante idee e le tante cose che ci vengono in mente o che possono venire in mente al nostro gruppo di lavoro per farle in una maniera sensata, per fare cose in una maniera sensata.La risposta è semplicemente farne meno, ma fare solo quelle che portano veramente valore.Ovviamente questa cosa che vi sto raccontando sta banalizzando 45 mutui talk, che ho visto e sono bellissimi, però in realtà dà dei consigli pratici su cui poter misurare anche quello che è una cosa che ha valore o meno e gestire anche l'ansia da questa produttività forzata che spesso ci imponiamo.Tocca a me, è un mio unblocco libro che ho qui adesso sulla scrivania perché ho finito di leggere da poco, me l'hanno consigliato i nostri amici baristi, anzi mi hanno obbligato leggerlo perché poteva essermi utile.È un libro molto noto nel settore, quindi sicuramente la maggior parte di voi lo conoscerà, però per quei pochi che non lo conoscono, The Phoenix Project è una bella lettura, è un romanzo di un tal Bill che si ritrova a essere capo responsabile del team della sua area IT e scopre che deve sistemare un po' di cose, quindi migliorare i processi, far parlare meglio gli sviluppatori, quindi c'entra anche un po' il tema di oggi.Il protagonista si chiama Bill e quindi la morale è che bisogna essere come Bill, come dice un noto gruppo che forse qualcuno conosce, sì come Bill.Niente, è un libro molto molto bello che consiglio.E poi The Unicorn Project.Quello che seguo lo devo ancora leggere.Esatto, sono libri bellissimi.Io in realtà stavo per portare l'audiolibro che ho iniziato l'altra sera, quindi diciamo che il mio balocco è in cooperativa con Luca e quindi riciclo dal cappello dei balocchi un altro si chiama Dev Experience in Enterprise è un video su youtube dura pochissimo dura 15 minuti ed è un un video di Toothworks molto molto carino da vedere.Bene, ormai la nostra puntata è andata.Io immagino Cirpo come...so che ognuno di voi ha visto James Bond, no? Quindi Cirpo un po' il Q della situazione, quello che ha sempre un tool pronto per ogni cosa e col suo team dà i superpoteri ai nostri James Bond di tutti i giorni.In realtà mi piaceva questa similitudine del fatto James Bond lo sviluppatore Q che è quell'ingegnere che fa tutti i giocattoli per James Bond come la parte di Dev Experience.Tra l'altro dovreste vedere quello che vedo io grande Cirpo.Ormai sono bollito.Aiutatemi! Intanto ringrazio Cirpo per esserci venuto a trovare.Grazie di cuore.Grazie a voi.ormai anche tu fai parte di questa allegra combricola perché tutti i nostri ospiti o coloro che vengono una volta nel nostro bar hanno accesso illimitato e bevute illimitate quindi serviti pure quando vuoi anzi se per caso hai qualcosa di nuovo da raccontarci o qualcosa di particolare da condividere la nostra porta è sempre aperta sentiti pure un po' con me a casa tua beh se succederà di ex engagement eccetera magari ho qualcosa da raccontare fra una mezza bellissimo bello bello bello allora ti aspettiamo è arrivato il momento di ricordare i contatti info@gitbar.it @brainrepo su twitter oppure il nostro gruppo telegram gruppo telegram sì il gruppo telegram è la nostra casa è il posto dove ci scambiamo le informazioni, chiacchieriamo, parliamo del più e del meno, tooling, contratti di lavoro, parliamo di tantissime cose.È un po' la base nonché il gioiello nascosto di Gitbar dove diciamo il podcast è solo un elemento accidentale, il vero valore è il nostro grande gruppo Telegram, quindi se non l'avete ancora fatto iscrivetevi.detto questo io rinnovo il ringraziamento a Cirpo, ringrazio anche Carmine, Andrea, Leonardo e Luca che hanno accompagnato me in questa chiacchierata, anzi diciamo hanno guidato questa chiacchierata con Cirpo.Io vi do appuntamento alla prossima settimana visto che ormai le ferie estive sono terminate è tutto grazie ancora ciao ciao ciao a tutti ciao grazie il po' ciao ciao ciao anche un cane che saluta Gitbar, il circolo dei fullstack developer una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei fullstack dev [Musica] [Musica]
