Bene e benvenuti su Geekbar, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori Sono le nove e mezza, siamo un po' più tardi del solito, quindi se sentite la nostra voce calante...

la mia sta sparendo...

se sentite la nostra voce calante il motivo è questo, ma l'argomento di oggi è un argomento iper interessante Parliamo di DevRel, DevAdvocate, DevEx, Dev...

tutto quello che non è scrivere codice ma è mischiare codice e gente E per farlo ho due amici con me, nonché ammutinati, nonché costo di Geekbar, nonché colonne portanti del nostro podcast Abbiamo Andrea e Mattia, ciao ragazzi, com'è? Ciao caro, sempre un piacere Andrea almeno ha la birra, io ho appena finito di bere le proteine Ma infatti, apro una piccolissima parentesi, io sono qui non perché sono esperto di DevRel o faccio il DevRel, ma sono interessato all'argomento Sai quando hai una...

diciamo...

Quando hai una birra Una brutta giornata impegnativa, cioè che è bello perché fai il lavoro che ti piace, però torni a casa e sei sfatto totale Allora ti arriva una bella notifica, o stasera si regista l'episodio con Mattia su DevRel Ah da paura, allora mi piovo una birra, vado al mio bar preferito, mi siedo e farò le domande da coglione ignorante che sono sul tema Per scoprire che cos'è DevRel Guarda, per te è bello andare al bar dopo una giornata del genere Esatto, quindi saluto Però tu Matti non puoi ordinare un peperone di proteine al bar, o te lo fanno? Troppo tardi, non lo so, però nell'ultimo mese e mezzo che sono a dieta mi è capitato diverse volte di andare fuori a mangiare tipo con mio figlio e i suoi amici Così, cos'hai, mangiare un piatto di verdure grigliate in posti dove probabilmente nessuno li ha mai chiesti Tipo senza fare product placement, mi immagino una scena di tu al Mc Donald's, al Burger King, tuo figlio e gli amichetti che si strafogano e tu le verdure grigliate di plastica Al Mc o al Burger King ancora no, ma mi è successo un birrificio qua vicino molto buono che fa degli hamburger ciccionissimi E mio figlio si è mangiato una cuccia con la porchetta e i pomodori secchi e io ho mangiato un piatto di cavolo cappuccio Vabbè, tipo il coltello nello stomaco e quant'altro, ti vuoi proprio male Però funziona Beh, però il controllarsi così ci porta a diciamo spingerci sui oltre i nostri limiti no? Quindi è una sfida importante quella che Mattia sta facendo e che io non riuscirei mai a fare per quello che nel giro degli ultimi tre anni ho preso tipo 20 kg Ma le sfide veramente Aspetta perché adesso faccio un gancio molto bello perché uno dei motivi per cui io sto facendo questa vita di privazione è che nel mio anno a Londra in cui ho fatto la mia prima esperienza da developer advocate Ho preso 10 kg in un anno perché nell'ufficio di Londra di Google si mangiava e si mangia molto bene e io ero di cattivo umore quindi mangiavo tantissimo E tra l'altro è abbastanza comune che chi entra a Google prenda una decina di kg appena entrato proprio perché c'è cibo dappertutto Beh, ma si mangia bene anche a casa tua, cioè se hai deciso di fare lo stesso lavoro ora Eh, però devo cucinare Mi dicono però che da Amazon c'è tipo la filosofia frugal quindi magari potresti fare switch e perderne 20 perché non ti danno da mangiare Probabilmente sì, per dirti sono stato in ufficio la settimana scorsa perché dovevo fare una roba a un certo punto entro in una stanza deserta, non c'era nessuno perché era venerdì e l'ufficio era semi deserto C'erano tre piatti giganti di fette di pane e nutella già fatto, avrei potuto mangiarli tutti Mio Dio Lì veramente mi sono detto ok, se riesco a non mangiare questa roba sono veramente diventato un maestro Jedi della Dio Ok, Mr.

Ferrero, se ci stai ascoltando mandaci dei barattoli di nutella da un chilo per favore O dei soldi 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 E comunque, c'è comunque da dire che nonostante tutto queste sfide sono comunque più semplici che avere a che fare con la gente E tu nel tuo lavoro come developer advocate in Google hai a che fare tutti i giorni con la gente immagino O è un mito No è vero, allora faccio una serie di preamboli incastrati uno dentro l'altro Primo, il mio lavoro si chiamava developer advocate tra il 2018 e il 2019 quando stavo a Londra Poi sono rientrato e adesso faccio la stessa identica cosa ma si chiama developer relations engineer Perché? Fondamentalmente perché Google ha deciso che era una buona idea chiarire il fatto che noi che facciamo DevRel siamo comunque degli engineer Quindi siamo gente che sa scrivere codice e siamo gente che appunto, come dici tu, parla con la gente che scrive il codice Nel mio caso, e poi magari vi racconto in dettaglio come è fatto il mio team e cosa facciamo Ma io per un buon 80% del tempo anziché scrivere codice quando facevo lo sviluppatore sui prodotti Ho a che fare con gente che scrive codice, non scrivo codice direttamente ma faccio supporto proattivo e reattivo a gente che scrive codice Quindi sì, io ho a che fare con la gente E dal mio punto di vista io lo faccio per l'API di Google Ads quindi ho vantaggi e svantaggi in questo senso Perché tipicamente questa gente con cui ho a che fare è gente che vuole fare in modo che noi guadagniamo dei soldi E vuole farci del margine sopra quindi ci sono di mezzo dei soldi che vuol dire che quando le cose non funzionano La gente è un po' più incazzata di quelli che usano tipo dei progetti open source E di contro sono anche tutti molto collaborativi perché quando noi facciamo dei soldi loro fanno i soldi Quindi quando va bene va molto bene, siamo tutti amici e si fanno un sacco di soldi Quando va male e non ci sono i soldi ci sono i PZERO Eppure è così particolare, è strano vedere che in realtà esiste una connessione in quello che fai Così potente col business, spesso il developer advocate e il team di DevRel è sempre un po' lontano dal business A meno che in strane situazioni dove per magia tra doppi apici il team di DevRel diventa anche team di sales Ma questi sono casi alterati e un po' alieni Adesso ti droppo il primo dipende della giornata Nel senso che dipende tantissimo da qual è il business in questione Nel senso che per dirti all'interno di Google stessa che poi di fatto ha imparato mettendoci le mani E centinaia di aziende diverse, ci sono mille modi diversi di fare DevRel perché ci sono mille business diversi Per dirti il modo in cui lo faccio io è abissalmente diverso dal modo in cui lo fa la gente che fa DevRel per Chrome O per Android o per Cloud E dipende appunto da come è fatto il business Nel senso che Chrome e Android sono prodotti open source con API SDK su cui la gente fa delle applicazioni Ma Google non ci fa dei soldi per esempio o almeno non direttamente E questa cosa sposta tantissimo per esempio Nel mio caso invece io ho a che fare con un prodotto che fa l'80% del fatturato di Google E soprattutto ho a che fare con un prodotto in cui la componente di sales è molto importante Nel senso che tra la gente con cui io ho a che fare c'è anche tantissimo dei team di sales interni di Google Che sono di tipi diversi a seconda delle aziende e degli sviluppatori con cui io ho a che fare Ma una grossa parte del mio lavoro per esempio è avere a che fare con i team di sales Che hanno un modo di lavorare completamente diverso dai team di engineering Perché hanno dei target di revenue da cui dipendono i loro stipendi per esempio O perché comunque tipicamente sono persone con un background non necessariamente tecnico Fanno un altro lavoro In fin dei conti una cosa che ho imparato e che mi piace tantissimo come definizione È che il lavoro di DevRel è un lavoro di ponte Nel senso che io di mestiere faccio il ponte tra un sacco di entità diverse con background diversi Che parlano lingue diverse e hanno obiettivi diversi Per dirti io faccio da ponte tra aziende partner, che poi vi racconto più in dettaglio cosa sono E il nostro team di engineering che è il team che materialmente sviluppa le API Faccio da ponte tra il team di sales e il team di engineering Faccio da ponte tra il team di sales e i partner Faccio da ponte tra i partner e il resto del mio team per esempio E quindi questa cosa che poi è uno dei motivi per cui questo lavoro mi piace tantissimo Fa sì che tu debba saper parlare un sacco di lingue diverse Perché hai a che fare con persone di estrazioni background e interessi diversi Chiaro, proviamo a fare questo esperimento Proviamo a vedere il tuo lavoro dal punto di vista pratico E poi piano piano risalire su quelli che sono gli impatti e su come ti poni In modo da proprio fare un percorso La tua giornata, dovendola organizzare, come è? Allora, anche lì è una delle cose che mi piacciono tantissimo di questo lavoro È estremamente vario, dipende tantissimo Dipende da com'è la giornata, dipende da come sono i partner con cui lavoro Dipende tantissimo anche da cosa ti piace fare Nel senso che nel mio team ci sono persone che hanno il mio stesso job title E fanno per una buona parte le stesse cose che faccio io E per una parte altrettanto buona, no Però nel mio caso specifico la mia giornata è fatta così Allora, io anzitutto sono l'unico in questa time zone nel mio team Ho a che fare con partner europei, ma il grosso del mio team sta a New York Che vuol dire che la mia giornata è abbastanza divisa in due tronconi principali Che sono quando New York dorme e quando New York sveglia E oltre a questo c'è un terzo chunk grosso che è quando si sveglia Mountain View Che è il momento in cui succedono le cose a Google E il brutto di questo è che Mountain View si sveglia quando qui sono le sei di sera Quindi a me capita di rado perché non lavoro con tanta gente a Mountain View Ma capita comunque che io abbia riunioni a orari brutti, tardi Che sono mattina presto in Silicon Valley Comunque la mia giornata quindi tipicamente la mattina Che quando New York dorme è fatta o di focus work Quindi di lavoro in cui non ho rottura di palle perché il resto del mio team dorme O di lavoro con i partner Che è una parola che ho già detto diverse volte Ma forse vale la pena spiegare un po' cosa intendo per partner Nel mio caso si intendono aziende che vogliono sviluppare applicazioni on top All'API di Google Ads Quindi per fare degli esempi estremamente concreti Wix.com o Prestashop di turno hanno il loro toolino che ti fa fare i siti e-commerce Tu sei un tizio che vuole vendere della merce online Vuoi farti il sitino per venderla online e usi il prestashop o il wix.com di turno Fai il tuo sitino e-commerce, ci carichi i tuoi prodotti E a un certo punto il signor Prestashop o il signor Wix Ti dicono guarda, già che hai questi prodotti perché non li pubblicizzi su Google? Tra l'altro noi siccome siamo partner di Google Ti possiamo anche dare dei coupon per fare pubblicità su Google Ads gratis Schiaccia questo tasto all'interno dell'interfaccia di Prestashop o di Wix E crea le tue campagne Google Ads Quando tu schiacci quel tasto interagisci con l'API di Google Ads Che quindi ti fa creare le campagne, ti fa creare gli asset delle tue campagne Ti fa settare il budget delle tue campagne pubblicitarie e così cosa L'API di Google Ads in realtà è un API piuttosto complicata Perché Google Ads è un prodotto piuttosto complicato Fa una serie di cose veramente depravate Sia sotto il cofano che anche a disposizione degli utenti Per cui spesso e volentieri il Wix.com o il Prestashop di turno Hanno bisogno di una persona di Google Che dica loro per esempio quali sono le feature che possono essere interessanti per loro nell'API Oppure che li aiuti a fare troubleshooting Oppure ancora che gli dica guarda abbiamo appena lanciato una versione nuova dell'API Con questa roba che ti può servire potresti usarla Oppure si torna di nuovo al rollo del ponte Parlando con il Wix.com di turno Venga a sapere che Wix ha bisogno di una feature che nell'API non c'è E costruisca una feature request per il team di engineering Fatta nel modo che rende più semplice la vita del team di engineering Nello specifico nel caso di Wix.com e Prestashop quella persona di Google sono io E anche di un po' di altri partner Per cui questo è il mio lavoro di partner dev rel Dimmi Andre Curiosità riguardo a questa particolare tipologia di giornata lavorativa Quindi tu oltre a supportarli, aiutarli a utilizzare le nuove API o a trovare bug E aiutarli a utilizzare le API In qualche modo prendi anche dei feedback sulle esigenze dei partner Barra clienti Quindi in qualche modo sei anche una chiave importante sul peso della roadmap O la messa in priorità dei task da assegnare agli engineer Assolutamente sì Tra l'altro molto concretamente il caso di Wix è un caso emblematico Wix fa un sacco di richieste API Fa un sacco di campagne Fa un sacco in definitiva di soldi Per cui quando apro un bug o apro una feature request Se io ci scrivo dentro questa cosa serve a Wix La fa automaticamente balsare in cima alla lista di priorità Quindi diciamo che non abbiamo un processo formale in cui si mettono in ordine le priorità Come potrebbe essere uno sprint planning o grooming Si ordinano le priorità delle cose in cui siamo coinvolti anche noi Però sì, il fatto che noi abbiamo a che fare con gente che sposta molti soldi Comunque ci dà il potere di mettere in cima le cose o di metterne in fondo delle altre Quindi un po' di peso sulla roadmap ce l'abbiamo Vai E tutto questo diciamo viene fatto a Sempre viene ingaggiato oppure piazzi delle call di routine settimanali, bisettimanali, mensili Che immagini che ovviamente tu hai citato due grossi parte Però diciamo ne curi decine e decine Poi vabbè dipende anche dal volume Può darsi pure che chi ha delle bestie, ha delle balene ne cura meno Chi ne ha tanti piccoli ne ha tanti piccoli Immagino Esattamente così e tra l'altro questa cosa mi dà modo di droppare un altro dipende Nel senso che dipende tantissimo sia dal feeling che ha il partner Nel senso che ci sono persone che schifano le call e preferiscono comunicare via mail Ci sono persone che invece per qualunque cosa ti dicono dai sentiamoci un attimo ne parliamo Tipicamente però diciamo che nella mia esperienza la maggioranza dei partner ha una call settimanale o bisettimanale Da mezz'ora a un'ora in cui facciamo un po' il punto della situazione Poi comunque è una cosa che adatti col tempo per dirti io nell'ultimo anno avevo un partner Con cui avevo una call settimanale in cui anziché mezz'ora ci prendevamo Sette minuti in cui mi dicevano si si va tutto bene siamo sulla roadmap siamo a posto non ci serve supporto A un certo punto ci siamo detti vabbè diciamo che ci sentiamo ogni due settimane E oggi ho fatto una call bisettimanale con loro e anche lì è stata si si ok tutto a posto tutto secondo la roadmap Quindi potrebbe essere che switchiamo ancora a una modalità un po' più meno frequente Mentre invece ci sono partner con cui ho una call settimanale di un'ora E che poi il resto della settimana ti tempestano di mail e anche lì poi dipende da in che fase del progetto sono Per cui per esempio questo partner qui sta per lanciare la beta nella loro integrazione Quindi giustamente sono in fase di testing molto intensivo e scoprono cose di giorno in giorno E oltretutto è capitato che ittassero dei limiti o dei bug dell'API o di cose che non si possono fare E che vanno risolte abbastanza in fretto appunto sono lì per lanciare la beta Quindi dipende poi oltre a questo è verissimo anche quello che dici tu Che per esempio c'è una persona nel mio team che ha un unico partner che si chiama Amazon E non ha materialmente il tempo per averne altri Oltre a questo però il mio team è un mostro a due teste Nel senso che il team è un po' più esteso e composto sia dai developer advocate o da quelli che si chiamavano developer advocate Che fanno quello che faccio io Ma abbiamo anche un team che fa quello che noi chiamiamo scaled dev rel Per cui anziché avere dei partner con cui hai un rapporto molto profondo e molto stretto Loro fondamentalmente rispondono ai ticket di supporto che vengono escalati dai nostri agenti di supporto E quindi qualunque azienda può avere a che fare con loro È un rapporto diciamo più transazionale nel senso ho un problema me lo risolvi Mentre il developer advocate ha un rapporto continuativo e proattivo con l'azienda Quindi noi facciamo entrambe le cose Io l'ho fatto per un po' come parte del mio training Ed è una cosa che non farei Però le persone che lo fanno si divertono tantissimo perché comunque è molto diverso Nel senso che ti capita in un giorno 5 persone con cui tu non hai mai parlato e non riparlerai mai più Una volta che hai risolto il loro problema che hanno un problema complicatissimo da debuggare E quindi fondamentalmente le persone che fanno questo lavoro sono Detective Conan Sono veramente i maestri del debug e sanno investigare le peggio cose Infatti quando mi è capitato che stavo facendo supporto E vedono i peggio mostri immagino E vedono i peggio mostri sì sì sì C'è una persona nel mio team che è super brava e ha esperienza e conoscenza su qualunque cosa dell'API Quando io stavo facendo training di questo tipo di supporto Avevo un caso che non avevo idea di cosa cazzo stesse succedendo Ho chiesto aiuto a lei e lei mi ha detto Eh questa cosa in effetti è strana E io lì mi sono letteralmente cacato nei pantaloni Lei dice così vuol dire che non c'è soluzione sta succedendo il finimondo Stanno stuprando le nostre API Sì poi sai in realtà anche lì è interessante anche capire quali sono i partner divertenti e quali no Nel senso che a volte pensi ok vorrei un partner che non mi smarona mai Che mi dice sempre che va tutto bene e che è a posto con il progetto su cui stiamo lavorando assieme Lo sta per rilasciare e va tutto bene Ed è quello che ti dicevo prima che mi dice sempre sì sì tutto a posto siamo in linea con la roadmap E quelli sono facili da gestire Perché comunque fai bella figura perché loro rilasciano il progetto senza troppo sbattimento Però poi ci sono i partner quelli un po' più intensi Che veramente fanno del male all'API e la usano in dei modi che nessuno avrebbe mai pensato E cercano di fare cose che nessuno pensava fossero possibili E veramente spostano in là i limiti di quello che puoi fare con le API E lì ti devi fare un po' più il culo perché loro veramente fanno delle cose arcane e strane Però Google ha un sacco la fissa dell'impatto e che devi dimostrare dov'è che hai effettivamente avuto impatto Dov'è che il tuo lavoro è stato valuable E in quel caso lì funziona di brutto perché comunque se tu dici Guarda io stavo lavorando con questa parte, loro avevano bisogno di questa feature Io ne ho parlato col team di engineering, l'abbiamo disegnata assieme, loro l'hanno rilasciata E in virtù di questa feature questo partner ha fatto x mila dollari di revenue in più E noi pure...

bella per te Ti sei pagato lo stipendio Eh sì, hai dovuto farti il culo però poi quando fai la performance review quella cosa lì brilla abbastanza Mi hai ricordato le mie discussioni col team di DevRel di Shopify, i poverini Shopify è un altro nostro partner, è un altro di quelli che ha il developer ad which ci lavora solo Shopify Tra l'altro a proposito di questo mi spiace tantissimo che oggi non ci sia Alessio Perché quando io sono entrato a Google a Londra, lui lavorava a Hootsuite che all'epoca si chiamava ancora Adespresso E aveva un developer advocate che era il mio vicino di scrivania Quindi tipo il mio primissimo giorno a Google sono arrivato lì e questo tizio mi fa Oh guarda vuoi venire a vedere com'è fatta una call con un partner? Tra l'altro sai sono pure italiani, si chiamano Adespresso Per puro culo Alessio quella volta lì non c'era Altrimenti avrei riso tutto il giorno Vero, Ale, si Ale, Matti volevo farti una domanda Nel developer journey che è più o meno il percorso che un DevRel cura col suo cliente Che inizia da un momento probabilmente anche di pre-sale, di interessamento, di evangelizzazione A un momento di post-sale e ultima iterazione Tu nel tuo lavoro hai individuato uno slice molto preciso no? Ed è uno slice che possiamo dire centrale no? Prima del deploy, prima del rilascio, betta applicazione e nell'evoluzione dell'applicazione Questa è più o meno la parte che vai a coprire Nel vostro lavoro, nel tuo team Quella che copro io scusami però Esatto infatti volevo chiederti quello Nel vostro team il lavoro di pre è fatto da chi? Perché è splitato? Se esiste un motivo per cui queste due azioni sono divise E come percepisci questa differenza di, cioè questo modello organizzato, da azionale? Allora è una domanda interessantissima che io stesso ho fatto il mio manager tempo fa Perché non capivo, nel senso che quello che mi sono risposto poi Quando sono stato alla conferenza di developer relations engineer di Google Si chiama DevRelCon In cui ci sono quelli che fanno DevRel per tutti i prodotti Mi sono reso conto che noi non facciamo DevRel nel modo in cui DevRel fa DevRel Perché lo facciamo in un modo abbastanza diverso Per dirti quello che un po' tutti hanno in mente Quando si parla di DevRel è molto più vicino al modo in cui lo fa il team di Chrome o quello di Cloud E fanno quello di cui parlavi tu come evangelizzazione Nel senso che per farti un esempio molto concreto Io non vado a parlare alle conferenze di API di Ads Mentre non puoi fare una conferenza senza che ti arrivi un developer relations engineer di Cloud A farti vedere qualche figata di GCP o qualche magia nuova di Chrome Per dirti nel team di developer relations di Chrome ci sta gente tipo Jake Archibald o Una Kravets Che sono famosi anche perché stanno a tutte le conferenze del mondo E tra l'altro su Jake ho un aneddoto dopo Per cui il mio team specifico lo fa in un modo un po' diverso La risposta che mi diede all'epoca il mio manager è Perché la scelta se usare o meno l'API di Ads non la fanno gli sviluppatori Il nostro target di sales e di evangelizzazione non sono gli sviluppatori Ma sono i CFO piuttosto che i C-level delle aziende Che decidono ok integriamo anche Google Ads nella nostra offerta di business Mentre se sviluppare un'applicazione su Chrome in JavaScript lo decide uno sviluppatore O se usare Google Cloud lo decide al massimo un CTO O comunque dell'agente tecnica che ha bisogno di persone tecniche Per essere convinta a usare questo prodotto Usare o meno Google Ads è una decisione di business È una decisione di soldi Quindi gli stakeholder che prendono questa decisione sono stakeholder di soldi Che parlano con persone di soldi che stanno nel team di sales Poi ci sono figure ibride all'interno del team di sales Che hanno anche un grosso background tecnico E che quindi vanno anche a convincere i C-level del caso A dirgli ora che noi possiamo integrare la nostra API nella tua applicazione E fare una cosa tutta seamless all'interno della vostra applicazione Per cui voi fate le campagne di Google Ads dentro il front end di Prestashop Però a livello puramente decisionale, quindi a livello pre Come dicevi tu, le persone tecniche tipicamente non sono ancora coinvolte Vengono coinvolte in un momento successivo che è il momento in cui entro in gioco anche io Cosa che però è caratteristica solo di Ads Chiaro, però se vogliamo affermare il fatto che Se parliamo un po' più a ampio respiro L'ecosistema DevRel in questa grandissima famiglia Rientrano anche quelle persone che vanno alle conferenze Scrivono articoli, vanno alle community a spingere A presentare il proprio servizio, prodotto, API, quello che è Quindi non stiamo parlando di qualcosa che sia al di fuori dell'ecosistema DevRel Ma che ricade sempre dentro questa famiglia Sì, poi tieni conto che noi non facciamo evangelizzazione in senso stretto Nel senso di dire vado a una conferenza o scrivo degli articoli Perché così gli utenti che non stanno usando la mia API iniziano ad usarla Però comunque in un certo qual modo è un lavoro che facciamo lo stesso Nel senso che comunque il mio team e io facciamo video su YouTube Per spiegare meglio le feature dell'API Facciamo post sul blog di Google Ads Developers per annunciare le feature nuove Quindi diciamo che materialmente il lavoro ha molta sovrapposizione Infatti comunque noi facciamo molto training anche su questo E per dirti i colloqui io li ho fatti con un sacco di gente del team di DevRel di Android L'intento con cui lo facciamo è leggermente diverso Proprio perché è leggermente diverso il momento del developer journey in cui interveniamo Sì e poi secondo me esiste anche un'altra differenziazione Ci riflettevo prima di iniziare a registrare Io vengo da una società di consulenza E un'altra differenza importante Nel modo di fare DevRel Nota margine Vengo da una società di consulenza che fa un botto di DevRel Ma un botto davvero e lo fa in modo strutturato Adesso non lo dico perché è la società per cui lavoro Però è conosciuta in Europa per essere forte da quel punto di vista E riflettevo, provavo a immaginare qual è la differenza Tra fare DevRel di un prodotto E anche là si possono fare delle ulteriori differenziazioni ma ci arriviamo dopo E fare DevRel in termini di servizio Perché quando tu fai DevRel in termini di servizio Quello che tu devi promuovere, evangelizzare È la tua expertise E là il tranello è dietro l'angolo perché davvero basta veramente poco Per diventare autoreferenziali Scusami, dal mio punto di vista di esterno rispetto alla tua società di consulenza La percezione che ho io è che il modo in cui fa DevRel questa società è molto per una questione di branding Perché di fatto è marketing E dire ok noi siamo attenti all'esigenza degli sviluppatori, alla developer experience e quant'altro Quindi guarda come lavoriamo bene e quindi assumici per fare il tuo progetto E nel contempo per esempio una cosa che fa il team di DevRel è tantissimo open source Che da una parte è potenziare il toolkit che tu usi quando vai da un cliente Perché in questo la società per cui lavoro è molto precisa Noi lavoriamo su quel tech stack, arriviamo là con una expertise di quel tech stack e ti risolviamo il problema Però nel contempo fare open source in quel caso è in un certo modo fare DevRel Anche se stride, però è fare DevRel Stride perché in realtà siamo già nell'ambito magari della DevEx Per esempio nella società dove lavoro non esiste un team di DevRel, esiste un team di DevEx Ed è colui che si occupa di curare ambedue le cose Quello che volevo evidenziare sono questi confini sfumati Stiamo avendo difficoltà ad attaccare ruoli ed etichette E questa cosa è un bene, ma nel contempo genera molta confusione quando si deve immaginare un certo learning path Dillo a me Scusa Andrea, ti ho fregato Andrea aveva la mano alzata da un po' Scusami Più che altro oltre a avere alzato la manina perché volevo fare un'osservazione Nell'ultimo ragionamento che facciamo, Mauro, hai proprio bruciato una domanda che però segnala che davvero qualcosa gli interessa Però se siete d'accordo ci tornerei dopo su dei confini tra DevRel e DevEx Ma farei un passo indietro su quello che invece discutiamo prima Nel senso di azienda che fa tanto DevRel, persone che fanno tanto DevRel Allora voi che l'avete visto un po' più da vicino e che lo fate anche La domanda che mi viene è quanto è difficile mantenersi, cioè non andare troppo oltre l'asticella per non essere personal branding Ma essere DevRel per la mia company Cioè quanto è complicato, perché molto spesso mi viene da pensare, io mi metto nei panni di una persona che va ovunque, fa qualsiasi cosa Dove ti giri c'è sempre lui che ovviamente sta facendo davvero molto bene l'arte di DevRel Spingere la roba della sua azienda, del suo software source, eccetera, della sua community Quanto è complicato fare in modo che non sia personal branding ma che sia DevRel? Molto, poi lì secondo me la differenza la fa molto l'intento con cui lo fai Nel senso che a un certo punto quando lo fai davvero tanto diventa evidente, almeno per chi non è proprio alle prime armi Se tu stai facendo DevRel perché vuoi aiutare la comunità di sviluppatori o degli sviluppatori specifici O perché sei fondamentalmente un paraculo e stai facendo personal branding e vuoi metterti in mostra Poi è vero anche che a conti fatti potrebbe essere una situazione win-win Ci sono molti DevRel famosi che per intenti che non so, perché non li conosco personalmente O non ci ho parlato personalmente, ma fanno entrambe le cose Danno un grosso contributo alla comunità di sviluppatori o comunque sono molto d'aiuto E anche sono molto famosi e questa cosa gli porta lavoro, soldi e quant'altro Per cui diciamo che come tutte le cose in cui sono coinvolte delle persone La linea è molto sottile, variabile e sgamarla è spesso una cosa da utente smaliziato Però ci sono molte situazioni in cui puoi non vedere questa linea o volutamente ignorarla E tutto sommato stiamo bene tutti così Io ho come molti di voi sanno, io ho avuto un'azienda per un bel po' della mia vita E quest'azienda faceva PR, aveva delle persone che facevano PR Non erano strettamente DevRel ma fondamentalmente in un altro dominio quello facevano Erano qualcosa Rel Esatto E quindi vi posso rispondere da imprenditore Cambia tutto con l'approccio dell'azienda E l'azienda che detta le regole del gioco Questo vuol dire che se l'azienda ti permette di fare del personal branding È perché si trova o è un'azienda sprovveduta oppure si trova in una condizione di win-win Perché? Perché magari dà talmente tanti benefit nel senso largo del termine a questa persona E fidelizza la persona e la persona diventa l'azienda Nel senso che la persona sta talmente bene in quell'azienda Che gli permette di andare in giro per il mondo, fare tante belle cose Fare quello che gli piace e con la persona alla fine diventa uno a uno con l'azienda Quindi potrebbe essere un amplificatore Esatto Assolutamente Naturalmente questo succede nel mondo ideale Il mondo reale talvolta assume anche una serie di sfumature che non sono o il bianco o il nero Adesso vi parlo da imprenditore Una cosa che io feci quando mi trovai davanti a questa situazione fu quella di distribuire la responsabilità Distribuendo la responsabilità tu stai distribuendo la visibilità Ha un costo questa azione, non è gratis Però nel contempo ti a, rimuove completamente tutte le vulnerabilità derivanti dal single bus factor B, tu dimostri che l'azienda non è una persona E in ambito sales questa cosa è importante Perché quando vai a fatturare tu non stai fatturando, parlo di aziende di consulenza come era la mia Non stai fatturando il lavoro di una persona Ma stai fatturando il lavoro di un team Terzo, crei una serie di policy per cui si sostituisce il noi al io Detto tra noi, tra io, Andre, Mattia e i 1500 ascoltatori che ci stanno sentendo E il gruppo Telegram E il gruppo Telegram esatto Tappate un attimo le orecchie ragazzi per favore Che rimanda tra noi Detto tra noi, una delle fatiche più grandi che ho avuto quando avevo l'azienda è forzare chi si occupava di PR a dire noi al posto di io Ho fatto un lavoro talmente pesante, tale che, e qualcuno se ne è anche accorto Io non riesco più a dire io Anche al lavoro, chiudo una PR e uso il plurale E un mio collega mi ha detto, potremmo fare No potresti fare, potrei fare, non potremmo fare Usi il plurale maiestatis Vabbè la battuta è stata quella no? Casse il mago Telma Però ecco, lo spingere ad adottare questo approccio Fa sì che, insomma, ci si protegga Anche perché, in un modo o nell'altro Il DevRel, Dev Advocate In qualche modo, possiamo immaginarlo come la testa Che appare, la faccia di una certa entità Quindi che noi lo ammettiamo o meno Siccome la faccia ha una certa influenza Nel team che sta dietro, magari di engineers Magari una certa influenza nel backlog Lui ha anche un ruolo di leadership Se vogliamo vederlo in ambito molto più ampio E quando tu hai un ruolo di leadership Qua forse mi sto spostando un po' oltre Però quando tu hai un ruolo di leadership E vuoi portarlo, accompagnarlo in modo effettivo Tu devi essere un servant leader E a quel punto tu usi un noi al posto di un io E risolvi il problema che Andrea stava dicendo prima Ho bisogno della pastiglietta adesso No, no, è tutto assolutamente sensato Tanto più che, guarda, per dirti Nel mio caso, poi sai Io sono un pochino facilitato dal fatto che Il brand dell'azienda per cui lavoro Nel 99,9% dei casi è più grosso Del brand della singola persona Non mi vengono in mente singole persone Che hanno un brand più grosso di quello di Google Per cui è difficile per noi dire io Quando vuoi dire Google Però tantissimo del lavoro che facciamo noi Soprattutto all'inizio, quando sei in fase di training iniziale È fare in modo che tu impari ad avere il tone of voice di Google A parlare nel modo corretto Che significa comunque che per esempio noi Come parte del nostro team iniziale Oltre a fare appunto supporto, quello di cui vi parlavo prima Facciamo anche molto shadowing delle call Degli altri developer Adwpait con i loro partner Un po' per vedere com'è fatta l'interazione Ma un po' per appunto imparare il tono di voce Per imparare qual è il modo Google Di comunicare con gli sviluppatori Che magari non è necessariamente il tuo Magari non è quello che ti viene spontaneo Dopo un po' sì Però il tone of voice è importante E in quello c'è anche appunto dire Molto più noi che io O praticamente mai io E di nuovo per me è facile Perché noi sono 150.000 e passa persone E io sono l'ultimo degli stronzi E quindi nessuna maniera di grandezza Che io possa mai avere Potrebbe farmi dire io rispetto a un progetto gestito da Google Però è comunque così È una cosa verissima C'è un problema di fondo però Che è il problema di tutto DevRel Ed è amplificato dal momento in cui tu dici più noi che io E il problema grosso del mestiere del DevRel È come si misura se un DevRel sta lavorando bene o no Come fai a dire ok tu sei un buon DevRel tu no E la tua performance a livello di quest'anno da Developer Relations Engineer è andata bene Quest'anno hai lavorato bene Quest'anno sei stato bravo Quest'anno no La prossima volta le domande non me le segno comunque Non ti tranquillo Questa era facile questa è la domanda Mattia è un po' come si chiamava quel conduttore italiano Fatti una domanda e datti una risposta No sono Marzullo Si faccia una domanda e si dà una risposta Ma io che cazzo ne so Parliamo di API dai La risposta è molto grossa ed è molto dipendente Nel senso che uno dei modi che hai per misurare le performance di un Developer Relations Engineer È l'impatto di cui parlavo prima Io ho lavorato con un partner e ha rilasciato il suo progetto in tempo E funziona e fa dei soldi con l'API di Ads Bella sono stato bravo O forse ho avuto culo però Perché quella lì è una misura indiretta Che dipende dal lavoro di altre persone Quindi come fai a dimostrare che questo progetto funziona perché tu hai avuto un impatto Certo perché dall'altra parte potresti avere degli ingegneri incapaci Che non sono degni di questo nome E cannano la scadenza e impatta sulla tua performance Oppure di contro potresti aver culato e aver beccato della gente bravissima Che non ha mai avuto nessun problema E funziona tutto e tu non hai fatto niente E sono tutti contenti E tra l'altro mi fa molto ridere questa cosa quando ci penso Perché è molto simile a una cosa che io faccio nel mio tempo libero Come hobby che è l'attività dell'allenatore I ragazzi giocano bene e l'allenatore è bravo I ragazzi giocano male e l'allenatore è scarso E tu non hai fatto nulla di diverso I progetti vengono consegnati in tempo e devrà il bravo I progetti vanno in ritardo e devrà il coglione E tu non hai fatto nulla di diverso Oltre a questo ci sono anche una serie di altre cose che puoi fare Per dimostrare l'impatto e che dipendono tanto anche dal progetto su cui lavori Per esempio una cosa molto dritta che funziona spesso È uscire una nuova feature del prodotto su cui lavori Che può essere l'API di Ads, ma anche una feature nuova di Chrome È uscito un progetto nuovo di Cloud Misurare l'adoption a seguito di contenuto che tu hai prodotto Per presentarlo, spiegarlo, hai fatto delle guide, hai fatto dei video Sei andato a presentarlo a delle conferenze E l'adoption di questa feature è salita dell'X% È una misura un pochino più dritta del tuo impatto Anche lì potresti avere culo oppure no Potresti aver pescato dal cilindro una feature bellissima Che è strafacile da usare e tutti usano proficuamente E fai una bella figura Potresti aver pescato una feature che è complicatissima da spiegare E in qualunque modo tu faccia e per quanto bravo tu sia La gente fa fatica ad adottarlo Per cui anche lì è sempre un po' una misura indiretta E per dirti un dilemma classico è Noi tra le altre cose scriviamo le guide su developers.google.com Di come fare le cose sull'API Le page views delle guide sono una metrica buona per misurare Se tu hai fatto un buon lavoro o no No No, o sì Se tanta gente legge la tua guida è perché la guida è scritta bene O è perché la feature fa schifo Oppure perché la guida è scritta male e la gente la deve leggere tante volte Ci sono molti modi di misurare il lavoro di DevRel Ma sono quasi tutti indiretti Proprio perché è un lavoro in cui tu non scrivi direttamente il codice Non fai direttamente le cose con i prodotti Ma le fai con le persone E quindi c'è spesso, quasi sempre, un layer intermedio tra te e le metriche E devi imparare un po' a essere bravo e parà a culo tu A spiegare a chi ti sta misurando Potrebbe essere il tuo manager, potrebbe essere il comitato che valuta la tua promozione Dove esattamente tu hai avuto impatto E un po' devi avere culo ad averlo, l'impatto Perché a volte puoi essere bravissimo e non ce l'hai Oppure puoi non fare niente e sembra che tu ce l'abbia avuto Ciao Carmine Nel frattempo si è unito a noi anche il buon...

Buonasera, buonasera Buonasera Carmine Mi sentite, sono online Sei raffreddato Sono molto raffreddato, ho l'influenza E in realtà sono riuscito a connettermi al più a colpo perché sono con Windows stasera Quindi non ho avuto nessun problema di sorte Invece con la mia distro preferita sì In 15 secondi ha sparato il primo flame Carmine No no no, assolutamente In realtà io ero entrato, ne stavamo parlando anche oggi Per fare una sola domanda e poi esco così e vado via Che non so in realtà se avete già fatto Se avete già fatto questa parte la tagliamo Che relazione c'è tra essere un devrelle e un developer advocate? Perché spesso anche online l'ho vista intrecciata come cosa Io non ci ho mai capito niente nella mia grande ignoranza Beh in realtà dipende tantissimo dall'azienda Ogni azienda li chiama anche un po' come cazzo vuole E una delle cose che stavo dicendo prima è proprio che Google ha cambiato nome A questa cosa tra quando ero lì nel 2018 e adesso Nel senso che io faccio esattamente le stesse identiche cose Nel 2018 ero un developer advocate Adesso sono un developer relations engineer Sostanzialmente è la stessa cosa diciamo Ma i nomi li sceglie HR o marketing? Infatti, interessante Li sceglie Bard Questa era una battuta Però ecco, abbiamo parlato di KPI Proviamo a visualizzare l'attività del devrelle Immaginiamo un triangolo Piace sempre a tutti immaginare triangoli Ok Nella parte alta ci mettiamo l'area di engineering Il punto di engineering Un po' come i grafici dei calciatori su FIFA Sì sì Ok, abbiamo l'area di engineering L'area di prodotto E l'area di marketing sales Ok A livello di KPI Quello che tu Di cui tu hai parlato È un punto di valutazione Nella parte magari più marketing e sales Cioè quanta gente è tirato dentro Ma le KPI variano anche nel spostarsi Nell'indirizzamento dell'attività di devrelle È una domanda più difficile Credo la più difficile da fare In realtà l'ho capita C'è un gradiente di ruoli all'interno di devrelle Ecco, come cambiano le KPI Col cambiare di queste Allora, io su questa cosa ti posso rispondere Ovviamente solo rispetto all'esperienza Di come gestisce questa cosa Google Non so come lo fanno le altre aziende Ma nel caso specifico di un developer In relationship engineer di Google Il nostro lavoro e quindi i nostri KPI E il nostro triangolo È assolutamente chooser on adventure Nel senso che te lo decidi da solo In base a quello che ti piace fare In base a quello che tu pensi abbia senso fare Per il team, per l'azienda, per Google E per l'umanità E per dirti all'interno del mio team Io ho persone che hanno quel triangolino lì Fatto in modo estremamente diverso Nel senso che qualche tempo fa C'era una persona Partendo dal presupposto che il supporto ai partner Lo facciamo tutti E ci sono alcune cose che facciamo tutti Come per esempio la gestione di developers.google.com O questa cosa qua Il resto del triangolo È assolutamente up to you Cioè nello stesso team e con lo stesso job title Hai persone che fanno contenuto su YouTube E di fatto fanno gli streamer Quello che faccio io in parte Ma ci sono persone invece che fanno Drittissimo il vertice di engineering Per esempio qualche tempo fa È successo che l'API aveva grossi problemi di performance È un aneddoto molto buffo che se abbiamo tempo vi racconto Serviva qualcuno Tra il team di engineering e noi Che mettesse in piedi una suite di benchmarking Delle performance dell'API È una roba piuttosto complicata dal punto di vista ingegneristico Anche perché dovevamo misurare Le performance non solo dell'API stessa Ma anche delle sei client library che manteniamo Che sono Java, PHP, Python,.NET, Ruby e Perl Quindi di fatto dovevi fare benchmarking di un API E di queste sei client libraries assieme Era una roba piuttosto intensa ingegneristicamente parlando L'hanno fatta in due Che di fatto fanno formalmente lo stesso lavoro che faccio io Io questa cosa però non credo che la saprei fare Ci sono persone invece che si occupano di Disegnare il processo di feature request all'interno dell'API Quindi sono molto spostate verso il vertice del prodotto Uno dei motivi per cui a me questo lavoro fa impazzire È che tu puoi sceglierti da un quarter all'altro Su quale dei vertici di questo triangolo concentrarti di più Lo scegli un po' perché appunto pensi che Abbia un impatto positivo sul team, sull'azienda e sull'umanità Ma un po' perché pensi anche tu di riuscire ad avere un impatto positivo E poi in definitiva anche di fare bella figura nelle performance review Però è assolutamente lasciato alla tua scelta Poi ogni tanto capita, mi è capitato Che il manager di turno venga e dica Ok c'è questa roba da fare, chi la fa? E lì vabbè Qualcuno la deve fare e si fa Ma è Mattia che fa l'integrazione dell'API in Turbo Pascal? Manco per il cazzo Già faccio C-Sharp E ho fatto PHP Non parliamo mai di PHP per favore No però per istinere Quando stavo a Londra mi è successo, e credo di averlo già armentato, di buttare il podio Stavo facendo one to one con il mio manager Ma per caso conosci PHP, ci serve uno che faccia il maintainer della client library PHP E io non ho avuto il cuore di mentirgli E quindi per un po' sono stato il maintainer della client library PHP delle API di Azi Beh fa curriculum, grande Non ne vado a ridere Comunque senti, davvero tutto super interessante A me piacerebbe tornare un po' sul discorso che abbiamo cantonato un attimo prima Sulle eventuali sfumature o intersezioni Non per forza come viene visto questo in Google Ma immagino che anche tu facendo questo Ti sia documentato in letteratura, eccetera eccetera Abbia letto cose tempo fa E qualche altro episodio, se non sbaglio, è anche consigliato una newsletter Riguardo a questo tema, che ovviamente mi sono iscritto immediatamente Divelo paravocalos Esatto, e quindi ero davvero interessato a Le possibili intersezioni e sfumature Tra il discorso DevRel e DevEx Developer Experience Dove ovviamente ipotizzo, la butto lì Che ci sono degli ambiti dove probabilmente sono molto simili Altri ambiti che sono due cose completamente differenti Ti prego, argomentiamo Io ti do la mia interpretazione Che poi magari si rivelerà essere una assoluta cazzata Però per come la percepisco io Developer Relations è una cosa che ha a che fare con la relazione con le persone È parlare con le persone e capirne le esigenze e poi tornare indietro Eventualmente dal team di engineering oppure tu materialmente Implementare queste esigenze all'interno della tua API o del tuo prodotto Che poi è un prodotto per sviluppatori, quindi realisticamente è un API Developer Experience invece è una cosa un po' più astratta e meno legata alle persone È disegnare un API che funzioni bene, che sia ergonomica Che rispetti i principi del buon padre di famiglia dell'API Che sia disegnata bene, che sia facile da usare Dove è facile da usare però di nuovo dipende dalle persone che la usano E quindi forse anche lì un po' di rapporto con le persone c'è per forza Secondo me però è un continuum Non è che se tu fai DX non hai mai a che fare con le persone Ma sviluppi il tuo prodotto in isolamento e poi speri che sia facile perché lo è per te E se fai Developer Relations invece non scrivi del codice ma parli solo con le persone Ci sono migliaia di sfumature di grigio in mezzo Sì, le Developer Relations e comunque la presenza umana in un certo prodotto Fa parte di un elemento del ventaglio della Dev Experience E il sapere che c'è qualcuno là Se hai una partnership e se sei sul prodotto giusto Che quando hai un problema tu tiri su il telefono e dici Ehi velo mio aiutami perché qua sono in merda Allora io ti volevo chiedere come si diventa DevRel Cioè metti che io voglio diventare domani mattina DevRel Come posso imparare? Che cosa posso imparare? E soprattutto c'ha senso questa figura anche in aziende medio-piccole Lo chiedo perché ci sono tante aziende molto più piccole di Google ovviamente Che hanno prodotti che vengono usati da sviluppatori, da clienti sviluppatori Insomma che hanno effettivamente dei prodotti simili Ha senso che in quel caso la figura di DevRel O è qualcosa che possono permettersi solo le aziende più grandi? E dico questa ultima cosa perché in altre puntate quando abbiamo parlato di DevX Ci si è sempre fermata su questa cosa Che magari aveva senso solo se l'azienda era abbastanza strutturata Perché ovviamente anche questo è un costo Ma allora vado a ritroso e rispondo per prima alla tua ultima domanda E secondo me la risposta è dipende ovviamente Perché in un'azienda piccola magari quello che è DevRel O comunque in un team piccolo Quello che è DevRel magari è collassato all'interno di una persona che fa anche altre cose Per cui tu per esempio potresti essere uno sviluppatore Che scrive il codice dell'API o di qualunque prodotto che tu offra Che ha come target degli sviluppatori E nel momento in cui tu fai design dell'API Alla luce di quello che pensi o che ti è stato detto dalla comunità dei tuoi utenti Che è il modo migliore Stai facendo DevRel Di fatto A un certo punto DevRel è né più né meno che attenzione all'utente Dove l'utente però è uno sviluppatore E non è l'utente finale che clicca i pulsanti del tuo sito Ma è un utente che scrive del codice contro una tua API Per cui se tu sei una persona qualunque che sta attenta alle esigenze dei tuoi utenti slash sviluppatori Stai facendo DevRel Poi a seconda di quanto è grande il team e di quanto è grande l'azienda Potresti decidere che fai solo quello Fai solo il ponte di cui parlavo prima Però probabilmente, anzi sicuramente Se la tua azienda fa un prodotto che ha come target degli sviluppatori Tu fai DevRel in ogni caso Non puoi non farlo perché il tuo utente sono degli sviluppatori Rispetto invece a...

Sì, ma diciamo sia ora che quando anche qualche domanda fa non riesco a non pensare al fatto che ti ascolto E non faccio altro che rivedermi davanti agli occhi tutte le definizioni riguardo a uno sviluppatore di DevX Allora se dico che qualcosa del tipo DevRel è per qualcosa veicolato a persone fuori dall'azienda E se invece dico DevX per persone è qualcosa dentro l'azienda È una blasfemia? Perché c'è davvero tante similitudini e tanti stessi concetti o stessi gradi di attenzione e focus Occhio però Andrea, scusami Mattia Quando tu dici DevX sta dentro l'azienda, DevRel è interfacciarsi con fuori Non è completo nel senso che per esempio le API di Google devono avere una developer experience di un certo livello Dove l'interfacciamento con la persona è un elemento Però una buona documentazione, una buona ergonomia delle API che fanno parte della parte di DevX devono essere anche una delle componenti che si interfacciano verso fuori C'è anche per l'interno tutto questo? Ma tra l'altro aggiungo dell'ulteriore benzina su questo fuoco Dicendo che quelli che fanno DevX o DevRel che dir si voglia per i tool interni di Google Quindi tipo per il Kubernetes interno di Google piuttosto che queste cose qua Si chiamano platform DevRel Quindi loro lo fanno internamente ma si chiamano DevRel E secondo me è veramente solo una questione di nomenclatura Però di fatto il lavoro è quello quando tu stai facendo qualcosa per cui stai attento al tuo utente E il tuo utente è uno sviluppatore e stai facendo DevRel o DevX che dir si voglia Vero Perché alla fine...

Vai Mauro, perdona No, no, vai Andre No, quello che devo dire è che in entrambe le aree a me mi sembra che quello che si vuole andare a fare è appunto cercare in tutti i modi, in qualsiasi, tutte le armi che abbiamo Nel nostro coltellino svizzero, cinturone eccetera eccetera Fare in modo che l'altra persona che sta dall'altra parte, che è fuori o dentro Raggiunga il suo obiettivo nel meno tempo possibile E nel meno tempo possibile, con più facilità possibile, con meno stress cognitivo eccetera eccetera Sì, sì, è proprio una questione di ergonomia E c'è da aggiungere un'altra cosa Che è una particolarità dell'industria dove ci troviamo E della parte di relazioni nell'industria dove ci troviamo È che in buona parte dei casi Facciamo l'esempio di Mattia Quello che Mattia fa, o quello che Google fa con l'API che cura Mattia Per il quale lavora Mattia Non è vendere un prodotto Ma porsi in un contesto, in una condizione di co-creazione Quando tu vai a co-creare con la persona Tu non stai solo Tieni, questo è il mio prodotto, bon, prendilo Ma una parte, anche se non appare formalmente Una parte della responsabilità del prodotto creato È il tuo E le esigenze che ha il cliente in un processo di co-creazione Sono molto più alte Perché non sono solo esigenze Sono anche paure E spesso le paure sono molto più forti della mera esigenza E tu sei là nel percorso di co-creazione Per fare da assistente tecnico in qualche modo Quindi dagli una mano dal punto di vista tecnico Fagli capire come funzionano le cose Rassicurarli nel fatto che le API non crashano quando loro scalano Per esempio, adesso Google magari non è il caso Però è un'esperienza che io ho vissuto Lavorando in un ambito enterprise Abbiamo preso una startup Un servizio di una startup E praticamente alla prima richiesta abbiamo sentito tutto scricchiolare E a quel punto siamo subito andati dal team di DevRel Dal nostro referente e gli abbiamo detto Ok, noi siamo un enterprise, siamo una multinazione, siamo grossi Siete sicuri? Ci rassicurate che non ci crolla tutto sotto il culo? E questa cosa è importante Tanto se non più di tutta la parte di evangelization Perché tu, comunque, quella relazione non è solo a crearla La difficoltà della relazione non è solo crearla È facile creare relazioni Il complesso viene subito dopo Quando entri nel processo di co-creazione Dopo che hanno fatto il POC delle tue API E avevano visto che funzionano in locale Works on my computer E poi bisogna trasformarli in un prodotto E tu ci devi essere Quindi devi essere un po' tecnico, un po' psicologo Un po' comunicatore, un po' esperto Un po' trainer e formatore Perché il loro successo è il tuo successo Mi hai dato un braccio Per un alleddito fantastico Vi ho accennato prima al fatto che a un certo punto L'API di ATS ha avuto dei problemi di performance La storia più bella che sta dietro a questo momento È la storia di una figura di merda colossale Che abbiamo fatto un po' tutti Praticamente quando sono entrato la prima volta Nel 2018 Avevamo fatto una cosa che è classicissima di Google È proprio il pattern di Google Abbiamo deprecato l'API che c'era E quella nuova era in beta Per cui una grossa parte del lavoro Che facevamo noi con i nostri partner all'epoca Era dirgli oh dai migrate all'API nuova Che anziché usare SOAP usa gRPC ed è molto più figa Va velocissimo, superforte Ha un sacco di feature nuove, fa un sacco di cose Ci stavamo addosso tantissimo perché migrassero all'API nuova Che all'epoca era in beta Quindi spingevamo anche un po' a dirgli Oh dai usate l'API nuova è bellissima E nel frattempo aiutateci a farla meglio A un certo punto a gennaio del 2019 Rilasciamo la 1.0 General Availability e post sul blog Oh minchia bellissima adesso la potete usare tutti Dai oh cosa fate ancora con l'API vecchia di SOAP Che fa schifo, usate l'API nuova è bellissima Dopo che succede questa cosa Qualcuno viene in mente di fare dei performance benchmark E l'API nuova è 30 volte più lenta di quella vecchia Quindi con il capo cosparso di cenere Siamo andati ognuno di noi dai suoi partner E gli beh ti ricordi quando nell'ultimo anno Ti abbiamo detto che dovevi migrare all'API nuova Perché quella vecchia faceva schifo Non era vero Ci sono stati lunghi mesi In cui abbiamo fatto andare più forte l'API nuova E a un certo punto poi andava effettivamente più forte Mi hanno detto dai facciamo che ritorniamo Dove ci eravamo lasciati qualche mese fa E quindi potete tornare a migrare all'API nuova E l'API vecchia l'abbiamo spenta in autunno di quest'anno Cioè del 2022 Quindi è stata una cosa di fatto La migrazione ci si aspettava che sarebbe durata anni E è durata anni più X Per via di questa cosa E appunto c'è stato un momento Che è molto legato a quello di cui parlava Mauro In cui di fatto noi avevamo Per noi era molto importante Capire lo sbattimento, lo scoglionamento E il dolore degli sviluppatori a cui avevamo detto Di migrare all'API nuova E poi a un certo punto gli dicevamo di no Una cosa di cui sono andato a parlare diverse volte Dai devrel bravi E questo tra l'altro poi mi ricollega Alla domanda che aveva fatto all'inizio Carmine A cui non ho ancora risposto È che una delle skill principali Per uno che è bravo a fare developer relations È l'empatia Per ti mettere nei panni della persona con cui lavori E saper fare i suoi sbattimenti E fare i tuoi anche i successi che avete insieme Fa parte di quel processo di cocreazione di cui parlava Mauro Per cui quando io parlo con Wix o Prestashop Io sono Google a un certo punto Ma io sono anche un pochino Wix e Prestashop E devo riuscire a immedesimarmi nelle loro esigenze A capire esattamente che cosa serve loro E capire perché serve loro E andare poi dal team di engineering A dire guarda che a Wix di turno serve questa cosa E loro magari mi dicono Ok dai noi la esponiamo in questa entità dell'API Perché ci viene comodo Perché sta nella stessa tabella su DB E io dico zio guarda che fa schifo Perché così per gli sviluppatori è scomodo E quindi io devo empatizzare con il team di engineering Devo scrivere del codice in più Perché deve esporre in due point diversi Delle cose che stanno in una tabella sola Ma anche nei panni dello sviluppatore Che vuole avere un API facile da usare Per cui una grossa parte del mio lavoro È mettermi nei panni di qualcun altro E fare in modo di capire come aiutare queste persone A come dicevi tu Andre prima A ottenere il loro obiettivo nel modo più semplice possibile E tra l'altro per tornare alla domanda di Carmine appunto Come si diventa così? Come si diventa questa cosa? Secondo me un modo molto interessante di analizzare questa domanda È come sono diversi i colloqui da developer relations engineer Rispetto a quelli da software engineer generico Io ho fatto entrambi Ho fatto i colloqui da software engineer per Google più volte Ogni volta senza successo Ho fatto quelli da developer relations engineer due volte Perché sono entrato, uscito e rientrato Entrambe le volte con successo I due learning parts di fatto I due skillset che ti chiedono in fase di colloquio Hanno ampie aree di sovrapposizione e ampie divergenze Nel senso che tipicamente un colloquio da developer relations engineer Funziona che tu hai due domande E fai più di questi colloqui, ma in ognuno di questi tu hai due domande Una domanda è la classica coding question da colloquio tecnico Che può essere, che ne so Uno dei collochi che ho fatto Abbiamo parlato tantissimo, all'epoca era super di moda Di un algoritmo per giocare a Wordle Quindi che strutture dati useresti per disegnare un programma che gioca a Wordle Come progetteresti l'algoritmo che gioca a Wordle Perché useresti un approccio piuttosto che un altro E cose di questo tipo Ma l'altra domanda invece è legata all'aspetto comunicativo ed empatico Di un developer relations engineer Per cui per esempio una domanda che mi fu fatta la prima volta che ci colloqui Era raccontami un API che ti piace Su cui hai sviluppato e che ti piace e perché ti piace Andre lo so che per te questa cosa è molto sul confine tra DevRel e DevEx No perché, sorrido, perdonami perché una domanda molto simile La faccio in ottica di colloquio per ragazzi, per il mio team di DevEx Quindi davvero mi viene da sorridere Ma che ci sta, nel senso che è super interessante tutto questo Perché fa parte di tutte le possibili sfaccettature Punti di approccio che alla fine vanno in direzioni molto simili E bisogno di persone con skill o soft skill Attitudini molto simili per fare cose molto simili Che possono essere chiamate in maniera differente Poi sempre parlando di skillset Quindi appunto per fare il developer relations engineer Devi poter essere un engineer, devi sapere scrivere codice bene Però secondo me c'è anche un'attenzione diversa Nel senso che per esempio io lavoro, come vi dicevo, tantissimo su progetti open source E la percezione che ho avuto io, perché poi non ho avuto feedback diretto e concreto su questo Ma la percezione che ho avuto io quando ho fatto i colloqui È che ci fosse più attenzione al fatto che il codice che stavo scrivendo in fase di colloquio Fosse leggibile e chiaro Piuttosto che super performante e ON anziché ON log N Ovviamente devi saperlo e devi dirlo e devi saper dire Guarda ho scelto di fare questa cosa ON anziché ON log N perché mi sembra più leggibile Però diciamo che quando fai DevRel, nel mio caso perché fai cose open source E quindi devi scrivere del codice che spiega delle cose Anziché scrivere del codice che fa delle cose È importante più la chiarezza che l'efficienza Detto che se scrivi del codice di merda che va super lento comunque sei capra Però per dirti, noi una grossa parte del nostro lavoro all'interno delle client libraries ci sono i Code Examples Che sono esempi di delle operazioni più comuni che tu puoi fare con l'API di HATS E tutti, tuttissimi ci dicono sempre che sono il loro punto di partenza principale Quando devo sviluppare una feature nuova, se c'è un Code Example lo prendo, lo copio, lo incollo nel mio codice e poi lo modifico E quindi quella roba lì è un pezzo di codice che fa qualcosa Ma è un pezzo di codice esplicativo Cioè non sta lì per farti vedere, per creare una campagna Ma è lì per farti vedere come si fa a creare una campagna E questa cosa ha un pochino di sfumatura nel modo in cui tu il codice lo scrivi Per dirti, io negli esempi scrivo dei commenti che non scriverei normalmente Mati ti faccio una domanda La prima volta, se ricordo bene, se la memoria non mi tradisce La prima volta che venisti a GitBar parlamo di Code Review È vero E voglio collegarmi con un doppio carpiato a questa cosa Ormai...

Perché noi parliamo di empatia Esatto, ma ancora prima di coinvolgere l'altro nel processo proprio Mi interessava capire Ormai è da un po', è dal 2018 che tu fai DevRel, giusto? Poi in realtà hai sospeso per un po' e hai fatto Team Lead o qualcosa del genere, ricordo bene Sì, ho fatto il Kotlin Hai fatto Kotlin, esatto, e abbiamo una puntata anche su quello E poi sei ritornato Però comunque questo processo di spingere l'acceleratore sulla comunicazione È premesso che il codice parla agli umani e non alle macchine Ha cambiato qualcosa nel tuo modo di vedere il codice? E scrivere il codice, al di là della sua funzionalità, non sto parlando di examples, ok? Ma devi scrivere un side project o devi fare una Code Review su Mokey Il fare DevRel, ti ha cambiato il modo di fare queste altre cose? Dipende, nel senso che una delle cose cruciali che impariamo e che ti chiedono anche ai colloqui Quando crei un contenuto di qualunque tipo, può essere codice ma anche no E qual è, non so come si dice in italiano, l'intended audience di questo contenuto Qual è il pubblico di riferimento, il lettore di riferimento Per chi stai creando questo contenuto? Sì, più o meno il target, anche, sì Per cui tu moduli la tua comunicazione, che può essere codice o no In funzione della persona a cui pensi di star parlando Per dirti una cosa che mi hanno chiesto diverse volte in fase di colloquio è Ok, questa cosa che mi hai appena spiegato, adesso spiegala a quest'altra persona Per dirti, con la domanda lì sull'API che mi è piaciuta Spiegamela come se fossi uno sviluppatore JavaScript Spiegamela come se fossi un CTO, spiegamela come se fossi uno che sta a una conferenza Oppure ancora, io in fase di colloquio ho dovuto portare una presentazione E ho portato un talk che ho fatto a CodeMotion Incidentalmente era un talk su Saga Pattern che ho fatto in italiano e in inglese E l'ho cambiato nel frattempo In base al feedback che mi era arrivato la prima volta E l'ho cambiato ancora per la presentazione che ho fatto a Google E di fatto le domande che mi hanno fatto su questa presentazione sono state molto di più Su quanto io l'avessi cambiata, perché e per come Che sulla presentazione stessa Per cui, saper modulare la tua comunicazione in base alla persona a cui pensi di star parlando Che poi magari non è necessariamente quella a cui stai parlando davvero E te ne accorgi dopo e hai fatto una cazzata Questa è una skill grossa che mi porto dietro dalla mia esperienza di DevRel Che abbia influito sul mio scrivere codice in generale, dipende Perché appunto, quando scrivo del codice in generale Adesso mi capita di chiedermi Ok, questo codice perché lo sto scrivendo, chi lo leggerà È del codice che devo buttar via? È del codice che devo condividere con qualcuno? È del codice di MockEye che devo rilasciare open source? È del codice che sto scrivendo per il team con cui sto lavorando? È del codice di cui so che mi farà CodeReview uno molto puntiglioso? E questa cosa influisce Di fatto mi ha aggiunto un dipende in più quando scrivo del codice Tu scrivi il nuovo modello, dipende Però vedete, questo lo dico agli ascoltatori Martì è una di quelle poche persone che inizia le frasi con dipende Poi però smonta, smembra e analizza le cose Cerco di convincermi che i miei non sono dei dipende paraculi Esatto No, non lo sono, non lo sono, posso confermare Ma a questo punto, se ti dovessi chiedere Quale progetto open che usi o che hai utilizzato Ti sarebbe piaciuto o ti piacerebbe che avesse lo stesso tipo di DevRel che hai tu a Google? E secondo te qual è un progetto che ne potrebbe beneficiare e perché? Perché secondo me è interessante analizzare anche questo tipo di sfaccettatura E secondo te si può fare con i progetti open Dove non c'è effettivamente qualcuno che ti paga, questo è ancora più interessante È interessante soprattutto perché ci sono diverse variabili nei progetti open Prima non c'è qualcuno che ti paga e in molti progetti open non c'è qualcuno che decide Perché la gente può mandare le pull request e magari c'è un team di maintainer Che ha tante teste e tante opinioni A livello open source, secondo me della gente che dovrebbe pagare un DevRel è la gente di Spring Perché io mi voglio bene, mi sono guadagnato da vivere per un sacco con Spring Però diciamo che spesso e volentieri funziona perché hai culo e hai provato delle configurazioni a caso finché non funziona Quindi forse loro vorrebbero, e sicuramente c'è della gente che lavora a Spring e fa DevRel e scrive le guide e quant'altro Ma credo che potrebbero investirci un po' di più Salutiamo il signor Spring che ci guarda da lassù e se vuole fare una donazione è sempre il benvenuto come tutti gli ascoltatori Che ha detto il giorno dopo dell'equinozio insomma Chiaro, io mi riferivo alla primavera non al progetto open Assolutamente Io credo guardando l'orologio che un po' ci siamo quindi chiedo ad Andrea e a Carmine se hanno qualcosa da chiedere ancora Mattia? No, credo di no Forse la domanda è vorresti cambiare il tuo job title in DevX Engineer? Forse sì No, no Una roba che mi sento io di aggiungere rispetto alla domanda che ha fatto Carmine prima su come si diventa DevRel Di fatto, ed è molto simile a come si diventa software engineer in generale, almeno nel mio caso Io non penso di esserci diventato ma è una roba con cui mi identifico tanto Io e il fatto che io sia qua lo testimonia purtroppo questa passione per spiegare le cose alla gente Che sia che cos'è un DevRel, che sia come fare le cose con le API di Google Che sia andare a parlare ai meetup, che sia spiegare ai bambini come si gioca a calcio A me piace pensare che questa cosa sia perché mia madre faceva l'insegnante, mio nonno faceva l'insegnante, mia nonna faceva l'insegnante Quindi un po' ce l'ho nel DNA e sono di quei rompicazzo che ti devono spiegare come funzionano le cose E se io non facessi il DevRel probabilmente farei una cosa simile con un titolo diverso Quindi sì, potrei chiamarmi DevEx Engineer ma alla fine farei quello che ti spiega le cose Forse più DevEx Relationship Cercando...

Relax Relaxionship No, io credo che di titoli forse ne abbiamo anche troppi alla fine Volevo chiudere facendo una domanda Mattia Mi è venuto in mente guardando le cuffie che porta, che mi piacciono Eh, posso dire il brand, sono molto belle, sono un evangelist, ne ho due paia e le ho ricomprate e sono molto fighe È un bel gancio per il paese dei balocchi anche Esatto, però io voglio chiudere questo episodio non dimenticando che tu hai fatto parte del mondo della musica e del mondo dell'organizzazione delle feste, che è una roba che un po' condividiamo noi due E ho fatto anche il giornalista musicale che è quello che ti spiega la musica E lo fai ancora oggi Però quello che voglio chiederti è il fatto dell'organizzazione degli eventi, essere presente a eventi, feste notturne, creare relazioni, in quel mondo Ti è servito, hai preso qualcosa da questa esperienza? Sì, allora tieni conto che adesso è un momento storico un po' stronzo nel senso che prima nella mia vita precedente a Google noi facevamo dei workshop in cui giravamo per il mondo, di fatto per gli uffici di Google La gente del posto veniva in ufficio da Google, mangiava come i cinghiali e passava una giornata a sentire me e il mio team che gli spiegavamo all'epoca perché dovevano migrare all'EPI Nuova, tra l'altro E di fatto quello era ne più ne meno che organizzare un evento in cui io anziché mettere i dischi ti raccontavo perché l'EPI Nuova era una figata E poi mettevi i dischi come fatto a God of Motion No, all'epoca non lo facevo come fatto a God of Motion ma se avessi potuto l'avrei fatto volentieri Però sì, c'è una grossa componente All'epoca poi ero l'ultimo degli strozi del mio team, quindi non lo facevo ma non avevo un ruolo organizzativo all'interno della gestione dei workshop però semplicemente uno che andava lì e faceva le presentazioni Però la parte di dire sto in un posto, sono se vuoi l'host dell'evento e quindi nei momenti morti dell'evento in cui non c'è nessuno che fa una presentazione la gente viene da te e ti chiede cose, magari non ti chiede i free drink ma ti chiede ho questo problema con l'EPI e come faccio a risolverlo è molto simile, c'è un'ampia sovrapposizione, solo che lì i free drink non te li chiedono perché si mangia e si beve tantissimo gratis pagato da Google ma credo che se ci fossero stati mi avrebbero chiesto anche i free drink o il brunchlet per un privé o queste cose qua Quindi sì, mi ha aiutato Comunque è un posto in cui sei circondato da sconosciuti che però conoscono te o che vogliono qualcosa da te e devi un po' per quanto sia difficile per me perché sembro una cazzata ma sono tendenzialmente una persona introversa devi riuscire a farlo, devi parlare con la gente e quel giorno lì arrivi alla fine della giornata che sei da buttare nel cesso e non vorresti mai più parlare con nessuno ma è molto simile in quel senso Sì, guarda ho riconosciuto le stesse dinamiche quindi abbiamo spottato gli stessi punti di intersezione Tra l'altro mi manca tantissimo questa cosa dei workshop, io mi scoccio un sacco che per via della pandemia non li stiamo più facendo A me manca anche tutta la parte dei free drink però quella è la vecchiaia che mi ha portati via Ma hai meet up a Milano? Ci saranno qualche meet up? Sì sì, anche quelli però sono un po' rilento poi vabbè col fatto che adesso sono un padre di famiglia, sera vado a letto presto E siccome la sera si va a letto presto io direi che possiamo accompagnarci all'uscita del nostro bar Ma prima di accompagnarci tutti insieme all'uscita e di passare lo straccio al bancone ci sono due momenti che non possiamo saltare Il primo è il momento nel quale ringraziamo chi ci sostiene, Gitbar ha eliminato le pubblicità, si sostiene in modo del tutto autonomo Quindi oltre a mettere il nostro impegno ecco ci mettiamo anche un po' di nostre pecunie per fare in modo che questa macchina Continui ad andare e che possiate sentire un episodio nuovo ogni settimana E questa cosa riesce a succedere perché ci sono delle persone che ci prendono sulle spalle Che si prendono non necessariamente in serio anche incredibilmente, esatto, e questo è forse più faticoso anche che fare la documentazione La donazione Ma ci sono delle persone che si prendono carico di questi episodi e ci sostengono con una piccola donazione Questa settimana abbiamo Fabio Marzotti che ci invita a tre birre Bravissimo Fabio E noi queste tre birre ce le beviamo alzando il calice in aria e brindando alla salute e alla felicità di Fabio Detto questo è arrivato il momento tipico e topico di Geekbar Il momento in cui i nostri guest e i nostri host condividono con voi un libro, un talk, un video, un film, un vino Qualunque cosa possa essere interessante e possa davvero aver senso condividere appunto con la community e con gli ascoltatori di Geekbar Quindi prima domanda a Mattia Hai qualcosa per noi? E con tu con il paese dei balocchi Ah il paese dei balocchi Allora avevo un balocco che mi sta estremamente a cuore ma poi Andre me ne ha fatto venire in mente un altro che quindi dirò per primo E' un sito molto carino che si chiama AIP.DEV dove AIP sta per API Improvement Proposals ed è praticamente una serie di guidelines scritte da Google Su come disegnare un API E' una roba assolutamente di DevEx e sono delle pratiche regolette, coordinate e divise per argomento che ti dicono per esempio quando devi usare GET in un'API HP Quando invece devi usare POST o quant'altro O come dare i nomi alle risorse o come fare le cancellazioni degli oggetti o piuttosto che i soft-delete e queste cose qui E sono appunto una serie di guidelines su come si disegna una bella API in modo che sia ergonomica E tra l'altro il vantaggio è che essendo di fatto idealmente uno standard se in un mondo meraviglioso tutte le API del mondo seguissero IP Sarebbe estremamente facile per gli sviluppatori perché tutte le API si comporterebbero nello stesso modo E ovviamente siccome il mondo non è il mondo ideale l'API di Google Ads ha un IP da solo Perché il mondo è cattivo Esatto, perché comunque gli sviluppatori in qualche modo dovranno pur guadagnarsi il loro stipendio su data Al suo punto l'intelligenza artificiale ci ruberebbe il lavoro troppo in fretta E questo è un bellissimo gancio per il mio secondo balocco che è un balocco di intelligenza artificiale L'aneddoto del caso è che c'è un tizio di cui non ricordo nemmeno il nome ma è un tizio di cui ho molta stima Che ha chiesto al chatbot di intelligenza artificiale della concorrenza Mi inventi, io sono un appassionato di Sudoku, mi inventi un gioco che non esiste ed è simile al Sudoku E hanno fatto un po' di avanti e indietro E il chatbot della concorrenza gli ha inventato questo gioco e poi hanno fatto anche un po' di avanti e indietro per decidere come chiamarlo E questo gioco si chiama SampleIt Perché devi completare, quindi la parte di complete è quella, devi completare una griglia con le somme dei numeri E si chiama SampleIt per via di questo Ora il mondo del 2023 è un mondo in cui la tecnologia ci permette di fare tantissime cose Tra cui fare scraping del sito con tutti i SampleIt, metterli in un PDF e pubblicarci un libro su Amazon Che è la cosa che ho fatto io Quindi se voi cercate il libro dei SampleIt su Amazon è come un libro di Sudoku Ma con i SampleIt e di fatto l'autore, l'autore per modo di dire per lo scritto 10 righe di test caffè Sono io e mi arrivano dei soldi E mi sembrava assolutamente opportuno metterlo come balocco della mia puntata Andrea? Ma è fantastico Ah stai ancora pensando a quello Genio, cioè genio proprio Tutto in caps lock proprio Sai quando ti dicono adesso che ci sono i chatbot la gente non lavorerà più Io ho fatto scraping di uno che ha fatto il lavoro con il chatbot Sono ancora più pigro, non mi sono neanche fatto il culo di chiedere le cose a chatbot Chapeau Io ho qualche perplessità ma le condivido con te in privato A livello etico diciamo che è molto grey area Dicevo, anche io un balocco, non è qualcosa che ci entra minimamente con il DevRel né con la DevX, anzi forse è qualcosa che ricade in un area che forse non è mai stato toccato minimamente da un balocco Sto parlando di un browser Ma come, ci consigli un browser? Sì, io vi consiglio un browser che si chiama ARK, non è la distribuzione Lo uso tutti i giorni Ah grande, non lo sapevo, quindi è stato già citato? Sono in ritardo? Mi sa di sì, mi sa di sì che l'ho portato in un balocco Allora niente, lo ricordiamo perché gli vogliamo bene Sì però spiega perché è figo Ci stavo arrivando, prima che mi bruciassi, mi sparassi sul petto Un fucile a cannemozze, mi sento proprio la rosa qua davanti Sono sotto l'effetto dei medicinali, sono giusto di canto Niente, è un browser che rivoluziona completamente il concetto dei tab in alto Andando a snaturare tutte queste abitudini che noi abbiamo E spostando tutto questo sistema di navigazione, clasterizzazione, categorizzazione Della qualunque che noi vogliamo bookmarkare o che stiamo navigando in questo momento Da top lo sposta semplicemente a left Quindi cambia completamente la nostra user experience Sto cercando di utilizzarlo da settimane perché l'idea mi piace tanto Ma sono sempre molto attaccato alle radici dei vecchi abitudini Quindi molto spesso riapro Google Però quando mi ricordo lo riapro e ci riprovo Quindi quello che vi dico è provatelo, dategli una chance È ancora sotto invitation, quindi il mio balocco è un link Esclusivo Esatto, che vi permetterà di scaricarlo Purtroppo ne posso staccare solo uno Visto che può farlo anche Mauro, aggiungeremo un link anche da parte sua L'idea che mi piaceva dietro a questo è che poi voi a vostra volta I due fortunati che staccheranno il download per la prima volta Potranno condividere il proprio all'interno del nostro bellissimo gruppo Telegram In modo da far partire questa cosa che non vuole essere una cosa di piramidale Perché non ci facciamo i soldi di nessuno Ma è soltanto a livello di condivisione, di community Per dare a tutti la possibilità di provarlo e dargli una chance Arc, il primo browser ponzi Come ho sentito che l'armi No no, nel senso, con queste prevenzioni sono stato iniziato Più di dieci anni fa a OneCoin Perché io non conoscesse, andasse su Google a vedere che cos'era Beh, anche Gmail iniziò così Assolutamente sì Io ho ancora l'indirizzo email di Gmail da un invitation in beta Anch'io Ho ancora quello Allora, in realtà, questa notovoce di Gmail mi avete spoilerato il balocco Che cazzo La serata degli spoiler Il tuo balocco era Gmail No, il mio balocco era AI, che sto provando da qualche settimana Ah, il caricolo di DHH Esatto, che sto provando da qualche settimana L'unico client mail altamente opinionato Come il suo fondatore Assolutamente Diciamo che tra fare Rubio Race, Ledger's Stylized Doctrine E andare su AI Cioè, effettivamente il passo è breve Ma in realtà l'ho voluto provare perché avevo letto un thread su Reddit Dove effettivamente c'erano diverse persone che lo avevano provato Ed erano riusciti ad ottenere, diciamo, un flusso di email un po' più ragionato Io l'ho voluto provare perché la mia email attuale fa schifo Ok, nel senso, è una email che ho usato da tantissimi anni Quindi il 90% di le cose o è spam o è newsletter A cui non voglio più essere iscritto E quindi volevo provare, perché promette e in buona parte mantiene Di farti focalizzare solo sulle cose che ti interessano e che tu apri Praticamente, l'ho riassunta veramente male Mi paga poco, si può anche provare Ed è possibile utilizzarla anche con lo proprio domino custom Potrei anche semplicemente cominciare facendo un account AI E facendo il forward delle email, semplicemente se vuoi ritrovare Secondo me vale la pena provarlo Sono un fan delle robe che fa di VHH, ma non tanto Ad esempio, ho provato Basecamp e non l'ho capito Non l'ho capito, onesto Non ho ancora capito esattamente che cos'è Hai provato anche a non scrivere gli unit test? No, ho provato Basecamp perché mi hanno detto che è meglio di Trello Io non ho visto né Trello né Gira dentro Basecamp Quindi non ho la minima idea di come deve effettivamente essere utilizzato Quindi niente, se volete provarlo, provatelo Secondo me può valere la pena Non ho nessun referral da darvi Ho già preso il bonifico perché ho fatto questa sponsorizzazione qui Ora arriva sul conto lituano, l'EU Tra l'altro, parlando di gmail e di client di posta che te la fanno vivere meglio Vorrei fare un momento di silenzio in memoria di Inbox che ci guarda da lassù Ed era bellissimo Inbox era il client di posta alternativo di Google Che è stato ammazzato da poco Quello che aveva come obiettivo la empty list o come cavolo lo chiamava Zero Inbox tipo quella roba lì Tutto ora dentro Google c'è un grosso frangente di vedove di Inbox Che periodicamente dicono di accendere Molto più di qualunque altro prodotto Credo che Inbox e Google Reader siano i due che hanno più vedove Ma Google Plus a me piaceva Adesso faccio il disclaimer In quelli che dicono le opinioni qui esposte sono le mie Non sono quelle della Zero, piaceva solo a te Sei il Rosa Chemical dei social network E Google Plus era il tuo fetish Carmine Faccio un sacco con il Plus Esiste ancora Blogspot? Google Ads Developer Blog è su Blogspot Ok, ok, fino Io, che balocchio Fatemi pensare un attimo Abbiamo parlato di Google Abbiamo parlato di Developer Advocate DevRel e quant'altro Abbiamo parlato di team di Chrome Anche se Mattia Poici ha detto che ha un aneddoto su quel team Ma non ce l'ha detto Un aneddoto su Jake Archibald, se vuoi te lo racconto Lo diciamo in chiusura Chiudiamo con quello Così teniamo live la gente attaccata all'episodio fino alla fine Oppure facciamo cliffhanger e lo mettiamo nel prossimo episodio Bravo Mauro Bravissimo In quel team c'è anche un signorotto che si chiama Eddie Osmani Questo signorotto È un coglione È il Chiara Ferragni dei DevRel Praticamente più su Twitter che a casa sua immagino Però ha scritto un libro, se non lo sapevate sapetelo Perché tipo l'ha tweetato avantieri E io da buon fan di Eddie Osmani l'ho già comprato Mi arriva questo fine settimana E si chiama Software Engineering The Soft Parts È molto bravo a dare i titoli E secondo me c'entra parecchio con questa roba Con il discorso che abbiamo fatto Rockford li ha già fatto causa perché è una copia del titolo del suo libro Non ne ho minimamente idea È bellissimo, JavaScript The Hard Parts Ah sì, hai ragione Forse è una citazione Sì è assolutamente una citazione Però ecco, mi arriva questo weekend Quindi ci butto un occhio questo weekend e poi vi saprò dire di più Però è senza dubbio interessante Voglio però anche io portare un altro balocco di riserva Mattia ha citato le intelligenze artificiali Proprio oggi ascoltavo un episodio Bello bello bello Prima o poi verrà qua su Gitbar Del podcast Data Nightmare Di Walter Vannini L'episodio si intitola L'economia politica di chat GPT Recuperatevelo, è fortemente opinionato Vannini è molto pungente quando dice le sue cose Però secondo me è una di quelle cose che va ascoltata Ehh, detto questo Detto questo ragazzi io non sto più capendo niente perché il dolore sta risalendo Vi do appuntamento alla prossima settimana ringraziando Mattia, Andrea e Carmine per essere venuti Grazie di cuore, è stato un super piacere bere una birra con voi raga Grazie mille anche a voi e a Mattia specialmente che ci ha illuminato un po' su questo ecosistema E movimento Mi piacerebbe soltanto ricordare una cosa che credo sia stata citata soltanto una volta in un'ora e cinquanta minuti e ventisette secondi Il gruppo Telegram Bravissimo E' vero, dovremmo nominarlo più spesso Comunque in realtà come al solito sono io che ringrazio voi perché mi date la possibilità di spiegare le cose che è la mia passione principale Allora l'aneddoto è che nel 2018 appunto quando sono entrato a Google a Londra Jake Archibald che per chi non lo conoscesse è un developer relations engineer molto famoso Uno di quelli che stanno veramente più alle conferenze che a casa loro e che fa delle cose fichissime nel team di Chrome E' super esperto di web performance e di far andare forte i siti Stava seduto due scrivanie di trolla mia e io lo conoscevo di fama l'avevo visto parlare a diverse conferenze E a un certo punto il mio vicino di scrivania nonché mentore all'epoca nonché appunto developer advocate che supportava Alessio in Adespresso Mi diceva vabbè dai ti faccio fare un giro qui attorno ti presento alla gente che sta seduta qui attorno Quindi faccio il giro, tutta la gente mi dice dai io mi chiamo così cosà, faccio questo questo, basta Arriviamo da Jake Archibald e mi fa ciao io sono Jake, gli faccio sì lo so con gli occhi a corrucino, lo so che sei Jake E io all'epoca ero letteralmente l'ultimo arrivato nel team e lui non aveva nessun obbligo nei confronti, nessun dovere nei miei confronti Ma mi ha tenuto lì 40 minuti abbondanti a raccontarmi la rava e la fava di quello che stava facendo Era una roba fighissima su dei formati di compressione delle immagini diversi Credo che stesse facendo una comparazione tra tipo JPEG, GIF e Brotli su quale andava più forte Super complicatissimo, mi fa no perché vedi adesso ho scritto questo tool che fa i paragoni in automatico E insomma mi ha raccontato la rava e la fava di cose, mi ha attaccato un pippone allucinante che non finiva più su una roba fighissima Mega interessante di cui io non ci ho mai più lavorato, non ho mai più avuto a che fare con Jake perché poi lui si è spostato di scrivania Quindi non ci siamo di fatto mai più parlati, però di fatto credo che a un certo punto lui come me non fosse in grado di non spiegare alla gente le cose Mi ha sempre fatto un po' ridere nel senso che cazzo c'è, tu davvero attacchi i pipponi pure alla gente in metropolitana evidentemente Ma tu non ti spieghi le cose che fai e un po' però mi ha fatto dire guarda che bravo questo che fa queste cose fighissime e te le spiega così bene Tra l'altro con questo fuoco negli occhi, perché tanto c'è, io non so se voi l'avete mai visto parlare Jake Ma è uno che veramente ha il fuoco negli occhi e lo fa venire a te e secondo me in quello lui è bravissimissimo Io ho letto un post sul blog in cui lui fa la comparazione dei siti delle scuderie di Formula 1 Io non faccio più performance dei siti e la Formula 1 mi sta sul cazzo Eppure quei post li li ho letti come se fossero un romanzo di Stephen King perché lui è davvero molto bravo a spiegare le cose Fine dell'aneddoto Sottotitoli e revisione a cura di QTSS.