Bene e benvenuti su Gitbar, 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, tutto quello che non è scrivere codice ma è mischiare codice e gente e per farlo ho due amici con me nonché ammutinati, nonché costo di Gitbar, nonché colonne portanti del nostro podcast abbiamo Andrè e Mattia.Ciao ragazzi, com'è? ciao caro ciao ciao sempre un piacere sempre intanto andrei almeno alla birra io avrei finito di bere le proteine ma infatti apro una piccolissima parentesi io sono qui non perché sono esperto in 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 il sfatto totale allora arriva una bella notifica o stasera si regista l'episodio con mattia su The Brat, 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'è The Brat.Guarda quanto è bello andare al bar dopo una giornata del genere.Esatto, quindi saluta.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 miei amici, così cos'hai, mangiare un piatto di verdura grigliata in posti dove probabilmente nessuno li ha mai chiesti tipo senza fare product placement mi immagino una scena di tu al mcdonald da burger king King, tuo figlio e gli amichetti che si strafogano e tu le piatture grigliate di plastica.Al Mac 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è c'era tipo il coltello nello stomaco e quant'altro ti vuoi proprio male però funziona dai beh però il controllarsi così ci porta a diciamo spingerci sui oltre i nostri limiti no? quindi è una sfida è una sfida importante quella che che Mattia sta facendo è che io non riuscirei mai a fare per quello che nel giro degli ultimi tre anni ho preso tipo 20 kg.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.Io ero di cattivo umore quindi mangiavo tantissimo.Tra l'altro è abbastanza comune che chi entra a Google prenda una decina di chili appena entrato proprio perché c'è cibo dappertutto.LM: si mangia bene anche a casa tua? Cioè sei deciso di fare lo stesso lavoro ora? DLL: però devo cucinare! LM: 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ì l'ufficio era semi deserto c'erano tre piatti giganti di fette di pane e nutella già fatto avrei potuto mangiarli tutti.Lì veramente mi sono detto ok se riesco a non mangiare questa roba sono veramente diventato un maestro Jedi della Dio.Ok mister 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 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 comunque noi siamo degli engineer, quindi siamo gente che sa scrivere codice, 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.Dal mio punto di vista io lo faccio per per le 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.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 P0.Eppure è così particolare, è strano vedere che in realtà esiste una connessione in quello che fai, no? Così potente col business, spesso il developer advocate e il team di DevRel è sempre un po' lontano dal business, 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.Ma allora adesso ti ti droppo il primo dipende della giornata.Nel senso che dipende tantissimo da qual è il business in questione, nel senso che per per dirti, all'interno di Google stessa, che poi di fatto ha imparato mettendoci le mani, è 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, 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 no? In modo da proprio fare un percorso.La tua giornata dovendola organizzare...Allora anche lì è una delle cose che mi piacciono tantissimo di questo lavoro è estremamente vario dipende tantissimo dipende da 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 Montenvio, 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à letto diverse volte, ma forse vale la pena spiegare un po' cosa intendo per...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, puoi farti il sitino per venderlo 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 a 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 e 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 in 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 DevRel.Dimmi, Andre.Curiosità riguardo a questo, diciamo, particolare tipologia di giornata lavorativa.Quindi, diciamo, tu oltre a supportarli, aiutarli, utilizzare le nuove API o a fare trovare bug e aiutarli a utilizzare le API, in qualche modo prendi anche dei feedback sulle esigenze dei partner/ clienti quindi in qualche modo sei anche una chiave importante sul peso della roadmap o la messa in priorità dei task da assegnare agli ingegneri.Assolutamente sì, tra l'altro molto concretamente il caso di Wix è un caso emblematico nel senso che Wix fa un sacco di richieste all'API, fa un sacco di campagne, fa un sacco in definitiva di soldi per cui quando quando apro un bug o apro una feature request se io ci scrivo dentro "questa cosa serve a Wix" la fa automagicamente 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 spring planning o grooming e 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.LM: Tutto questo viene fatto sempre, viene ingaggiato oppure piazzi delle call di routine settimanali, bisettimanali, mensili? perché immagino che tu hai citato due grossi parte però ne curi decine e decine.Poi 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.- 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, 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 "sì sì va tutto bene, siamo sulla roadmap, siamo a posto, non ci serve supporto".A un certo punto ci siamo detti "vabbè, senti, diciamo che ci sentiamo ogni due settimane".E oggi ho fatto una call bisettimanale con loro e anche lì è stata "sì sì, 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 esempio questo partner qui sta per lanciare la beta nella loro integrazione e quindi giustamente sono in fase di testing molto intensivo e scoprono cose di giorno in giorno e oltretutto è capitato che hittassero dei limiti o dei bug dell'API o di cose che non si possono fare e che vanno risolte abbastanza in fretta.Sono lì per lanciare la beta.Quindi dipende.Poi oltre a questo, è verissimo anche quello che dici tu, 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 e 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 qui 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 questa cosa...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ì, 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.Poverini.Shopify è un altro nostro partner, è un altro di quelli che ha il developer ad who che ci lavora solo Shopify.Tra l'altro, a proposito di questo, 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 avremmo visto il riso tutto il giorno.Vero.Ale, sì 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 itterazione tu nel tuo lavoro hai individuato uno slice molto preciso ed è uno slice che possiamo dire centrale no? Prima del deploy, prima del rilascio, beta applicazione e nell'evoluzione dell'applicazione.Questa è più o meno la parte che vai a coprire.Nel vostro lavoro, è 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 questo modello organizzato ed azionale? Allora è una domanda interessantissima che io stesso ho fatto il mio manager tempo fa perché 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, 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 Jco 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 c'è un...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 "guarda 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 anch'io.Cosa che però è caratteristica solo di Ads.LM: "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 diciamo il proprio servizio, prodotto, API, quello che è.Quindi non stiamo parlando di qualcosa che sia di fuori dall'ecosistema di Debrel, 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 giorni in cui interveniamo.Sì e poi secondo me esiste anche un'altra differenziazione.Ci riflettevo prima 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 che 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 dev rel di un prodotto e anche là si possono fare delle ulteriori differenziazioni ma ci arriviamo dopo no, 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 il il tranello e dietro l'angolo perché davvero basta veramente poco per diventare autoreferenziali? Beh sì perché scusami dal dal mio punto di vista di esterno rispetto alla tua società di consulenza la percezione che ho io è che il modo in cui fa Debrel questa società è molto per una questione di branding perché di fatto è marketing, è dire ok noi siamo attenti alle esigenze 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é 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 dev rel, anche se stride però è fare dev rel, stride perché in realtà siamo già nell'ambito magari della dev ex per esempio nella società dove lavoro non esiste un team di dev rel esiste un team di dev ex ed è colui che si occupa di curare ambe due 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 no? dirlo a me! oh scusa scusa Andrea ti ho fregato! la mano alzata da un po' LM: più che altro, oltre a aver lanciato la manina perché volevo fare un'osservazione, nell'ultimo ragionamento che facevi Mauro, mi hai proprio bruciato una domanda che però segnala che davvero qualcosa mi interessa.Però se siete d'accordo ci tornerei dopo su queste dei confini tra Devrelle e Devix, ma farei un passo indietro su quello che invece discutevamo prima nel senso di azienda che fa tanto devrel, persone che fanno tanto devrel, allora voi che diciamo l'avete visto un po' più da vicino, 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.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 open source eccetera eccetera della sua community, quanto è complicato fare in modo che non sia personal branding ma che sia DevRel? E' 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 e vuoi metterti in mostra.Poi sai è 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 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 autentesmalizziare.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 ok? E quest'azienda faceva PR, aveva delle persone che facevano PR, non erano strettamente dei Vrel ma fondamentalmente in un altro dominio quello facevano.Erano qualcosa Vrel.Esatto, e quindi vi posso rispondere da imprenditore.Cambia tutto con l'approccio dell'azienda, è 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 O è un'azienda sprovveduta, ok? Oppure si trova in una condizione di win win.Perché? Perché magari dà talmente tanti benefit nel senso largo del termine a questa persona.Ok? 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 che con la persona alla fine diventa uno a uno con l'azienda.Ecco.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 qualche quando mi trovai davanti a questa questa situazione fu quella di distribuire la responsabilità distribuendo la responsabilità tu stai distribuendo la visibilità a un costo questa azione non è gratis però nel contempo ti ha 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 lavoro di un team.Terzo crei una serie di policy per cui si sostituisce noi al io detto tra noi tra io, Andre, Mattia e i 1500 ascoltatori che ci stanno sentendo e il gruppo telegram esatto.Tappate un attimo le orecchie ragazzi del famiglio che rimanga tra noi.Detto tra noi una fatica, una delle fatiche più grandi che ha 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 un APR 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? La battuta è stata quella no? Casse il mago Telma? Però ecco lo spingere ad ad adottare questo approccio fa sì che insomma ci si protegga anche perché in un modo o nell'altro il DevRel, DevAdvocate 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 è a una certa influenza 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, 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 in molti 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 advocate con i loro partner.Un po' per vedere com'è fatta l'interazione, ma un po' per appunto, per imparare il tono di voce, per imparare qual è il modo Google di comunicare con gli sviluppatori, 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 centocinquantamila e passa persone e io sono l'ultimo degli stronzi e quindi nessuna maniera 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? 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, resti tranquillo.- Questa era facile, questa è la domanda.Mattia è un po' come 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 KPI dai!" La risposta è molto è molto grossa ed è molto dipendente nel senso che appunto uno dei modi che hai per misurare le performance di un developer relations engineer è l'impact 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 e 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 sculato e aver beccato della gente bravissima che non ha mai avuto nessun problema e bam funziona tutto e tu non hai fatto niente e sono tutti contenti.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."Non chiamarmi arrogante perché ciò che sto dicendo è vero.Penso che sono uno speciale." I ragazzi giocano bene, l'allenatore è bravo.I ragazzi giocano male, l'allenatore è scarso.E tu non hai fatto nulla di diverso.I progetti vengono consegnati in tempo, devrà il bravo.I progetti vanno in ritardo, devrà il coglione.E tu non hai fatto nulla di diverso.Oltre a questo, però, 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 è è uscita una nuova feature del prodotto su cui lavori che può essere l'API di Ads, ma anche, che ne so, 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.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.Devi imparare un po' a essere bravo e paraculo tu a spiegare a chi ti sta misurando, che 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 Carmine.Buonasera, buonasera.Mi siete sentite? Sono online.Sei raffreddato.Sono molto raffreddato, ho l'influenza e in realtà sono riuscito a connettermi a più a colpo perché sono con Windows stasera.Non dovresti dirlo questo.Non ho avuto nessun problema di sorte.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 che non so in realtà se avete già fatto questa parte, la tagliamo.Che relazione c'è tra l'essere un devrelle e un developer advocate? Perché spesso anche online l'ho vista intrecciata, come cose, 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 sto 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 e nel 2018 ero un developer advocate e adesso sono un developer relations engineer.Sostanzialmente è la stessa cosa diciamo.Ma i nomi li sceglie HR o marketing? Infatti! Che interessante! interessante, ti sceglie Bard no questa era una battuta però ecco abbiamo parlato di KPI proviamo a visualizzare l'attività del Devrel immaginiamo un triangolo piace sempre a tutti immaginare il triangolo nella parte alta ci mettiamo l'area di engineering il punto di engineering un po' come i grafici dei calciatori su FIFA erano che avevi quelle.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, no? Cioè quanta gente è tirato dentro, ma le KPI variano anche nel spostarsi nell'indirizzamento dell'attività di DevRel.È una domanda più difficile, la più difficile da fare, però in realtà l'ho capito.C'è un gradiente di ruoli all'interno di DevRel.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 relationship engineer di Google il nostro lavoro e quindi i nostri KPI e il nostro triangolo è assolutamente "choose your own 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, per cui c'è nello stesso team e con lo stesso job title, hai persone che fanno contenuto su YouTube, 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, e serviva qualcuno tra il team di engineering e noi che mettesse in piedi una suite di benchmarking delle performance dell'API e è 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 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ù.e 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.E Mattia fa l'integrazione dell'EPA in Turbo Pascal.Manco per il cazzo.Già faccio C#, - Non parliamo di PHP per favore - No, però per rischiare, quando stavo a Londra mi è successo, e credo di averlo già raccontato in qualche momento, di stare al podcast, stavo facendo one to one con il mio manager e a un certo punto lui mi fa "Ma tu 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 fidele fiori di azio.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 diciamo come viene visto questo in Google, ma immagino che anche tu facendo questo ti sia documentato in letteratura, abbia letto cose tempo fa, in un qualche altro episodio, se non sbagliare, che anche consigliate una newsletter riguardo a questo tema, che ovviamente mi sono iscritto immediatamente.LM: Divelo paravocalos.esatto e quindi ero davvero interessato a le possibili intersezioni e sfumature tra il discorso DevRel e DevEx, dove ovviamente ipotizzo, la butto lì, che ci sono degli ambiti dove probabilmente sono molto simili altri ambiti che sono proprio due cose completamente differenti, però 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 sfumatori 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.Il sapere che c'è qualcuno là che quando se hai una partnership e se sei sul prodotto giusto quando hai un problema tu tiri su il telefono e dici "Ehi, vello 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? 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 sono 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 Devix ci si è sempre fermata su questa cosa che magari aveva senso solo se l'azienda era abbastanza strutturata era 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 un'altra persona, di una persona che fa anche altre cose.Per cui tu, per esempio, potresti essere uno sviluppatore che scrive il codice dell'API, 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 Debrel.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/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, la tua azienda fa un prodotto che ha come target degli sviluppatori tu fai dev rel in ogni caso non puoi non farlo perché il tuo utente sono degli sviluppatori.Rispetto invece a...- Ma ti...però diciamo sia ora che quando anche nella domanda 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é davvero tante similitudini e tanti stessi concetti stessi gradi di attenzione e focus.Occhio però Andrea, scusami Mattia, quando tu dici "DevX sta dentro l'azienda, deve interfacciarsi con Fori" 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 fanno parte della parte di DevEx devono essere anche una delle componenti che si interfacciano verso fuori.Certo che lo facciamo anche per l'interno tutto questo? Sì, ad un altro aggiungo dell'ulteriore benzina su questo fuoco dicendo che quelli che fanno DevEx 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 stai facendo devrel o devex che dir si voglia.- Vero - Perché alla fine...Vai Mauro perdona - No no vai Andre Andre - No quello che devo dire 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 miglior tempo possibile e nel momento più facilità possibile con meno stress cognitivo eccetera eccetera.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 le quali 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 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 da 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é 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, quindi dopo che hanno fatto il POC delle tue API e hanno visto che funzionano in locale, "works on my computer" e poi bisogna trasformarle 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 gracio per un addeduto fantastico.Vi ho accennato prima al fatto che a un certo punto l'EPI di Azz ha avuto dei problemi 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, noi 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" e gli stavamo addosso tantissimo perché migrassero all'API nuova che all'epoca era in beta.Quindi spingevamo anche un po' a dirgli "usate le API nuove, è bellissima e nel frattempo aiutateci a farla meglio".A un certo punto, a gennaio del 2019, rilasciamo la 1.0, genero la availability e posto 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 le API nuove, è 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 le API nuova e a un certo punto poi andava effettivamente più forte e abbiamo detto "dai, facciamo che ritorniamo dove ci eravamo lasciati qualche mese fa" e quindi potete tornare a migrare alle API nuova e le API vecchie le 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 alle pià in 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.è saperti mettere nei panni della persona con cui lavori, è 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 con 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 capire esattamente che cosa serve loro e capire perché serve loro e andare poi dal team di engineering a dire "guarda che ha il Wix di turno, serve questa cosa" e loro magari mi dicono "ok dai noi la esponiamo in questa 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 che deve fare, deve scrivere del codice in più perché deve esporre in due poi in poi diversi delle cose che stanno in una tabella sola ma anche nei panni dello sviluppatore che deve 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.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 skill set 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.Fai più di questi colloqui, ma in ognuno di questi tu hai due domande.Una domanda è la classica coding question da colloquio tecnico.E può essere, che ne so, fai...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 appunto 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 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é diciamo una domanda molto simile la faccio diciamo in ottica di colloquio per ragazzi per il mio team di DevEx.Quindi davvero mi viene da sorridere.Ma che ci sta nel senso è super interessante tutto questo perché fa parte di tutte le possibili sfaccettature e punti di approccio che alla fine vanno in direzioni molto simili e bisogno di persone con skill o soft skill e 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 saper 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 perché 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 Ads 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 Matti 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é anche 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 il 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 i colloqui, quando crei un contenuto di qualunque tipo, può essere codice ma anche no, è qual è, non so come si dice in italiano, l'intended di questo contenuto.Qual è il pubblico di riferimento, il lettore di riferimento? Per chi stai creando questo contenuto? Sì, più o meno il target, 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 Salga 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 all'interno, 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 Mockey 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à coderview uno molto puntiglioso? e questa roba, questa cosa influisce.Di fatto mi ha aggiunto un dipende in più quando scrivo del codice.Beh siccome non lo dico mai a Marta Anzio...E tu schiessi l'uomo del dipende! Però vedete, questo lo dico agli ascoltatori, Martia è una di quelle poche persone che inizia le frasi col "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 so, non 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 avessi 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ù E' interessante soprattutto perché ci sono diverse variabili nei progetti open.Primo 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 developer relations engineer è la gente di Spring.perché io li 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, sicuramente c'è della gente che lavora Spring e fa dev rel 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 detto il giorno dopo dell'equinozio insomma.Chiaro io mi riferivo alla primavera non al...No io credo guardando l'orologio che un po' ci siamo quindi chiedo ad Andrea e a Carmine se hanno qualcosa da chiedere ancora a Mattia? No, credo di no.Forse la domanda è vorresti cambiare il tuo job title in dev x engineer? Forse sì.No, no, no.No, una roba che mi sento io di aggiungere rispetto alla domanda che ha fatto Carmine Carmine Primas 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 l'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.Se io non facessi il devrel probabilmente farei una cosa simile con un titolo diverso, quindi sì potrei chiamarmi dev ex engineer ma alla fine farei quello che ti spiega le cose.Forse più "The Vex Relationship".Cercando..."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 cuffia che porta che mi piacciono.Eh posso dire il brand sono molto belle sono un evangelist ne ho due paia e le ho ricomprate 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 no? - 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 in uova tra l'altro e di fatto quello era né più né meno che organizzare un evento in cui io anziché mettere i dischi ti raccontavo perché l'epi nuova era una figata e poi mettevi dischi come fatto con emotion.No, all'epoca non lo facevo come fatto con emotion ma se avessi potuto l'avrei fatto volentieri però 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, ero 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 e magari non ti chiede i free drink ma ti chiede "ho questo problema con l'API, 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 Fair Drink o il brunch club per il privé o queste cose qua.Quindi sì, mi ha aiutato.Comunque è un posto in cui sei circondato da sconosciuti che però conoscono te o vogliono qualcosa da te e devi un po' per quanto sia difficile per me perché sembra una cazzata ma sono tendenzialmente una persona introversa, devi riuscire a farlo, devi parlare con la gente, 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 di free drink però quella è la vecchiaia che mi ha portati via.Ma hai meet up a Milano? Ci saranno qualche meet up? Sì sì no no sì sì e 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 ci prenderci in serio anche incredibilmente - Esatto, esatto e questo è forse più faticoso anche che fare una documentazione...la documentazione sì vabbè, la donazione *musica* però ci sono delle persone che insomma si prendono carico di questi episodi e ci sostengo con una piccola donazione questa settimana abbiamo Fabio Marzotti che ci invita a tre birre bravissimo Fabio e noi queste tre birre allora ce le beviamo alzando il calice in aria e brindando alla salute e alla felicità di Fabio Dai! Detto questo è arrivato il momento tipico e topico di Gitbar 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 Gitbar Quindi prima domanda a Mattia.Hai qualcosa per noi? Riconduco nel 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.è 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 è 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 una API HTTP, 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, 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 sua.Perché il mondo è cattivo.Esatto, perché comunque gli sviluppatori in qualche modo dovranno pur guadagnarsi il loro stipendio su dato, altrimenti l'intelligenza artificiale ci ruberebbe il lavoro troppo in fretta.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.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 indietro per decidere come chiamarlo e questo gioco si chiama "sample it" perché devi completare, quindi la parte di complete quella devi completare una griglia con le somme dei numeri e si chiama samplit 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 samplit, metterli in un pdf e pubblicarci un libro su amazon che è la cosa che ho fatto io.Quindi se voi cercate il libro dei samplit su Amazon è come un libro di sudoku ma con i samplit e di fatto l'autore, per modo di dire, per ho scritto 10 righe di test caffè, sono io e mi arrivano dei soldi.Mi sembrava assolutamente opportuno metterlo come balocco della mia puntata.Andrea? Ma è fantastico! Stai ancora pensando a quella cosa.Genio, cioè genio proprio.Tutto in caps lock proprio.Sai quando ti dicono "ah 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.Sciapò! Ok anch'io ho qualche perplessità ma le condivido con te in privato.A livello etico diciamo che è molto grey area.Dicevo anch'io un balocco, non è qualcosa che ci entra minimamente col 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.Ci consigli un browser? Sì, io vi consiglio un browser che si chiama ARC, non è la distribuzione...- Lo uso tutti i giorni! - Ah, grande, non lo sapevo! Quindi è stato già citato? - 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 questo momento da top lo sposta semplicemente a left ok quindi cambia completamente la nostra user experience diciamo 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ò ogni quando mi ricordo lo riapro e ci riprovo quindi quello che vi dico è provatelo dategli una chance è ancora sotto invitation quindi diciamo il mio balocco è un link esatto che vi permetterà di scaricarlo purtroppo ne posso staccare solo uno e visto che può farlo anche Mauro aggiungeremo un link anche da parte sua e 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 ti tocca a te? No, no, non ho 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ì.Sì, sì, sì.Assolutamente sì.Io ho ancora l'indirizzo email di Gmail da un invitation in beta.Anch'io.Ho ancora quello.Allora, in realtà, questa cosa di Gmail, mi avete spoilerato il balocco.Che cazzo! La sera mai hai detto spoiler? Il tuo balocco era Gmail? No, il mio balocco era Gmail, il mio balocco era EI, 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 Ruby on Rails, l'agency da Rails.toktoon e andare su AI, effettivamente il passo è breve, ma in realtà l'ho voluto provare perché avevo ho letto un thread su Reddit dove effettivamente c'erano diverse persone che lo avevano provato ed erano riusciti ad ottenere un flusso di meno un po' più ragionato.Io l'ho voluto provare perché la mia mail attuale fa schifo, ok? Nel senso, è una mail che uso da tantissimi anni, quindi 90% delle cose o è spam o è newsletter, a cui non voglio più essere iscritto, e quindi proverei, 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 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.Ho provato Basecamp e non l'ho capito.Ma l'ho capito, onesto, non ho ancora capito esattamente che cos'è.Hai provato anche a non scrivere gli unit tests? No, ho provato Basecamp perché mi hanno detto "è 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, se non mi può valere la pena.Non ho nessun referral da darvi, ho già preso il bonifico perché ho fatto questa sponsorizzazione qui, ora mi arriva sul conto lituano, l'EU.Tra l'altro parlando di gmail e di client di posta che te la fanno vivere meglio io vorrei fare un momento di silenzio in memoria di Inbox che ci guarda lassù ed era bellissimo.Inbox era il client di posta alternativo di Google che è stato abbattuto da poco.Quello che aveva come obiettivo la empty list o come cavolo lo chiamava.Zero inbox tipo quella roba lì.c'è tuttora comunque dentro Google c'è una una grossa un grosso frangente di vedove di Inbox che periodicamente dicono dai ora accendiamo molto più di molto più di qualunque altro prodotto.Credo che Inbox e Google Reader siano i due che hanno più vedove.Ma Google+ a me piaceva...adesso faccio il disclaimer in quello di quelli che dicono le opinioni qui esposte sono le mie, non sono quelle dell'azienda, piaceva solo a te.Sei il Rosa Chemical dei social network e Google+ era il tuo fetish Carmine.Faccio un sacco con il plasma.Esiste ancora Blogspot? il blog google ads developer blog è su blog ah ok ok sì io che balocchio fatemi pensare un attimo allora abbiamo parlato di google abbiamo parlato di developer advocate devrel e quant'altro abbiamo parlato di team di chrome anche se Mattia Pojic ha detto ci ha detto io ho un aneddoto su quel team e non ce l'ha detto.Ah no è vero, no un aneddoto su Jake Archibald se vuoi te lo racconta.Lo diciamo in chiusura allora, lo diciamo in chiusura e chiudiamo con quello.Così teniamo l'hype, la gente attaccata all'episodio fino alla fine.Oppure facciamo cliffhanger e lo mettiamo nel prossimo episodio.Bravo Mauro, bravissimo, bravissimo.In quel team c'è anche un signorotto che si chiama Eddie Osmani.Questo signorotto, a parte che è il Chiara Ferragni dei Devrelle, 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 Edy 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 con questa roba con il discorso che abbiamo crockford li ha già fatto causa perché è una copia del titolo del suo di libro non ne ho minimamente idea.Come l'hai trovato in JavaScript the Art Parts.Ah si si si hai ragione.Forse è una citazione quindi.Si è assolutamente una citazione.Però ecco mi arriva questo weekend quindi io ci butto un occhio questo weekend e poi vi saprò dire di più.Però è senza dubbio interessante.Voglio però anch'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 Vanini è molto pungente quando dice le sue cose però secondo me è una di quelle cose che va ascoltata e buono detto questo detto questo ragazzi io non sto più capendo niente perché il dolore sta risalendo appuntamento alla prossima settimana ringraziando Mattia, Andrea e Carmine per essere venuti grazie di cuore è stato un super piacere bere una birra con voi ragazzi grazie mille anche a voi a Mattia specialmente che ci ha illuminato un po' su questo ecosistema e movimento e mi piacerebbe soltanto ricordare una cosa che credo che è stata citata soltanto una volta in un'ora e 50 minuti e 27 secondi, che è...Il gruppo Telegram.Bravissimo.È vero, è 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 relationship 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, è super esperto di web performance e di far andare forte i siti.Stava seduto, ho due scrivanie dietro la mia, e io 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 "va beh 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'ha, faccio questo questo" basta arriviamo da jake archibald mi fa ciao io sono jake lo so con gli occhi a coruccino lo so che sei jake e io all'epoca ero letteralmente l'ultimo arrivato nel team 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 e 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 e mega interessante di cui io non ho 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 cioè tu davvero attacchi i pipponi pure alla gente in metropolitana evidentemente gli spieghi le cose che fai e un po' però mi ha fatto dire "mica però guarda che bravo questo che fa queste cose fichissime e te le spiega così bene e con questo tra l'altro con questo fuoco negli occhi" e perché tanto cioè 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.Tipo 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 GIT BAR il circolo dei full stack developer una volta a settimana ci troviamo davanti a due birre e combrir repo, parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dev.
