Alessio Biancalana Grab The Blaster di Alessio Biancalana

2023: so it begins

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.

Creare Mondi 2021/2022

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.

Io e Agnese vi auguriamo un ottimo inizio d'anno

This blog is shamelessly powered by Jekyll

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

Recensione: The Five Dysfunctions Of A Team, di Patrick Lencioni

Le cinque disfunzioni di un team

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. :-)

Recensione: Chaos Monkeys, di Antonio García Martínez

Chaos Monkeys: recensione

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 exit1 tramite acquihire2 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 pubblicitarie3, 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.

  1. La exit si verifica quando un fondatore o generalmente un imprenditore “esce” dalla sua creatura con dei soldi. Può accadere tramite liquidazione del socio, tramite acquisizione, in moltissimi modi insomma. Io sono un programmatore, quindi ne posso parlare solo sommariamente: per sapere meglio cos’è una exit e come farne una di successo, chiedetelo a un amico commercialista. O se volete farvi due risate, tutti abbiamo un amico CEO presso se stesso. Chiedetelo a lui! Vi divertiranno le risposte. 

  2. Generalmente l’acquihire si verifica quando una società più grande acquisisce una società più piccola principalmente per l’expertise del team di sviluppo. È come un gigantesco e superveloce processo di reclutamento, dove vengono assunte cinquanta, cento persone invece che una alla volta. Il prodotto su cui l’azienda più piccola lavorava viene di solito gradualmente strangolato, mentre la società più grande mette il team a lavorare altrove. 

  3. Anche qui, il fatto che io abbia un’esperienza lavorativa in quel dominio non ha fatto altro che aumentare la mia personale simpatia nei confronti di Martínez. 

Un pezzo sul lavorare gratis a cui non riuscivo a trovare un titolo

Bazzicando Livello Segreto mi è saltato all’occhio un post in cui Lorenzo pubblicizzava il suo ultimo articolo riguardo il lavorare gratis e la narrativa del lavoro pagato non in moneta sonante, che aiuta a pagare le bollette, ma in esperienza. Un po’ come quando un po’ di tempo fa la gente si sognava di chiedere cose assurde pagando “in visibilità”.

Lungi da me dare ancora visibilità a gente che di scempiaggini ne ha dette già troppe: in ogni caso è ormai ricorrente ogni tot mesi che arrivi qualche benpensante a sciorinare la sua rispetto al fatto che i giovani ultimamente non hanno voglia di fare nulla, non hanno minimamente intenzione di investire sul proprio futuro tanto che, incredibile (!), desiderano persino uno stipendio per mangiare qualcosa la sera.

È un discorso che sia io che Lorenzo, appunto, abbiamo visto e sentito spesso. Si applica alla cucina di un ristorante stellato, si applica alla redazione di un giornale famoso, si applica persino alle big corp americane di cui tutti i giorni utilizziamo il software: ho visto coi miei occhi aziende di cui non immaginereste mai questo atteggiamento provare a negoziare un salario relativamente basso solo perché “heyyyy, ma è la Silicon Valley babe, lo sai quanto vale un’esperienza qui?” - ebbene, è vero che le esperienze non sono tutte uguali e alcune contano più di altre, ma è altrettanto vero che le hard skill hanno un costo materiale e oggettivo sul mercato. E soprattutto, rispetto a quando magari un sessantenne o un cinquantenne di oggi poteva permettersi di rinunciare a una cena fuori in favore “dell’esperienza”, per quanto sbagliato in generale sia, l’inflazione galoppante ci ha portati a un punto di non ritorno dove il mercato del lavoro ci vede necessariamente col coltello tra i denti.

Scusate, datori di lavoro!

Investire: quando si può

C’è un mondo da dire riguardo il “lavorare per l’esperienza”, ma Lorenzo ha riassunto il tutto abbastanza bene:

L’altra volta dicevamo che a volte non sei il più bravo, il più veloce o il più preciso, sei quello che ha resistito di più, che è rimasto e si è fatto trovare al momento giusto e al posto giusto col bagaglio di competenze giuste. Ecco, il sistema prevede che per essere quella persona tu possa permetterti di resistere, o di essere così ricco e ben inserito che la tua eventuale bravura può essere notata grazie alle giuste conoscenze e alla serenità di scrivere senza dover pensare ai sacrifici fatti dalla vostra famiglia.

E per resistere devi poter non pagare molte spese prima le cose inizino a girare, devi poterti magari permettere anche dei corsi di comunicazione che oltre a formarti hanno il grande pregio di farti iniziare a frequentare ambienti in cui, se vali qualcosa, magari ti notano, e quei corsi costano.

Insomma, quando sentiamo questi ragionamenti è il segnale numero zero che siamo di fronte a una persona col bias del sopravvissuto fin sopra le orecchie. E non solo.

Come investire su se stessi nel software engineering

Se Lorenzo ci dice abbastanza schiettamente come investire su di sé nel mondo del giornalismo:

Volete scrivere gratis per fare esperienza e perché altrimenti non vi potete costruire un portfolio? Benissimo, apritevi un blog, fatelo con più persone e fondate un magazine come N3rdcore ma per dio se qualcuno mette dei banner e lucra sui vostri click non regalategli il vostro tempo.

Investire su di sé nel mondo del software engineering è qualcosa che va di pari passo, e anche se sembra scontato non lo è: non abbiamo alcun bisogno di essere sfruttati da aziende dimora di incompetenti per ottenere visibilità ed esperienza costruendo un sito brutto, avendo magari a che fare con stakeholder ancora più incompetenti. L’ecosistema open source ci permette di cominciare a farci il bagno con tutte le pratiche che potenzialmente faranno parte del nostro futuro lavorativo, e senza che nessun manager con la frusta stia lì a guardare quante ore sottopagate stiamo seduti su una sedia scadente in un ufficio in cui dobbiamo andare per forza perché - hey - mica vorrai lavorare da remoto.

Come al solito ricordiamo che i contributi a un progetto open source possono essere:

  • Traduzioni;
  • Documentazione;
  • Segnalazione bug;
  • Pacchettizzazione;
  • Triage (ovvero una persona si mette lì a capire a capo chino quale bug è più importante di un altro);
  • Design;
  • Solo in ultima istanza: codice.

L’aspetto migliore? Presto detto: un level up della nostra carriera e delle leve negoziali di cui disponiamo, senza nemmeno aver iniziato a lavorare. Con la libertà di poter decidere noi l’investimento che possiamo fare su noi stessi. Di solito quello che succede con un progetto tradizionale commerciale di tipo tossico è un approccio all-or-nothing, ovvero se non puoi dedicare otto ore al giorno a un lavoro sottopagato non ottieni né la paga (magra), né l’esperienza (scadente. Fidatevi: scadente).

In un’organizzazione dove il progetto è aperto e noi siamo dei contributor individuali occasionali, siamo noi a controllare il quantitativo di tempo che dedichiamo al progetto. Se abbiamo un esame all’università, possiamo prenderci una pausa. Se abbiamo bisogno di una giornata libera, nessuno ci correrà dietro (e vorrei vedere: è volontariato). Il nostro curriculum però ne uscirà smagliante.

A differenza di quelli che hanno lavorato gratis per la web agency di quartiere.

Member of

Previous Random Next