08 Feb 2023
Sono appena rientrato a casa da un’esperienza che per me ha avuto del magico: il FOSDEM 2023. Avendo avvisato “la gang” già da un po’ di tempo prima usando Mastodon sono stato fortunatissimo a poter incontrare di persona gente con cui di solito il massimo che posso fare è scrivermi, e devo dire che mi sono veramente emozionato a trascorrere questi tre giorni a Bruxelles. È stato il mio primo FOSDEM, ma decisamente non sarà l’ultimo. Lo scrivo già da ora: ci vediamo l’anno prossimo. Per forza.
Volendo scrivere un resoconto mi accorgo di non sapere da che parte iniziare, quindi probabilmente è meglio che io inizi direttamente da un banale ordine cronologico.
Gli stand
Innanzi tutto, appena arrivato e appena presa confidenza con la città e i suoi mezzi, ho comprato la maglietta del FOSDEM di quest’anno. È un modo per sostenere economicamente la conferenza (almeno a livello infinitesimale), e allo stesso tempo per aggiungere un pezzo di valore al mio guardaroba nerd. Non ho preso la felpa per due motivi:
- Costava un rene;
- Metterla in valigia sarebbe stato più complicato: adesso che so che ci sono le felpe riserverò dello spazio l’anno prossimo, potenzialmente costruendomi il guardaroba direttamente in loco. :-D
A parte questa parentesi fashion, ho rimediato altre magliette al mio stand preferito, ovvero quello di openSUSE (momento aziendalista lol), presso il quale ho potuto incontrare degli adorabili membri della community molto radicati, e svariati colleghi con cui ho potuto chiacchierare a proposito dei progetti su cui stiamo lavorando con il nostro team. È stato strano da una parte, perché non abbiamo quasi mai occasione di vederci di persona, estremamente appagante dall’altra.
Intorno allo stand di openSUSE c’erano chiaramente anche altri stand di altre distribuzioni Linux: il più divertente tra questi per me è stato lo stand di Gentoo, dove per onorare lo spirito della distribuzione in cui ogni utente compila i software sulla sua macchina, se volevi spillette o adesivi te li dovevi stampare da solo.
Le devroom
A strapparmi dalle risate per l’autoironia clamorosa dello stand di Gentoo sono stati chiaramente i talk che si sono tenuti nelle varie devroom: dopo le sessioni di keynote il resto dei contenuti sono stati ospitati da aule più piccole, che in alcuni casi erano purtroppo decisamente sottodimensionate rispetto all’affluenza suscitata da determinate tematiche. Le mie devroom di riferimento sono state quella di Rust il primo giorno, e quella di Erlang e Elixir il secondo giorno. Ovviamentea scrivere Elixir siamo sempre in quattro gatti, quindi non è stato un grosso problema assistere a tutti i talk e anche andare a fare un giro ogni tanto senza la paura di non trovare più posto.
Viceversa per quanto riguardava la devroom di Rust ho capito abbastanza in fretta che una volta rimediato un buon posto non mi sarei più alzato per quasi tutta la giornata: ho letto svariate lamentele durante i talk, soprattutto mentre parlava Kris Nóva, e i post parlavano sempre di file chilometriche. Mi sono trovato incagliato anch’io in una fila del genere cercando di entrare nella track di Continuous Integration and Continuous delivery per seguire il talk di Olivier Vernin, e devo dire che non è stato per niente piacevole.
Dall’altra parte, mi rendo conto che non avendo la vendita di biglietti come metrica di quanto si riempirà la location, è difficile per gli organizzatori prevedere il macello che si farà in un posto del genere.
Ma tornando al nostro argomento: le devroom! Al 99% i talk che ho seguito sono stati interessantissimi e tenuti da persone molto preparate. Sono stati veramente pochi gli speaker che ho visto che mi hanno fatto pensare “questa persona avrebbe potuto fare meglio di così”, e ognuno è stato efficace al suo massimo livello, dallo speaker più navigato alla persona che aveva bisogno di misurarsi con un pubblico un po’ più grandicello.
Della devroom di Rust ho apprezzato in particolare Building a distributed search engine with tantivy, di Harrison Burt, e Aurae: Distributed Runtime, di Kris Nóva. In particolare il talk su Aurae è stato per me una bellissima occasione di riflessione su come concepire qualcosa di più digeribile da un utente comune in uno spazio operativo dove quando si parla di container è impossibile prescindere dalla demagogia della CNCF e dallo strapotere di Kubernetes.
Della devroom di Elixir ho adorato Running Erlang and Elixir on microcontrollers with AtomVM di Davide Bettio, principalmente per il fatto che è durato cinque minuti scarsi in cui Davide ha praticamente ownato il suo pubblico. Ci mancava solo il mic drop finale. Non vedo l’ora di poter guardare il video.
Una menzione speciale va alla devroom di LLVM, che mi è stata consigliata da Michelangelo, in cui ho trovato una selva di scoppiati che parlavano di cose allucinanti. È stato strano e meraviglioso al tempo stesso immergermi in una realtà di cui capivo mediamente una parola su tre.
Gitbar @ FOSDEM
Un evento particolarmente emozionante è stato per me incontrare di persona Mauro, Luca, e Leonardo, che insieme a Carmine con cui ho la ~s~fortuna di lavorare tutti i giorni formano la quasi totalità degli host di Gitbar. Nonostante ci conosciamo ormai da diverso tempo non ci eravamo mai incontrati, e abbiamo sfruttato questa occasione non solo per prenderci le birre che non ci eravamo mai potuti prendere fisicamente ma solo virtualmente, ma anche per registrare una puntata pirata piena di scurrilità in presa diretta usando il telefono di Carmine e occupando un’aula della facoltà di Diritto e Criminologia.
Spero che l’episodio esca quanto prima, anche se sono estremamente consapevole che il montaggio richiederà del tempo. Scusa Mauro per la pressione che ti sto aggiungendo in questo momento :-D
Considerazioni finali
FOSDEM è stato un evento di portata gigantesca, sia oggettivamente parlando che da un punto di vista squisitamente personale. Quest’anno hanno partecipato tante persone che non c’erano mai state, e ho veramente l’impressione che si sia un po’ tornati a certe vibrazioni e alla consapevolezza che un’intera industria multibiliardaria si regga in realtà sulla passione di relativamente poche persone. A volte capita di perdere la concentrazione e dimenticare quali sono gli aspetti importanti, specialmente del lavoro che si fa. Per me questa conferenza ha significato riprendere contatto con un ecosistema che ritenevo ormai al lumicino, tastarne il polso, e scoprire che è ancora vibrante di buone idee, seppur con i suoi problemi.
Ho capito che ci sono ancora un sacco di lande inesplorate, e che come software engineer siamo circondati di tantissimi amici pronti a darci una mano anche nei momenti più bui, in cui ci sentiamo isolati e senza motivazione. E ogni volta che ci sentiamo così, forse la cosa migliore è darsi appuntamento e parlare tra noi di static typing con una birra davanti, senza scemenze corporate in mezzo.
31 Dec 2022
Se dovessi cominciare a fare una lista di tutte le cose che sono accadute quest’anno per metterle in fila e fare il mio personale bilancio, non saprei nemmeno da dove iniziare. Probabilmente sarà meglio andare direttamente in ordine sparso, raccontarvi un po’ di roba, fare le mie solite sezioncine e alla fine vedere se c’è da tagliare, limare, sistemare, lettera, testamento.
È stato sicuramente un anno in cui mi sono messo alla prova. E devo dire che l’ho fatto in molti modi, a tratti esagerando, ma il bilancio è positivo e la soddisfazione che ne ho tratto complessivamente è stata enorme. Se dovessi riassumerlo in una frase, questo 2022 che sta terminando è sicuramente una fila di 365 giorni da cui mi porto dietro una migliore consapevolezza di me.
Ma veniamo agli eventi tangibili.
Creare Mondi: e mondi sono stati creati
L’anno scorso ho menzionato di aver intrapreso insieme ad Agnese un corso di scrittura creativa. Il corso in questione è stato Creare Mondi, curato e “insegnato” da Eulama Litlab. Voglio scriverlo esattamente come lo penso: probabilmente uno degli investimenti migliori che abbia fatto in vita mia. Mi ero iscritto pensando di voler accumulare qualche attrezzo in più per diventare essenzialmente un Dungeon Master migliore, invece come primo elemento di questa lista destrutturata mi sono stati dati degli strumenti analitici per nulla banali, che hanno aumentato a dismisura le mie capacità di sviscerare non solo un testo scritto, ma in generale una storia.
E non parliamo solo di strumenti di analisi, ma anche di progettazione e di esecuzione: la nostra classe di Creare Mondi ha deciso infatti di intraprendere un’esperienza di scrittura collettiva di un romanzo. Se vi dovessi descrivere che cosa è uscito fuori, i più direbbero che è un romanzo cyberpunk. Io vi direi che è un bel libro.
Abbiamo terminato nel corso di quest’anno la prima stesura. Non sappiamo bene che cosa ci faremo, ma è stato un viaggio talmente emozionante che ora, su due piedi, non so nemmeno descriverlo a parole. Entrare nella psicologia dei propri personaggi da una parte, dei coautori dall’altra, è qualcosa che auguro a chiunque voglia mettersi in gioco con qualcosa di inaspettato e nuovo.
Il mio grazie più profondo, per quello che Tolkien chiamerebbe assolutamente un viaggio inaspettato, va a (in rigoroso ordine alfabetico) Agnese, Alexander, Anja, Anna Chiara, Pasquale e Roberto.
Siete il gruppo di avventurieri migliore in cui uno possa sperare di imbattersi.
Un anno di Casa Blaster
Non c’è molto da scrivere su questo aspetto, ma è una cosa importante quindi ho voluto dedicargli una porzione tutta sua del bilancio di quest’anno. A Marzo abbiamo compiuto ben un anno di permanenza dentro questa casa. Il 2022 è stato il primo anno in cui ci abbiamo vissuto dentro dall’inizio alla fine. Come i proprietari terrieri (heh) che stanno leggendo questo post sapranno, il possesso di un immobile si porta dietro tantissime cose; principalmente bestemmie e imprecazioni.
Ma sotto questa coltre di madonne in realtà c’è tantissima felicità, la felicità di avere un posto sicuro. Il proprio angolo di mondo di cui si è assoluti signori e padroni, liberi di riempirlo di qualsiasi scemenza. Sia io che Agnese non ci siamo tirati indietro: chi ha visitato casa nostra ha ripetuto anche più di una volta che dovremmo far pagare il biglietto d’entrata.
Se state leggendo, mi auguro che veniate a visitare il nostro museo.
Fanno dieci euro.
SUSE Trento 1.0
Lavorativamente è stato un grande anno, sicuramente pieno di sentimenti intensi. Trento, il prodotto di cui mi occupo praticamente a tempo pieno insieme al mio team, è arrivato alla sua versione 1.0 passando per svariate gestazioni complicate e, devo dirlo, una riscrittura pesante cambiando completamente stack: siamo passati da Go, static templates e una manciata di componenti React a un’implementazione completamente scritta in Elixir, che implementa il modello CQRS/ES (ovvero Event Sourcing e Command/Query Responsibility Segregation), con spalmata sopra una bella single-page application basata su React.
Il viaggio è stato clamoroso, e ho imparato tantissime cose sia su Elixir e Commanded (il framework che usiamo per implementare CQRS/ES), sia su JavaScript. Una riscrittura non è mai facile, soprattutto una riscrittura della larghissima parte di un’applicazione web: i rischi sono tanti, e in molti faticano a vedere i benefici di un’operazione simile. La verità? Eravamo disperati. Ma dalla disperazione è nato qualcosa di meraviglioso. Probabilmente è materiale per un racconto più approfondito, sempre su queste pagine.
#Fedi23
All’incirca verso Marzo di quest’anno è stato chiaro che nell’ecosistema dei social media “tradizionali”, se così vogliamo chiamarli, stavano per verificarsi degli eventi di portata colossale. Dipende da quale lato si guarda la questione, ma per alcuni sono stati eventi con un impatto catastrofico. Bryan Cantrill ha definito l’acquisizione di Twitter da parte di Elon Musk e gli accadimenti successivi qualcosa di portata “Enron-ique”.
Per questo motivo durante quest’anno ho ripreso lo studio del protocollo ActivityPub, che avevo già esaminato nel 2017 ma che avevo lasciato perdere per questioni di tempo e di perdita d’interesse.
A oggi penso che valga la pena spendere più tempo e sforzi a comprendere come poter migliorare quello che abbiamo a disposizione per mantenere Internet un meta-luogo decentralizzato. Ho ideato e intrapreso alcuni sforzi in merito, ma per ora sono solo caccole e non meritano nemmeno di essere raccontati :-) Quello però che posso dirvi è che alcuni li ho intrapresi in solitaria, su altri invece ho trovato dei sodali con i quali a inizio 2023 probabilmente concretizzeremo qualcosa di tangibile.
Impiadinando
Non mi andava di scrivere “ricapitolando”, e “wrapping up” mi suonava troppo scontato e esterofilo. Quindi: impiadinando. Questo 2022 è stato una piadina con dentro un sacco di cose. Chi ha avuto contatti più o meno stretti con me è a conoscenza del fatto che ancora più che curioso io sono insaziabile, per cui ho solo un proposito e un augurio per l’anno venturo: che sia una piadina colma da scoppiare, per me e per voi che leggete, di ingredienti meravigliosi che ci facciano strabuzzare gli occhi di stupore. Che ci allarghino il volto in un sorriso.
Daje.
12 Dec 2022
Qualche giorno fa stavo pensando a tutti i generatori di siti statici che sono usciti “ultimamente” (dove per ultimamente intendo negli ultimi anni, non nell’ultima settimana e mezza). Per coincidenza, sono cascato sopra questo thread nel bosco selvaggio del fediverso, proprio qualche giorno dopo che Mauro ha mandato un breve rant contro Astro nel gruppo Telegram di Gitbar.
E mi sono detto, ma lo sapete che c’è? C’è che io sono un maledetto nerd e adesso vi spiego che io sono felice di come è implementato questo blog, che da Settembre 2014 è completamente scritto con Jekyll e una chilata di file markdown. E basta. A parte qualche singhiozzo durante qualche upgrade non si è mai rotto, e ho sempre integrato qui e là qualche funzionalità quando ne ho sentito il bisogno. In realtà, per la maggior parte del tempo, non ne ho sentito la necessità. Da un annetto e mezzo genero le preview dei post in formato card usando ImageMagick e una svomitazza di Ruby amatoriale che i meno schizzinosi definirebbero un plugin.
Non ci è voluto molto perché arrivasse qualcuno a dirmi che era uscito Hugo e che se non stavo migrando tutto a Hugo stavo perdendo tempo. Me l’hanno detto in tanti devo dire, e Hugo è l’unico generatore con cui farei cambio a oggi, forse. Qualche tempo dopo è uscito Gatsby. Fichissimo. Tutto a componenti. Ci ho pensato a migrare, poi ho lasciato perdere: il risultato sarebbe stato più o meno lo stesso, ovvero la solita chilata di file markdown e il solito rendering. Certo, avere JSX al posto della sintassi Liquid è un grosso avanzamento, ma alla fine chi se ne frega.
Sono passati quasi dieci anni (melodrammatico: comunque più di otto). Adesso c’è altra roba in giro, e vedo tutti affannarsi a rincorrere il trend e riscrivere il primo sito che gli passa tra le mani nello static site generator del giorno. Tutti sembrano quasi aver dimenticato che Jekyll esiste, almeno da quella che è la mia percezione. Io nel frattempo ho imparato a scrivere plugin per Jekyll, e ho scrito il mio. Sicuramente i tempi di generazione sono biblici e si potrebbe fare in duecento modi migliori. Eppure c’è una parte di me che si sente estremamente bene nel non aver cambiato una virgola di come funziona il software che sta sotto questo blog in otto anni. Un po’ il detto ormai stantio, “choose boring technology”, un po’ il fatto che sul mio blog preferisco scrivere prosa rispetto al codice. Un misto di un po’ di tutto, anche di dimenticanza.
Perché alla fine secondo me l’indice di uno stack che ti soddisfa è questo, specie per qualcosa come un blog: ha valore quando te lo scordi. Per questo, senza alcuna vergogna, vi dico che questo blog da otto anni è generato tramite Jekyll, e non ho intenzione di cambiare una virgola di tutto questo almeno per altri quasi-dieci anni. :-D
30 Oct 2022
Tempo fa, il mio amico Marco mi ha inviato un libro dicendo che lo avrei trovato illuminante. Consentitemi uno spoiler: lo è stato. Quando ho iniziato a leggere The Five Dysfunctions Of A Team, di Patrick Lencioni, non avrei mai immaginato che nonostante la semplicità dei concetti esposti l’avrei trovato così “eye-opening”. Una delle cose che mi hanno colpito, per esempio, è stato il fatto che il paradigma che viene esposto funzioni a tutti i livelli, senza distinzioni, che si tratti di un team di exec che fa del prendere decisioni ad alto livello il proprio mestiere, o che si tratti di un team di sviluppatori.
O ancora, che si tratti di un team con competenze orizzontali.
Esattamente come The Phoenix Project, che ho letto ma che non ho più pensato di recensire (mannaggia a me), i teoremi vengono esposti in una forma narrativa piuttosto gradevole: la storia, piuttosto lineare, racconta di un team di exec che, posto di fronte a nuove sfide e sostanzialmente una compagnia che non riesce più a carburare, deve reagire e riassestarsi. Chiaramente è tutto posto in una chiave piuttosto didascalica, ma diciamo che il punto non è tanto quello di una bella storia, quanto di mostrare le criticità di un team disfunzionale e come superarle.
Le cinque disfunzioni in breve
In ordine di importanza, lungo il racconto Lencioni fa descrivere alla nuova “capoccia” del suo artificioso team di exec i principi disfunzionali che affliggono un team malandato, suddividendoli in delle lezioni essenziali. Questi sono:
- Assenza di fiducia;
- Armonia artificiale e assenza di conflitto;
- Mancato coinvolgimento delle persone nelle decisioni e mancanza di impegno;
- Mancanza di iniziativa dovuta alla mancanza di responsabilità;
- Focus eccessivo sull’ambito personale tralasciando il team.
Le soluzioni che vengono proposte sono molteplici, ma sostanzialmente il punto dell’opera è quello di battere sempre sugli stessi pilastri per fissarli in maniera indelebile. Lencioni rende in maniera clamorosa tutto questo, mostrando anche chiaramente la difficoltà delle persone coinvolte nell’accettare un altro tipo di mindset rispetto a quello a cui sono abituate.
Le soluzioni a queste cinque disfunzioni sono cinque pilastri, secondo l’autore, che dovrebbero portare un team a performare molto meglio e in maniera estremamente più fluida. In ordine, rispetto ai difetti elencati sopra:
- Ristabilire la fiducia, il rispetto, la tolleranza all’interno del team, soprattutto mettendo in evidenza le vulnerabilità di ognuno cercando di far passare il concetto per cui ogni componente del team ha bisogno dell’aiuto degli altri per massimizzare la sua personale possibilità di successo;
- Creare spazio per del conflitto costruttivo. Tantissimi tizi americani sono estremamente fan di quello che viene chiamato “radical candor”. Io penso che “radical candor” sia un modo socialmente accettato di fare gli stronzi, quindi non è che ci creda più di tanto: i feedback vanno anche saputi consegnare al destinatario. Viceversa, è assolutamente vero che tanti leader osteggiano il dialogo all’interno di un team. Bisogna ricordarsi però che dopo la mutua fiducia il dialogo è la risorsa più importante per il lavoro di gruppo.
- Coinvolgere le persone nelle decisioni crea un clima migliore, e favorisce l’impegno che tutta una squadra si può prendere rispetto a un traguardo. Volete un esempio? Provate a chiedere, in un team Scrum, a tutti i membri del team se pensano che il planning che viene fatto sia ragionevole. Di solito, nella mia esperienza, domandare questo alla fine di una sessione di planning crea un grosso senso di responsabilità condiviso. Non fatelo, e un domani vi troverete un team che sta in silenzio, vi lascia in balia dell’overcommitment, e buca gli sprint. Matematico.
- Rendere le persone responsabili delle proprie vittorie e dei propri errori favorisce azioni immediate per raggiungere il successo o evitare i burroni. Pensate che quello che ho appena scritto sia banale? Pensateci di nuovo. Una vostra vittoria è una vostra vittoria, o è una vittoria del vostro capo? Ve lo lascio come quesito da risolvere a casa. Potete mandarmi la risposta via mail. (Non sto scherzando: [email protected] se volete)
- Porre il focus costantemente sui traguardi del team e fare sì che il raggiungimento di questi si tramuti in crescita personale è la più grande delle sfide. Ma vale comunque la pena affrontarla.
Possono sembrare consigli da frasi dei cioccolatini o da biscotti della fortuna, eppure a me hanno aiutato recentemente a rimettere un sacco di cose in prospettiva, a indirizzare i miei manager nella giusta direzione ma soprattutto a capire i miei, di errori. Spero che leggiate questo libro e ne traiate gli stessi insegnamenti che ne ho tratto io, o anche di più: scrivetemi se trovate che abbia mancato dei punti. :-)
08 May 2022
Quando ho iniziato a leggere Chaos Monkeys, l’ho fatto consapevole del fatto che l’autore è un tizio estremamente controverso, il quale ha avuto notevoli conseguenze spiacevoli indietro dal suo libro anziché “la gloria” che un autore di un libro del genere, per come si pone in partenza, meriterebbe. In che senso, mi chiederete voi?
Vado a rispondere. È abbastanza pacifico intuire entro qualche capitolo dall’inizio che quella che è una storia di “oscena fortuna e fallimento casuale nella Silicon Valley” è in realtà il libro verità sulla Valley che chiunque dovrebbe leggere, almeno nella mente di Antonio García Martínez. È abbastanza scontato, di contro, che chiaramente alcuni passaggi siano esagerati e alcuni altri non siano credibili. L’idea che mi sono fatto tuttavia, e lo anticipo qui, è che nonostante parte del libro sia assolutamente squisitamente romanzata Chaos Monkeys sia davvero il libro verità sulla Silicon Valley, un posto dove ti basta un packaging carino per due righe di codice carine per prendere milioni su milioni di investimenti. E ovviamente, fare poi exit tramite acquihire lasciando a qualcun altro il padulo (sì, proprio lui) della gestione di una scatola il più delle volte contenente mota in quantità almeno eguale agli asset di valore della società.
La trama grossomodo è proprio questa, e si divide in tre atti:
- Il primo, in cui l’autore lavora per Goldman-Sachs ma si accorge di poter avere di più e si sposta in Silicon Valley;
- Il secondo, in cui l’autore fonda AdGrok, una startup che sostanzialmente fa un prodotto di gestione pubblicitaria per Google Ads (al secolo AdWords). Nota personale: il fatto che io abbia lavorato nel settore non ha fatto altro che aumentare il mio legame con questa parte della storia;
- Il terzo, in cui la startup di Antonio viene acquisita da Twitter (per acquihire, tra l’altro) ma lui con un sofisticato sistema di specchi e di leve riesce a tirarsi fuori dall’accordo e si fa assumere da Facebook come Product Owner nel ramo delle campagne pubblicitarie, esperienza che si rivela meno rosea del previsto.
Personaggi discutibili e modi di fare opinabili
La cosa che ho adorato di Chaos Monkeys è innanzi tutto una estrema demistificazione del modo di lavorare di Facebook, la cui company culture sarà sicuramente cambiata negli anni, ma di sicuro l’autore sa mettere a nudo il modo tipicamente nordamericano di condurre il business. Appena c’è una difficoltà, testa nella sabbia, identificazione del responsabile, licenziamento e via. Tutti puliti.
È meraviglioso leggere come la cultura di Facebook sia solo in parte legata alla parola magica “HACK” impressa all’ingresso dell’edificio principale della sede di Menlo Park tanto quanto nelle menti dei dipendenti, e invece almeno in maniera uguale sia connessa a un intricatissimo gioco di poteri e politiche che farebbe impallidire qualsiasi personaggio di House of Cards, The West Wing, o Game of Thrones. Andando più indietro, ho apprezzato tantissimo l’onestà nella condivisione dei risultati enormi raggiunti grazie a quella che in termini più lusinghieri viene definita “hustle culture”, e che qualsiasi persona di buonsenso chiama invece con due locuzioni molto precise che possiamo trovare anche nel nostro codice penale: circonvenzione d’incapace e truffa aggravata.
Apprezzo enormemente l’autore e la sua visione di sé come antieroe estremamente negativo all’interno della propria storia, una persona che non si ammanta di nulla se non dei propri ricavi, riuscendo così non solo a passarla liscia ai miei occhi, ma persino a suscitarmi una certa qual simpatia.
Le polemiche
Certamente non è un libro scritto nel rispetto delle minoranze o della diversità di genere. Lungo la lettura si incontrano sovente digressioni su quanto siano belle le receptionist di questo o quel venture capitalist, oppure quanto sia “geneticamente dotata” la ex compagna di Martínez. Capisco chi si è sentito in dovere di firmare una petizione per far licenziare l’autore dalla sua posizione in Apple, ma io personalmente ho apprezzato l’onestà. Oltre questo, fatevelo dire: è un libro scritto per generare questo tipo di reazione.
Quindi chiaramente se la prima reazione di fronte a certi stereotipi è l’indignazione, beh, ci state cascando con tutte le scarpe, e Martínez sta dimostrando ancora una volta di essere più intelligente di voi. Immaginatevelo nella sua poltrona al centro del suo flat a guardarvi e ridere di voi, così come ride di tutta la Valley.
Finalino
Always Be Hustlin’. Uno dei principi cardine di Uber, che non ho mai apprezzato. La hustle culture è qualcosa di veramente tremendo, che personalmente tendo a rifiutare. Nonostante questo, la storia di Antonio García Martínez mi ha catturato, svelto antieroe della Valley intento venticinque ore al giorno a lavorare per il proprio tornaconto raccontandosi in maniera romanzata, sì, ma mai stridente. Se volete farvi un’idea più precisa di come funzionano le startup della Silicon Valley e come ci si muove realmente in quell’ambiente, sicuramente Chaos Monkeys non può mancare nelle vostre librerie.
Sfortunatamente, non esiste una traduzione italiana.
