Benvenuti su Gitbar, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.Bene, benvenuti in questo nuovo episodio di Gitbar.Vi è piaciuta la storiella, vero? raccontare i monoripo parlando dei tre porcellini vi ha un po spiazzato in realtà lo ha fatto anche a me una piccola follia che mi è venuta in mente spero ripeto che abbiate apprezzato visto che qualcuno mi ha già scritto nel gruppo telegram lo ricordo nuovamente t.me/gitbar anzi prima di iniziare prima di presentare l'ospite perché oggi abbiamo un ospite speciale direttamente da quella che un tempo si chiamava l'albione no Prima però di presentare il mio ruolo come sempre quello palloso di ricordarvi i contatti.Info che ho c'ho la github.it per le mail @brainrepo su twitter ma soprattutto anche se ma soprattutto non si dice il nostro gruppo Telegram siamo ancora in pochi quindi ricordatevi di iscrivervi prima di Lanciare quel piccolo puntino di pubblicità che mettiamo ogni settimana e che sto valutando di togliere Vi devo anticipare chi sarà l'ospite di oggi.Abbiamo con noi Emanuele Blanco, CTO di Money Farm.Però fermi fermi fermi.Adesso ci fermiamo un secondo e poi ritorniamo direttamente con Emanuele.E' arrivato la rovina! Ciao Emanuele, come va? Ciao Mauro, ciao, tutto bene, grazie.Tu? abbastanza bene.È arrivato l'autunno lì a Londra? Decisamente, io sono in Felpa, la temperatura è scesa tanto, è un po' normale per questo periodo dell'anno, quindi ci sono abituato.Sì, anche perché la mia domanda immediatamente successiva era "ma a Londra esiste l'estate?" Guarda, quest'anno siamo stati molto fortunati, vabbè "fortunati" parola grossa con tutti i problemi del covid, però sai abbiamo avuto un aprile e un maggio veramente fantastici io in dieci anni che sono qui mai vissuto la primavera così forte, l'estate così così però abbiamo avuto due mesi di caldo caldo veramente caldo quindi non mi lamento.E due mesi spero in questi due mesi tu sia riuscito a fare anche un po' di ferie? Più o meno, più o meno.Eh guarda hai già anticipato il tuo lavoro e il tuo ruolo perché quando rispondono più o meno oppure no io capisco già a colpo d'occhio il ruolo.In realtà tu sei CTO di Money Farm.Money Farm è un'azienda che si occupa del wealth management quindi la nostra missione è quella di aiutare gli investitori o comunque le persone, gli individui ad investire proprio risparmi in modo sicuro e senza preoccupazioni.Noi crediamo che le persone debbano gestire la propria ricchezza cumulata nel corso del tempo con facilità e vogliamo offrire un servizio digitale ma anche umano, perché collaboriamo molto con gli ostri investment advisor, abbiamo persone che si occupano appunto di parlare con i clienti, non siamo una piattaforma esclusivamente digitale e quindi vogliamo offrire ai clienti la possibilità di risparmiare e di investire in modo sicuro e digitale senza preoccuparsi offrendo un servizio che sai tempo fa era solo appannaggio di persone molto ricche mentre invece noi vogliamo renderlo disponibile a tutti in modo indipendente quindi senza pressioni da parte delle banche o di istituzioni finanziarie che possono avere di interessi.Insomma una sorta, io lo dico un po' con l'accetta, ormai gli ascoltatori mi conoscono, una sorta di democratizzazione della possibilità di investimento, la semplicità di investimento, qualcosa del genere? Sì, direi di sì.Ok, allora avevo capito bene.Tu la Money Farm sei il CTO.Quali sono i compiti che come CTO quotidianamente devi assolvere? Come CTO sicuramente io mi vedo come parte integrante di due team.Innanzitutto il mio team è il team della tecnologia quindi insomma mi occupo di dare la strategia e di supervisionare tutte le attività legate alla tecnologia, sia in questo sviluppo della nostra applicazione sia mobile ovviamente che web, la gestione dell'infrastruttura, la gestione della delivery, quindi insomma dare aspettative ai nostri stakeholders nel capire come effettivamente realizzeremo ciò che desiderato e quando lo faremo.Gestisco anche un po' il lato IT operations, che da noi vuol dire appunto laptop, stampanti, insomma VPN, soprattutto VPN in quest'ultimo periodo.E questo è il mio team principale, ma ovviamente sono parte anche di un altro team, che è il team executive, dove quindi tutte le figure insomma responsabili dei dipartimenti dell'azienda si siedono insieme e definiscono la traiettoria, la strategia e insomma come arrivare ai risultati che vogliamo ottenere.Quindi è un po' un doppio ruolo che secondo me è anche nel nome come C come Chief e T come Technology, quindi questo già fa capire il doppio ruolo, un po' attivo diciamo.Sì, la testa di ponte tra appunto il business e quello che è la parte tecnologi giusto.Ma in realtà tu però non sei nato CTO, fino a qualche anno fa ti occupavi di altro giusto? Sì, diciamo io nasco come sviluppatore, io sin da piccolo ho una grande passione per l'informatica.Ho messo le mani su un computer, un pc, penso nell'87, se non mi ero errato, avevo 4 anni, molto precoce, ma avevo questa grande passione.Poi, al passare degli anni, ho continuato a coltivare con una laurea di informatica all'Università di Napoli, io sono di Napoli, e poi da lì ho iniziato la mia carriera da sviluppatore.Mi sono occupato principalmente di back-end nella mia carriera, ho iniziato con Java nel lontano 2008, poi dopo ho fatto vari anni in scala, con linguaggio sulla JVM abbastanza...un tempo era "bleeding edge", Era un utilizzo abbastanza conosciuto.Poi, col passare del tempo, ho scoperto questa passione non tanto nel costruire software, ma nel far costruire software.Poi, secondo me, mancava questo anello di collegamento tra tecnologia e il mondo del business.parliamo sempre di tecnologia e business come due mondi diversi.In realtà secondo me non deve essere così.Ormai la tecnologia è parte integrante di tutto il business, ma ovviamente essendo una disciplina relativamente nuova non c'è quella conoscenza che puoi avere in altre discipline come marketing o sales o cose del genere.Io ho visto questo gap di figure tecniche che poi tendono a diventare importanti anche da un punto di vista business.Io credo che avere qualcuno che guidi tecnologia ma con un forte background tecnico aiuti sia l'azienda ma anche il team tecnologico, perché conoscendo le problematiche tecnologiche sei in grado di spiegarle alle tue controparti e di far capire tanti problemi che magari degli sviluppatori sono hobby ma per una persona che ha studiato finanza, che ha studiato marketing non lo sono.Quindi sta a noi far capire perché certe cose vanno in un certo modo.Sì esatto.Confermo quello che stai dicendo quindi lo condivido appieno e aggiungo anche un'altra una considerazione.Spesso noi che nasciamo come tecnici quindi che ci occupiamo di informatica siamo talmente presi dal mondo della tecnologia che cambia così velocemente che ogni giorno ci propone dei giocattoli nuovi per i quali magari spendiamo notate insonni e che non siamo ci troviamo in un contesto dove non siamo più in grado di dedicare spazio e neuroni ad altre cose e spesso tralasciamo il mondo del business che insomma è anche quello che ci da da mangiare ci permette di giocare coi giocattoli fondamentalmente no ci da un motivo per cui noi passiamo le ore su quegli strumenti e spesso trascuriamo questo business.Per cui la mia domanda adesso è questa.Cosa hai dovuto appendere al chiodo nel momento in cui il tuo ruolo è passato da sviluppatore a CTO e hai dei rimpianti o no? quello che appendi al chiodo è insomma a volte sai noi sviluppatori ora mi metto col cappello da sviluppatore a noi piace la tecnologia anche perché tecnologia perché ci piace giocare ci piace il nuovo tool ci piace questo magari questa idea super intelligente per risolvere un problema problema e quando sei CTO sicuramente devi pesare il fatto che i sviluppatori vogliano continuare a seguire la tecnologia che è giusto però con le esigenze del business perché sai, uno degli esempi particolari è sempre nuovi framework, nuove tecnologie da usare e non sempre la scelta giusta.secondo me da CTO il mio compito è quello di trovare un bilanciamento, perché io so che da un lato magari altre persone del business non capiscono perché dovremmo passare, faccio un esempio, da on-premises al cloud.Dall'altro lato io so che questo mi dà un vantaggio competitivo anche a livello di elasticità, di agilità, che poi nel business paga dividendi.Al tempo stesso devo gestire i miei sviluppatori, il mio reparto, per dargli quella spinta ad innovare tale, per poterli tenere engaged e comunque appassionati, perché la passione è una parte importantissima del nostro lavoro.Senza passione non si fa molto, secondo me.Al tempo stesso io devo anche dare contesto per far capire che se magari non sono così propenso a cambiare dallo stack XYZ allo stack ABC, ci sono dei motivi che voglio spiegare che magari da sviluppatore pensi di non avere quelle preoccupazioni, questi problemi.Perché devo pensare invece in azienda è sempre così, bisogna sempre pensare a muoversi tutti insieme nella stessa direzione.Per quanto riguarda gli impianti, diciamo che io a volte ogni intanto controllo qualche pull request, cerco di fare qualche linea di codice, però noi siamo 40, sai, alcuni CTO sono ancora hands on, io sono molto hands off e a volte ho l'impeto di "ora faccio una pull request, fixo una cosa", però cerco anch'io di evitare di farlo perché comunque non è più il mio ruolo e sai, anche nella mia posizione a volte se se dici qualcosa che forse non è così esatto qualcuno magari non te lo viene nemmeno a dire quindi il rimpianto è quello di forse non poter giocare però la mia soddisfazione è di come dire le mie persone riescono a farlo e riescono a farlo nel miglior modo possibile.Come riesci? Anche questo è un dubbio perché in realtà è stato il mio crucio più grande quando ricoprivo il ruolo del CTO e nel quale investivo parecchio effort poi tornando a casa con tutto il muso di mia moglie che puoi immaginare, ma come riesci a rimanere sul pezzo? Perché comunque il ruolo del CTO un po' ti ruba, ti tira.Come fai a stare sul pezzo sulla nuova tecnologia e soprattutto come riesci a magari tenere anche banco davanti ai team di dev quando si parla di una tecnologia per la quale magari hai avuto delle difficoltà ad approfondire perché ripreso in cose probabilmente più importanti lato business? Hai mai sentito il peso e se sì come riesci a stare sui binari? Allora sicuramente come riesco a tenermi aggiornato, io in questo momento credo molto nel parlare con con altre persone che fanno un lavoro simile.Sai a volte uno crede "Ah no, magari tu non puoi dire, non puoi raccontare cosa fai perché ci sono segreti".No, in realtà confrontarsi in particolar modo in questo momento per me con altri CTO è utilissimo, perché sai guardando troppo spesso nel proprio giardino, tendi a non capire quello che succede fuori.Perché anche se continui ad ascoltare conferenze o talk, a me piace molto leggere, quindi ho una lista di libri che tende a crescere sempre, perché sono sempre tanti libri da aggiungere, e ho sempre meno tempo per leggerli.Però il confrontarsi con altri CTO, con altri signor Ingegneri e leader sicuramente mi ha aiutato tanto.Per quanto riguarda il peso di non comprendere una tecnologia, io credo che alla fine la tecnologia, qualsiasi nuovo framework o pattern architetturale, abbia delle motivazioni e delle problematiche che risolve a di fondo.Per me è importante capire quelli, ad esempio se il mio team vuole propormi di passare a fare even sourcing o CQRS io devo capire perché.E quindi il discorso che il dato immutabile mi consente di separare lettura e scrittura, mi consente di scalare perché ovviamente disaccoppio i due momenti per un'applicazione che genera più lettura e più scrittura e un un pattern o l'altro è migliore, a me basta capire quello, perché se poi voglio usare Kafka per fare event sourcing o voglio usare un event store, quello mi interessa un po' meno, perché ho delle persone che lavorano a contatto con me e il cui lavoro è quello appunto di capire quale tecnologia esattamente, quindi per me più la direzione è perché andiamo in quella direzione esattamente.Quindi cerco di capire tutte queste nuove cose che sono scelte, se il container, che ormai non sono più nuovi, perché utilizziamo i container, che poi sia Docker Swarm o Kubernetes.A me personalmente cerco di capire qual è il trend anche per assumere persone, perché magari se fai la scelta sbagliata non assumi nessuno, Però per il resto, secondo me, per un sito è molto importante avere persone che lavorano con te, che abbiano quella skill tecnologica sempre up to date e a cui puoi ovviamente delegare in parte.Poi noi siamo un po' di persone, alcuni siti con un team più piccolo devono comunque restare sul pezzo molto più di me tecnicamente.Lì secondo me la soluzione è sempre praticare il buon vecchio smanettare, fatelo a casa una proof of concept e esplorare la tecnologia.Concordo, tecnologia e giocare a casa e le conferenze che poi ti danno quel turbo boost come dico sempre, perché le note in sonno li ha spese qualcun altro per te e ti è venuta a raccontare cosa è successo? perché di questo si tratta, sono in realtà gli strumenti che un po' aiutano.Leggevo l'altro giorno un simpaticissimo articolo dal sito del CodeMotion, codemotion.com, sul ruolo del CTO e questo articolo diceva una cosa carina, faceva un grafico, c'era un'immagine, in realtà non era un'immagine ma era del testo, ma io me la sono immaginata come immagine, con quattro tipi diversi di siti.Allora adesso te li propongo e tu provi a vedere in quale quadrante ti posizioni o dove.E' una cosa mi sembrava carina a proporti.Allora il primo tipo che il sito del CodeMotion propone in quell'articolo era il comandante dell'infrastruttura cioè colui che lavorava in prima linea per mettere in atto la visione tecnologica però decisa o comunque concordata con ed altri.La strategia tecnica da implementare è già preapprovata, quindi magari sai da consulenti esterni che fanno lo studio progettuale o quant'altro e questo CTO supervisiona l'infrastruttura, la rete, la sicurezza e la manutenzione.Questa è la prima, il comandante dell'infrastruttura.Il secondo è il grande pensatore che ha lavorato per creare il modello di business dell'azienda e lo fa tutti i giorni svolgendo i lavori strategici necessari per confrontare l'azienda con i suoi competitor quindi c'è sempre la sottanalysis sulla sua lavagnetta con tutti i competitor e fa da testa di ponte tra il livello più alto quindi la sala con le famose sedi attorno a un tavolo e i livelli inferiori dell'azienda comunque i ruoli più operativi verificando che le tecnologie siano state completamente implementate all'interno dell'organizzazione secondo la strategia concordata quindi diciamo è un garante della strategia però allo stesso tempo diciamo ha anche la mente da pensatore che tiene un occhio a guardare cosa sta succedendo fuori e la competitività è un indicatore importante.Poi c'è il visionario che è solitamente associato all'organizzazione sin dall'inizio, quindi uno dei primi che sono saliti a bordo ed è responsabile dell'elaborazione delle strategie tecniche e dei progetti comunque strettamente legati al modello di business.La priorità principale di questo CTO è quello di portare avanti il business dell'azienda, cioè qualunque cosa si faccia deve essere focalizzata col business e per finire c'è un altro un'altra figura questi indicano una quarta figura che il customer champion che è quel CTO che ha il pallino fisso del cliente e che perde ore a focalizzarsi sulla UI e UX quindi anche sulle use case del prodotto e si concentra completamente nella soluzione dei problemi lato comunque più legato al business? questa è una domanda difficile non te l'aveva fatta nessuno.Non me l'aveva fatta nessuno no, direi che io mi vedo un po' un ibrido tra il secondo e il terzo.Quindi tra pensatore e visionario? Sì o meglio, io non sono il Money Farm dall'inizio, però sicuramente so che il business insomma è importante.Qualsiasi scelta, anche la nostra strategia tecnica, la famosa tech strategy che ogni CTO in qualche modo deve fare, è molto allineata al business e comunque c'è una tech strategy deve essere conseguenza di una business strategy.Detto questo, io con le mie persone insieme analizziamo la tech strategy e poi la faccio implementare ai team e mi assicuro che venga implementata nel modo giusto.Quindi questo è un po' come vedo.Io mi vedo come un grande facilitatore.Io devo assicurarmi che il meccanismo funzioni e che funzioni in modo giusto.Insomma, sai, portare avanti una visione, far sì che la visione venga eseguita e che nel day to day le persone sappiano cosa fare, sappiano come risolvere i problemi, sappiano quali sono i nostri valori e come lavoriamo.Quella è una parte molto importante, far capire a chiunque, a qualsiasi sviluppatore, a qualsiasi QA, a qualsiasi delivery manager.Che noi crediamo in un certo modo di fare software e secondo noi quella è la chiave per il successo.Dare all'azienda una flessibilità, un'agilità tale da poter realizzare ciò che crediamo sia giusto realizzare.Ok, quindi adesso abbiamo la tua faccina tra quei due quadranti.gioco mi piace tantissimo tanto che credo che farò tipo la copertina del podcast così della copertina dell'episodio noi ci fermiamo un secondo e per poi ritornare a parlare di recreating Uno dei ruoli che un CTO ha non è tanto quello di andare a fare colloqui con gli ingegneri da tirar dentro ma più che altro quello di mettersi in condizione di scegliere dei collaboratori talentuosi.Come si scelgono questi collaboratori? quali sono le campanelle se ne esistono che ti dicono ok questo può fare strada con noi e poi come li si mantiene questi collaboratori nella nave? Sicuramente per me è importante capire quando si fa un colloquio a qualsiasi candidato come questa persona possa interpretare i valori dell'azienda.So che sembra un'americanata, ma in realtà è importante avere dei valori e capire in cosa crediamo come Money Farm.E questo perché? Perché noi alla fine siamo un'azienda di prodotto, noi facciamo prodotto.Ne parlavamo anche prima, abbiamo toccato l'argomento in modo leggero, ma facendo prodotto per noi la cosa che è importante è dare valore ai nostri clienti, e dare valore a questi clienti vuol dire che a volte se dobbiamo usare sequel e non possiamo usare qualcosa di super fancy tipo Cassandra o sequel in generale o GRPC, dobbiamo fare quella scelta.Quindi ho valuto molto chi mette l'esigenza del cliente davanti.Cioè tecnologia è un modo per servire il cliente, quindi noi dobbiamo essere preparati nel conoscere le varie tecnologie e sapere che se io ho una situazione in cui devo fare veramente, ho tantissimi accessi in scrittura, magari le transazioni le devo fare in un certo modo perché mi bloccano.Quindi questo è uno che io assumo, deve saperlo, però deve anche sapere che per fare le cose semplici non serve bazooka.Quindi per me l'importante è capire qual è il problema che stiamo risolvendo e trovare il modo più semplice, ma dico semplice non semplicistico, scusami in inglese lo devi simplistic, non vuol dire sottovalutare la complessità del problema, ma non complicarlo senza necessità, perché ahimè a volte mi sono trovato con tante persone molto valide, che però per amore dell'ingegneria del software tendevano a dover complicare concetti molto semplici.Ora questa è una cosa simpatica, ma invito gli ascoltatori se non l'hanno fatto a cercare su github un progetto che si chiama enterprise fizzbuzz, che insomma è il problema di fizzbuzz, che per chi non lo conosce è un programmino che conta da 1 a 100 per ogni multiplo di 3 scrive fizz e ogni multiplo di 5 scrive buzz, però su GitHub c'è questa missione fatta in modo enterprise applicando una ventina di design patterns della Gang of Four e cose del genere.È un esempio ovviamente portato all'eccesso per farsi una risata, però tante volte si tende a dover complicare cose semplici e tornando alla domanda io valuto molto chi sceglie la semplicità e chi mette il cliente davanti.Questo è un aspetto per me importante.Quindi essere un ingegnere di prodotto, un product engineer, è una cosa molto importante.La seconda è il lavoro di gruppo.Ora so che sembra un concetto fatto, ma è importante capire che i problemi non li risolviamo da soli, a meno che casi particolari.Specialmente quando c'è un'azienda grande, ci sono tante forze che tirano in modo diverso.Quindi collaborare, essere onesti ed essere umili, che non vuol dire accettare le idee degli altri, vuol dire semplicemente mettere a disposizione le proprie idee e essere aperti al confronto, un confronto anche duro, non maleducato, ma alla fine trovare una soluzione comune, disagree and commit e andare avanti.Questi sono due dei trait fondamentali secondo me.Concordo con te, non posso non concordare questa cosa mi dà fastidio, voglio fare sempre l'avvocato del diavolo e mi viene difficile oggi.Ti volevo chiedere una cosa, nella ricerca del personale una cosa che ho notato sempre più spesso in diverse aziende è quello di coinvolgere il remote work è anche il remote work asincrono, proprio per andare a trovare quei talenti particolari che in realtà probabilmente nel territorio circostante non si trovano.Adesso voi siete a Londra, per cui probabilmente questo prodotto siete anche a Londra, giusto? Avete una serie a Milano, una serie a Cagliari, dico bene? Sì, esatto.Però come vi ponete nell'ottica di lavoro da remoto? Allora, noi siamo distribuiti, e quando dico distribuiti intendo che ogni team ha persone su più uffici, quindi noi non abbiamo il team collocato.So che alcuni agilisti puri dicono che solo il team collocato funziona, io non credo.Ecco, questo è stato anche un vantaggio per noi quando è iniziata la pandemia, perché per Tech@Money fare il modo di lavorare non è cambiato.Abbiamo chiuso gli uffici, ma lavoravamo tutti allo stesso modo.Io già prima, quando ero in ufficio, probabilmente spendevo più tempo su Zoom che non di persona con i miei colleghi.Noi abbiamo circa, non ricordo i nomi esatti, ma credo una una decina di persone a Londra di Tec, una quindicina a Cagliari, una decina a Milano.Siamo circa più o meno con questo razzo.Ora in particolare abbiamo iniziato anche ad assumere persone in modalità fully remote.Non ci siamo ancora spinti verso il lavorare remoto in modo totalmente asincrono, per una serie di questioni.A noi comunque piace essere in ufficio insieme, piace anche l'aspetto sociale.Quindi cerchiamo di mantenerlo.Al tempo stesso l'accesso al talento è sicuramente più facile essendo remoti.Quindi le ultime due posizioni che abbiamo chiuso, abbiamo assunto due ragazzi in Italia, ma entrambi non hanno una sede di lavoro in ufficio, entrambi lavoreranno principalmente da remoto.Quindi sai, fare remoto è una challenge che noi secondo me abbiamo trovato il modo giusto per farla tramite l'utilizzo di tool come Slack, Zoom, l'abitudine perché ci siamo abituati.Remote asincrono, che quindi ovviamente vuol dire veramente ignorare la timezone a quel punto, vuol dire che è tutto pull anziché push, non abbiamo ancora pensato a questo.Chissà se in futuro lo faremo meno, però per noi remoto in generale ha funzionato e comunque anche non è così diverso da come lavoravamo già prima, quindi siamo stati fortunati su quello.Vorrei che per un attimo rindossassi gli abiti del dev e ti chiedo adesso con comunque l'esperienza che hai che va oltre allo sviluppatore, quali sono le differenze che tu trovi tra il solo dev, cioè quello che lavora da solo per conto suo, che fa i suoi progetti, magari freelance, e un dev che invece lavora in termini enterprise, quindi in contesti ben più grandi.Sicuramente la prima differenza che mi viene in mente è la necessità in un contesto un po' più grande di avere un processo.Il processo è una delle cose che comunque a tanti sviluppatori non piace, perché viene visto come un impedimento.Secondo me c'è processo e processo.Alcuni processi, decisamente, e ti parlo di Waterfall piuttosto che di ROOP, sono molto prescrittivi e tendono a non considerare come funziona il mondo, perché le cose cambiano da un momento dall'altro.Quindi il processo non deve essere un modo per limitare la produttività o limitare la creatività, al tempo stesso è importante per coordinare un gruppo di persone.Quando si è da soli, diciamo che io anche da solo credo che ci sia valore in un processo, magari in un personal kanban o comunque nel tenere una sorta di pace, di ritmo e quindi tenerselo.Ma sicuramente lavorare in gruppo, lavorare in un'azienda grande richiede un certo livello di coordinazione, che ovviamente è diverso quando si è in 10, rispetto a quando si è in 100, che quando si è in 10.000.Quindi sicuramente quella è una delle cose che mi viene in mente.Ovviamente lavorando in gruppo è importante darsi anche un po' degli standard, che non vuol dire il libro di 200 pagine su come si mettono i punti in virgola e gli stazi, perché per fortuna abbiamo tool automatici che lo fanno.Però è importante darsi delle linee guida su come fare, perché io a me piace...a me piace i++, a te piace i++, come facciamo? Non possiamo fare record review ogni volta che ce lo cambiamo.Quindi bisogna accettare la diversità delle altre persone, anche in ambito tecnico, quindi di preferenze, e trovare un filo comune.Sicuramente queste cose che anche non solo da solo da freelance developer, ma anche da una startup piccola, che magari ancora in fase di product market fit, quindi penso che ne so, a scrivere software senza test o a fare rilasci manuali, ad arrivare a un punto in cui sai stai crescendo, ti può sembrare un overhead introdurre test automatici, introdurre fare una pipeline di di continuous delivery eccetera però nel lungo termine all'aumentare le persone questi costi aumentano esponenzialmente quindi è molto più conveniente seguire una sorta di ritmo e processo piuttosto che continuare a lavorare come se fossimo 51 contro 50 un team di 50.C'è quella colla, il processo è quella colla che tiene uniti poi tutti tutti i dev per creare delle squadre.Hai parlato di team prima e noi qua nel podcast abbiamo parlato a lungo praticamente gli ultimi due episodi, uno era sui micro front end dove ho perso credo 15 minuti a parlare di team end to end e l'altro era sulle monoripo quindi anche qua dove ho anticipato situazioni dove all'interno dei team ci si scorna tra team diversi.La mia domanda è come gestite e come gestisci gestisci gestisci ma stanno in francia mi sto dimenticando anche italiano.Come gestisci i team? Tu crei dei team orizzontali lato tecnologia o lavori più con team end to end? E soprattutto quanto sono grandi questi team? Adotti la tecnica bezzosiana dei two pizzas team? Raccontaci un po' del tuo approccio nel manageriale per quanto riguarda appunto i team.Allora, bella domani, anzitutto grazie perché è un argomento di cui mi piace tantissimo parlare, anche perché ho speso quest'anno solo due mesi nel capire una nuova struttura di team per Monofarma.Non so se sei capito, piace tanto anche a me come argomento.Allora, parto dai...non sono dogma, però io ho delle opinioni molto forti al riguardo.Io credo nei team end-to-end, quindi credo nei team legati a aree del prodotto, non credo nei team back-end, nel team front-end.Paradossalmente noi avevamo un team mobile che non abbiamo più ora perché abbiamo distribuito i nostri mobile developer all'interno dei team.A me piace chiamarli cross-functional, anche perché secondo me quando crea un team del genere, un product team, Ora invito gli ascoltatori, magari se sono appassionati al riguardo, di leggersi un po' quello che dice Marty Kagan del Silicon Valley Product Group al riguardo.Lui parla molto di team, di feature team contro product team, contro delivery team.E' importante perché? Perché creando un team che abbia ownership di area di prodotto da tutti i punti di vista, quindi partendo dal top of the funnel per quanto riguarda il design, scendendo all'implementazione del backend, del frontend, che sia il suo web mobile e anche della manutenzione, del test e della manutenzione appunto, della missa di produzione, tu crei quello spirito di ownership e crei quelle conversazioni che ti portano a un prodotto migliore.Se io metto insieme un gruppo di individui e li faccio diventare un team e questo team lavora, faccio un esempio, al processo di onboarding della piattaforma, loro riusciranno a capire tutte le piccole diversità che ci sono tra piattaforme, il comportamento dell'utente, per avere un prodotto di qualità e al tempo stesso io sono un grande appassionato del famoso detto di Vogels "you build it, you run it".Quindi il team che lo costruisce e il team che alle due del mattino si sveglia se il software va giù.Questo ti dà un senso di responsabilità, che ci pensi due volte prima di prendere delle scorciatoie che magari non sono...e prendere l'orgoglio del proprio lavoro.Secondo me uno sviluppatore deve essere orgoglioso di quello che fa.Per essere orgoglioso vuol dire che funziona funziona bene e produce risultati.Comunque, tornando a noi, noi abbiamo dei team che sono appunto end-to-end, cross-functional.C'è anche un ottimo articolo di Anna Shipman sui durable teams.Quindi sono team durevoli, non sono team che metti lì son tre mesi e poi li cambi, no, perché l'onboarding in un'azienda come Monifarm c'è e ci sarà sempre.Quindi abbiamo sempre bisogno di persone che ci lavorano, migliorano, lo modificano quando ce ne fosse bisogno e quindi questi team hanno aree di prodotto assegnate e includono al loro interno tutto il skill set necessario a deliberare prodotto.Quindi hanno prodotto owner, hanno design, hanno back-end developer, hanno web developer, hanno mobile developer, hanno testing e sono tutti insieme.Sulla dimensione diciamo noi abbiamo quattro team di prodotto così strutturati, le dimensioni sono variabili ovviamente perché alcuni team hanno più area, alcuni team hanno meno area, diciamo più o meno andiamo da un team di 5 a un team di 10, secondo me 10 è già un alto come numero, però è gestibile.Io non andrei oltre il 10, quindi non mi ricordo quanto mangiano quelli di Bezos, quanto mangiano di pizza, perché se fosse un team come me, due pizza sono due persone, basta.Però diciamo che secondo me 10 persone è un limite massimo, idealmente 8 poi dipende caso per caso sai è difficile dare una ricetta standard.Levami una curiosità ma voi avete anche un team di platform che fa da supporto a tutti gli altri team oppure anche quello è diluito perché tu mi hai detto no che fondamentalmente ogni team ha una ownership anche in fase di ops o perlomeno così mi è sembrato di capirlo ho capito bene oppure c'è un team di platform che equilibra un po' tutto? Allora il team ha supporto ma non a livello di ops e di infrastruttura più supporto applicativo, quindi ad esempio se ci sono bug o qualche problema da risolvere applicativo se ne occupa il team.Per quanto riguarda l'infrastruttura abbiamo un team di Satellite Reliability Engineering o platform, la nomenclatura un po' come dire soggetto di discussione proprio di questi giorni in azienda e comunque si occupa appunto di supportare l'infrastruttura per tutti i team.Io personalmente credo che un team del genere debba essere un team che possa abilitare gli altri team a mettere software sulla piattaforma, ma non credo nel modello in cui c'è un team che fa solo quello e gli altri team parlano a quel il team come una funzione di servizio, perché secondo me quello ricorda molto il discorso dei team orizzontali.Per esempio, il più famoso è il QA.Uno sviluppatore scrive una feature, poi la manda a QA e se ne dimentica.Non c'è nessun senso secondo me in un'azienda moderna, perché siamo tutti responsabili da Accountable per produrre il risultato.Non è che io sono Accountable per scrivere il codice e poi non me ne frega niente di metterlo in produzione.Ricordo una volta ho avuto una conversazione e un commento con una persona che mi ha lasciato un po' basito, che mi disse "ma il mio lavoro non è quello di mettere software in produzione, io scrivo codici e poi lo do a Ops e Ops lo mette in produzione".Ma, diciamo, non avevo proprio questo diritto.L'anno '90 forse.Esatto, ora tutto sai, tutto devops, cosa è devops? Devops effettivamente è fare il bridge di quel gap, cioè i sistemi sono troppo complessi non ha senso dividere queste funzioni.Quindi noi abbiamo un team di piattaforma che si occupa di infrastruttura.A volte bisogna essere pragmatici, non riesco in questo momento ad avere come dire conoscenza di tutti i team, però quella è la direzione in cui voglio andare.Certo, certo.Questo è interessante anche perché comunque molta della complessità Ops è stata delegata agli strumenti cloud che utilizziamo tutti i giorni per cui adesso veramente il ruolo dell'ops diciamo da una parte si è un po' ridotto in termini proprio di mole di lavoro dall'altro necessita appunto di competenze di essere collegato a tutto il resto della pipe di produzione e quindi alla fine l'ownership è importante anche da quel punto di vista.No? Ti faccio però noi adesso ci stiamo avvicinando un po' alla parte dei giocattoli, no? Delle cose che io vedo il tuo sorriso quindi vedo che dentro di te vive ancora l'anima dello smanettone, del geek che chiama i giocatoli.Allora raccontaci un po' come è fatto naturalmente quello che puoi dire, se puoi dirlo, lo stack tecnologico che utilizzate in Money Farm e il perché di alcune di queste scelte.Sì, allora innanzitutto noi abbiamo parlato di cloud, siamo hostings su AWS, quindi appunto siamo lì.Abbiamo un'architettura basata su microservizi, ecco ora micro servizi potremmo fare tanti episodi solo a parlare di cose del microservizio eccetera, però ovviamente ci sono alcuni servizi che sono un po' più micro, altri servizi sono un po' più macro ed è secondo me, nella mia esperienza, anche da sviluppatore molto difficile capire esattamente quali sono i boundary giusti, però noi stiamo cercando appunto di andare in quella direzione.Ora secondo me ecco, boh, ne avremo alla meno 60-70 in produzione al momento.Ovviamente c'è un monolite, perché non ho mai incontrato un'azienda che non abbia un monolite, spesso è una startup che è uscita tanto, ma siamo arrivati al punto in cui il monolite gestisce una parte di traffico piuttosto negligible, abbiamo lavorato tanto per isolarlo e quindi ora ecco diciamo che non ci due anni fa ci influenzava tanto oggi ci influenza ma molto meno e poi per me quello è l'obiettivo principale consentire al team di muoversi in modo agile veloce senza il monovite che lo puoi rilasciare solo una volta al giorno.Per quanto riguarda tecnologie abbiamo un API gateway che abbiamo scritto in Kong, che tra l'altro è anche l'API che fa Empower, scusami ogni tanto mi escono questi inglesismi, Empower è la nostra public API che insomma è alla base anche dell'integrazione che abbiamo fatto con poste italiane, tramite il loro sito interagiscono con le nostre api che sono appunto su Kong.Da un punto di vista delle applicazioni, le applicazioni sono native, quelle mobile, quindi utilizziamo iOS e Kotlin, utilizziamo Auth0 per quanto riguarda l'identity management, Web siamo React, non utilizziamo Micro frontend, diciamo per ora abbiamo un approccio di un'applicazione unica, abbiamo sperimentato con Mini frontend, probabilmente non avevamo capito bene i concetti, non hanno funzionato per noi.Dimmi una curiosità, questi team come lavorano? La composizione è fatta a build time cioè rilasciati un unico front end? Rilasciamo l'unico front end, sì.Come fai a far lavorare team diversi sull'unico front end? Questa è una curiosità perché in realtà da noi ci siamo riusciti con spada e coltelli.Ti dirò è stata dal team nata l'esigenza di rincorporare tutto in un unico frontend, noi avevamo delle applicazioni separate che poi mettevamo insieme ma dal team è nata l'esigenza di rincorporare tutto sull'unico frontend, noi abbiamo uno sviluppatore web per team quindi non sono tantissimi per cui è un po' più facile anche gestirselo tra di loro.E poi gli sviluppatori web si integrano tra di loro quindi comunicano tra di loro.La front end guild diciamo, quindi i sviluppatori web sono coordinati però poi ognuno di loro è parte di un team, quindi c'è uno che magari lavora la dashboard, uno che lavora l'onboarding e cose del genere.Però per noi sta funzionando al momento, poi non metto in dubbio che magari quando saremo più persone avremo bisogno di rivedere il modello.No te lo dico perché in realtà noi ci facciamo tanto fighi di nuove tecnologie o che bello questo giocattolo escono i micro front-end e usiamo i micro front-end, esce il nuovo framework javascript, ah si lo buttiamo in produzione, peccato che come il tuo ruolo ci insegna il business è l'elemento centrale di tutto, cioè se ti riprendi quattro mesi per riscrivere il frontend perché è uscito il che ne so il pingoo il nuovo framework javascript super scintillante forse non è il caso così come la nuova architettura bellissima forse non è il caso infatti per esempio noi in azienda il primo micro frontend l'abbiamo implementato semplicemente dividendo tutto in siti separati e mettendo un frontend proxy alla direi alla grizzissima che però tutto sommato ha funzionato e andava bene questo proprio per supportare quello che dici tu che quando si deve andare in produzione si deve generare valore probabilmente queste tecnologie queste architetture sono belle da leggere negli articoli quando vai a leggerti gli articoli di Toothworks fai una festa poi però alla fine quando li portare in azienda tutto si complica giusto? Ma secondo me è importante capire cosa è funzionale non solo appunto all'azienda ma anche alle persone perché sai io ho fatto tanto uno sviluppatore back end, io ero super super impegnato nello sviluppo quando uscì l'app degli microservizi, si è tutto bello fare un microservizio, ogni microservizio è solo che ne so una, ogni microservice ha un solo endpoint, sarà proprio la panacea.Però alla fine tu stai spostando la complessità, perché quello che guadagni nella semplicità locale del codice lo perdi negli opere del progetto.Esatto, quindi poi vai a fare distributive tracing, logging e cose del genere.Quindi alla fine, secondo me, devi fare quello che funziona per te.Per noi in questo momento l'applicazione unica funziona bene, non metto in dubbio che se ci fossero problemi magari potremmo esplorare qualche modo diverso di farlo.Nel tuo stack tecnologico ho sentito che hai parlato di AWS e di OutZero.Poi in realtà leggendo gli articoli ho letto che nello stack c'è anche Tableau, c'è anche Nutterbox giusto? Sì abbiamo utilizzato Nutterbox, utilizziamo Scala sulla JDM, utilizziamo Docker, tante cose.No però su questi su questi servizi no? La mia domanda è, quindi parlo di Nutterbox, di AWS, di Auth0 e di servizi di questo tipo.Cosa spinge un'azienda a lasciare alcune parti di complessità e delegarla a partner strategici esterni? Quali sono le paure che si hanno quando giustamente si delega quel tipo di complessità verso fuori e come si scelgono questi partner? Allora, secondo me, soprattutto in un'azienda di risorse limitate, come insomma qualsiasi azienda che non sia Google o Facebook, che Facebook si è riscritta al compilatore, tu devi fare una scelta di cosa è importante e cosa no.Io credo che sia importante fare internamente ciò che corra all'azienda.Quindi cos'è Monifar? Monifar è una fintech che fa wealth management.Quindi se magari mi scrivo io internamente il sistema che va sul mercato a mandare gli ordini e verificare le posizioni dei clienti, voglio spendere del tempo del mio team a scrivere un sistema super sicuro che si occupi di autenticazione degli utenti, probabilmente, avendo risorse limitate, dovendo scegliere dove metterle, le metto sul sistema di trading o sul sistema delle posizioni degli utenti.Un esempio proprio pratico che ho, noi per fare continuous delivery usavamo concourse un tempo.Concourse è un tool super interessante, fatto molto bene, però secondo me quando tu hai un team di satellite di laboratorie di ingegneria e platform di ingegneria di tre persone richiede troppa manutenzione perché te lo devi installare da te, ti devi manutenere i server, le patch, questo e quello e poi non funziona eccetera.Io preferisco onestamente fare partnership con GitLab, noi utilizziamo GitLab, e utilizzare GitLab CI, quindi io i sviluppatori scrivono le pipeline, però poi una volta che la pipeline è scritta, viene tutto eseguito lì dentro, io non me ne devo preoccupare.Perché? Perché così il tempo del mio team di Site Revealed Engineering lo posso spendere a lavorare sulla sicurezza, sull'alerting, sul monitoring dei servizi, sulle dashboard.Quindi tornando alla tua domanda, cosa ti spinge? È un discorso di fare quello che veramente corre al business e quindi il resto magari dice "ah no, tu paghi che ne so mille sterline o duemila sterline ma se facendo i conti poi cedendoci il tempo che ci perdi a manutenerselo da te e a scegliere il tool e a fare gli aggiornamenti eccetera io credo quasi sempre convenga per quello che non è core andare su un partner strategico.Assolutamente sì.Altra su questo guarda metto anche il timbrino oltre che alla firma visto che per esempio adesso sto lavorando un piccolo prodotto e proprio oggi integravo due partner perché scrivere la parte di analytics era impegnativo tutta la parte di big data farla tirare su gli strumenti era troppo impegnativa anche quello quindi integriamo mandiamo i dati gestiamo con attenzione quello che il nostro partner fa quei dati perché anche questo è un problema mica da ridere la scelta del partner.Assolutamente, è importante fare una due diligence e poi a maggior ragione per noi, noi siamo una fintech quindi siamo soggetti a della regolamentazione interiore, nel senso noi siamo comunque regolati dalla Financial Conduct Authority, la FCA in Inghilterra, per cui siamo obbligati, abbiamo degli odi annuali, siamo obbligati a fare le cose in un certo modo, ad esempio su tutti i software che si occupano della compliance abbiamo bisogno di nodi trail, ogni modifica deve essere approvata quindi abbiamo configurato GitLab in modo che ogni modifica prima di essere emergiata sul master debba essere approvata da una persona del gruppo specifico che ha ricevuto il training.Quindi è importante fare due diligence, è importante capire i contratti.È una parte che ho dovuto imparare perché quando sei sviluppatore non ci pensi, ci arrivi dopo, però è una parte molto importante.Di certo, rivolgiti alle aziende come WS che hanno tanti clienti nell'ambito finanziario, ti aiuta perché è comunque un nome importante e insomma tante aziende l'hanno fatto e anche loro ti danno una mano a capire come la soluzione con loro possa aiutarti nell'essere compliant alle regole.Giusto, un'altra domandina sempre che riguarda lo stack tecnologico.Diciamo che lo tange lo stack tecnologico.Da qualche tempo, a questa parte leggevo non da tantissimo, state aprendo a partner esterni in termini di API giusto? Sì.Quindi altri come li chiamo? System integrator? come altri partner che possono accedere ai vostri sistemi, alle vostre funzionalità attraverso i pi esterne.Come si percepisce la responsabilità di avere già un sistema che lavora in ambito fintech dove comunque ci sono dei confini molto strutturati quando si apre agli altri? Come ci si sente proprio a livelli di di di di di di fin mi viene anche difficile fare fare la domanda non so se sono riuscito a credo di aver capito beh sicuramente è una grande responsabilità ma d'altronde noi abbiamo già una grossa responsabilità verso i nostri i nostri clienti i nostri clienti si fidano e ci affidano le sparghi quindi da un punto di vista di sicurezza noi cerchiamo di seguire tutte le pratiche migliori, quindi dalla criptografia dei dati rest in transit, alla segregazione dei dati personali, a penetration testing in modo regolare.Se tu credi che quello che fai lo stia facendo nel modo giusto, questo ti aiuta anche perché se ne sei convinto e hai anche la prova, perché d'altronde ogni anno c'è qualcuno che ci viene a dire se facciamo le cose bene o no, e se non le facciamo bene ci dice cosa dobbiamo fare per farle bene, ci consente di essere abbastanza confidenti.La notte dormo tranquillo, mettiamola così, perché so che gli investimenti di un studente sono al sicuro, però sicuramente è un lato da considerare.E' una pussola sempre presente sulla scrivania quella.Ho il telefono sempre acceso che se succede qualcosa lo vengo a sapere.Assolutamente sì, bellissimo.Hai parlato prima di testing.Fare il testing della propria applicazione, specie in ambiti così sensibili come quello che andate a trattare voi.Quanto è importante? Ci sono delle parti che potete trascurare per cui si può non testare tutto o come ci si gestisce una parte di testing? Facendo un ragionamento realistico, non il progetto che parte da zero dove ti puoi divertire a fare qualcosa, cioè prendendo in mano una codebase che comunque ha x anni come ci si approccia al testing? Allora io credo sia molto importante quando dici testare tutto la risposta deve essere sempre più o meno sì devi testare tutto.Poi il livello di come dire su alcune parti meno critiche puoi permetterti di avere un approccio leggermente più leggero altre parti come ad esempio l'algoritmo che genera gli ordini per i clienti devono essere pensate in modo rigoroso ovviamente.Io credo sempre che nel festing, come un po' in tutta la tecnologia, bisogna prendere sempre un approccio legato al rischio, quindi dove c'è più rischio devi essere più attento, dove c'è meno rischio non dico devi essere meno attento però sicuramente puoi essere un pochino più...non so è la parola giusta, però sono due aree da trattare condiversamente.Tant'è che, come ti dicevo, i nostri auditor ci hanno detto che alcuni sistemi per essere lasciati in produzione devono avere una approval stamp da qualcuno che ha ricevuto un trade in particolare.Poi ovvio, quando sei una startup, sei a inizio, tante cose le fai, vai veloce, quindi il testing Una di quelle cose che lascia un po' dietro l'importante è poi però quando inizia ad avere una base clienti significativa come nel caso nostro, che tutte le parti della piattaforma siano testate e alcune più particolari in modo rigoroso.Abbiamo recentemente rilasciato un aggiornamento del protocollo che utilizziamo per fare i trading e il test con il nostro partner è stato piuttosto lungo anche perché sai testare con una terza parte è ancora più interessante.Ci abbiamo dedicato tanto tempo, è andato bene, però ci abbiamo voluto dedicare tanto tempo.Non appelli sulla lingua la terza parte e soprattutto non condivide pregiudizi e bias, che invece facendo un test interno, per pregiudizi proprio intendevo il concetto di bias, che facendo un test interno volente o nolente comunque hai, perché non potresti fare altri comunque sarei proprio curioso di vedere come avete moccato i servizi esterni dell'algoritmo di trading perché dalla faccia che fai è stato un sacrificio importante giusto? Noi per fare trading utilizziamo il protocollo FIX che è un protocollo abbastanza conosciuto nell'ambiente finanziario diciamo ora abbiamo anche un ambiente di test che la nostra parte delciandato, quindi a volte poi fai scelte se mockare tutto o non mockare tutto.Alcuni pezzi li fai solo in integration test, altri pezzi magari li fai con i mock, poi non puoi scendere più in dettagli.Anche perché ti dirò, non ne sono nemmeno troppo a conoscenza ovviamente, perché poi sai, io vedo il progetto a un certo livello, poi se c'è un mock o se c'è un testing server sono dettagli di cui non sempre ho la visibilità totale.Sì sì no ma la mia era proprio una battuta per dire quanto può essere comunque impegnativo a fare testing su parti di sistemi che sono critiche.Assolutamente.Dove in realtà oltre che la responsabilità del programmatore c'è anche la responsabilità del CTO e qua ti porto su un argomento che mi piace tanto approfondire che è quello della responsabilità dello sviluppatore.Però per un attimo spogliati dei vestiti di colui che è CTO e ha grosse responsabilità di una società che lavora in ambiti critici dovendo riassumere il concetto di responsabilità e anche di deontologia dello sviluppatore quindi di approccio proprio al proprio lavoro in termini responsabili.Cosa pensi che manchi al programmatore medio, allo sviluppatore medio mondiale, in ambito mondiale proprio in termini di approccio deontologico? Parlavamo prima, ho accennato la parte dell'orgoglio in quello che si fa.Secondo me è necessario che ogni sviluppatore che si sieda la mattina un'altra computer, insomma, debba arrivare alla fine della giornata sentendosi orgoglioso di quello che ha fatto.Per sentirsi orgoglioso vuol dire che hai fatto qualcosa che ti soddisfa e di cui poi puoi dire "io ho fatto questo".Questo è un livello diverso di ownership, secondo me, perché se io...C'è, ci fu uno scandalo della marca di automobili tedesca, missioni, test eccetera ora non voglio dire il nome perché non me lo ricordo non voglio farmi denunciare o cosa del genere.Guarda noi qua siamo liberi potrei dirlo io anzi metto il logo sulla copertina se vuoi.No scherzo.Sai io mi domando ma quei programmatori, quei sviluppatori che hanno fatto quel test, ma erano orgogliosi di quello che avevano fatto.Secondo me no.Perché allora non hanno alzato la voce e detto "ma io come posso fare questo?" Perché sai, alla fine noi ovviamente abbiamo a che fare con gli investimenti dei clienti, abbiamo una responsabilità morale, ma non solo morale, ma anche dettata dalle leggi che ci regolano.Qualsiasi sviluppatore può avere un impatto di diverso tipo, le sviluppature di sistemi time critical per ospedali piuttosto che missili, insomma, ci sono le vite delle persone in mezzo e secondo me l'orgoglio ti aiuta, perché? se veramente vuoi essere orgoglioso di quello che hai fatto vuol dire che lo prendi sul serio, quindi vuol dire che capisci, cerchi di farti domande, non prendere per assodato quello che ti viene detto, fatti delle domande, cercali di capire perché stai facendo quello.E' importante elevare non solo il livello tecnologico, cioè il requisito scrivo il codice, ma capire veramente, farsi le domande su cosa sto facendo e che senso abbia.E' È normale che ci siano aziende che hanno un modello di business questionabile da un punto di vista deontologico, ma noi come sviluppatori vogliamo lavorare per quelle aziende.Io onestamente ho lavorato anche per un'azienda di scommesse in passato.Le scommesse sono molto particolari, perché nelle scommesse di sé per sé non c'è nulla di male, però ci sono persone che purtroppo abusano delle scommesse, quindi si creano drammi familiari, addirittura si distruggono famiglie.Diciamo che non è una scelta facile, ma io ero convinto che quello che facevo e quello che l'azienda faceva in quel momento, perché anche noi appena assunti ci dicevano cosa faceva l'azienda per evitare questo genere di cose.Poi in UK il gambling è comunque regolato, c'è il gambling commission, ogni prodotto deve avere delle limitazioni, quindi ci sono dei limiti che possono far sì.La tua domanda è se posso essere orgoglioso di quello che faccio? Sì, perché io so che comunque se qualcuno esagera c'è questa consentezza della piattaforma esatto che ti fanno sentire più tranquillo.Ma secondo me è proprio importante sentirsi orgogliosi di quello che fai, potersi guardare la mattina allo specchio e dire io faccio una cosa di cui sono orgoglioso e so che ha un impatto e questo impatto è positivo.Esatto è la cosa fondamentale, soprattutto provare a entrare e avvicinarsi al business della propria azienda è quello che è il tuo ruolo è quello che spesso gli sviluppatori evitano come la febbre ma è anche quello che ti rende consapevole di quello che stai facendo cioè quello che ti trasforma da scimmietta pigiatasti se lo dico nel modo più dispregiativo possibile però ci capiamo da scimmietta pigiatasti a sviluppatore consapevole che cerca di portare valore in una direzione che esposa la mission e la vision della società.Cambia completamente tutto.Ci siamo trattenuti tantissimo ma io non ti posso lasciar andare via non prima questa è una parte di cui non ti avevo neanche accennato non prima di averti fatto due piccole domande.La prima è quale editor di codice usi? Non l'ho voluta fare io ma la community mi ha detto che mi linciano se non faccio questa domanda a tutti gli ospiti che rengono.Quindi sei della scuola di Vim o della scuola di tutti gli altri? Perché fondamentalmente il problema è quello? Allora il mio editor di testo default quando faccio git commit sulla command line è vim.Detto questo utilizzo IntelliJ ADA.Però sono vim contro Emacs, conosco anche qualche scorciatoio di vim nonostante non lo uso più.Benvenendo dal mondo Scala me l'aspettavo questa risposta però eh.No l'ultima cosa qua su Gitbar abbiamo un momento che si chiama il paese dei balocchi dove tiriamo fuori un po di cosettine carine di gingilli che ci catturano l'attenzione e che vogliamo condividere.Dovendo mettere sul tavolo qualche gingillo, prima hai citato alcuni libri no? Interessante, alcuni articoli, c'è qualcosa che ci suggeriresti di andare a vedere."E conduco nel paese dei balocchi" "Ah, il paese dei balocchi" Sì, c'è un libro in particolare che ho letto, sai mi ha fatto un po' la domanda inizialmente come da software developer sono diventato poi un po' più manager della CTO.C'è un libro che io mi sento di consigliare a chiunque fosse incuriosito del passaggio, di cosa vuol dire il passaggio, cosa vuol dire fare il tech lead, magari prima, poi il team manager, il manager di manager, l'engineering manager eccetera.Un libro che ho letto qualche anno fa, che mi è piaciuto molto, è un libro di Camille Fournier, che si chiama "The Manager's Path" e secondo me è una lettura utile anche per chi non è interessato al momento per capire un po', magari sai tu vedi il director e ingegneri, poi avete il CTO, ingegneri e manager, ma questi cosa fanno dalla mattina alla sera che stanno sempre in meeting e non scrivono codice? Secondo me il libro ti spiega proprio in maniera incrementale, senza scendere troppo nell'età, ma come buona introduzione, i vari livelli di cosa vuol dire avere una carriera, una progression a livello di management, di software developer.al libro che mi ha aiutato tanto anche per capire ma un sito cosa fa perché sai chi mi chiede cosa faccio probabilmente guarda il mio calendario tutti i meeting però ogni meeting ha la sua importanza perché perché manda avanti con l'iniziativa oppure mi consente di parlare con le persone per capire quali sono i problemi anche di capire cosa devo risolvere da ora a sei mesi e secondo me quel libro è molto molto interessante lo cerco lo metto nelle note dell'episodio e tra l'altro lo acquisto e lo leggo perché mi ha incuriosito.Se lo stai suggerendo è perché è stato in grado di darti parecchio valore almeno in quella fase di transizione.Invece più tecnicamente è un altro rimpianto forse di non aver mai approfondito completamente il functional programming.Da scala a scala è un po' la Gateway Drag, ci sono tanti costrutti funzionali, ho fatto anche un po' di Haskell nel tempo libero, ovviamente non al lavoro.Insomma, consiglio agli ascoltatori, se non hanno avuto modo di giocare con il functional programming, di dargli un'occhiata perché è un paradigma diverso che però apre la mente in tante direzioni e serve secondo me per uno sviluppatore.Allora, siccome eri uno scalista...si dice scalista? sì possiamo dire scalista sì.Eri uno scalista? Allora qua il gingilo lo metto io che è stato un suggerimento che mi ha dato mia moglie io all'epoca programmavi in php quindi tutto tranne che functional.Vedere il corso di Odeski sulla functional programming in scala ha cambiato il mio modo di vedere il codice e il mio modo di approcciare i problemi.Quindi sì, mettiamo anche il corso di Odeschi.Per chi non lo sapesse Odeschi è il creatore di Scala, giusto? Sì esatto, qui ti metto il timbrino perché quando mi sono avvicinato a Scala nel 2011-2012 il corso di Corsera è stato il secondo step dopo aver comprato il librone, ma il corso è veramente utile, quindi lo consiglio anch'io.Emanuele, io non posso far altro che ringraziarti infinitamente a nome degli ascoltatori di Geekbar e a nome mio.Mi ha fatto infinitamente piacere averti qua nostro nostro ospite.Sappi che questa da oggi è diventata anche un po' casa tua per cui quando hai qualcosa da raccontarci, due righe e c'è sempre un microfono pronto a sentire e a capire le cose interessanti che hai da dirci quindi grazie e cosa ti posso dire a prestissimo? Grazie a te è stato un piacere e a presto GitBar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei fullstack dev.[Musica] [Musica]
