Alessio Biancalana Grab The Blaster di Alessio Biancalana

Bandiere, ruoli e workaholic

Oggi sono finito sull’about di Marco Arment per caso, e subito dopo su questo post (che parla della crescita di Tumblr, linkato nel titolo come sempre) che paradossalmente nonostante la mia ammirazione per lui non avevo mai letto. Fornisce degli spunti di riflessione a mio parere veramente buoni sull’operato di un CEO di un’azienda di prodotto, sul ruolo di un tecnico quando si parla di crescita dell’azienda, e su tante altre cose. Per esempio il posizionamento.

MySpace was where you went in the past, WordPress and Movable Type were where people went if they had the patience and writing output to maintain a traditional blog, Facebook was where you went to define yourself by schools and checkboxes, and Tumblr was where you went to make your own identity and express your creativity.

Mi sono anche rivisto parecchio nel ruolo di Marco come “esecutore di idee”; di base io sono una persona che ha molte idee storte, ovvero che non possono essere accoppiate a un valore di business. Viceversa mi piace molto scrivere codice elegante e costruire prodotti dando il mio contributo soprattutto in maniera tecnica, rifinendo un’idea preesistente:

David always had a vision for where he wanted to go next. I was never the “idea guy” — in addition to my coding and back-end duties, I often served as an idea editor. David would come in with a grand new feature idea, and I’d tell him which parts were infeasible or impossible, which tricky conditions and edge cases we’d need to consider, and which other little niceties and implementation details we should add. But the ideas were usually David’s, and the product roadmap was always David’s.

E in questo post ho anche trovato la più fedele riproduzione del mio pensiero riguardo il lavorare sotto un workaholic (perché me ne sono trovati diversi davanti nel tempo).

David always obsessed over his newest ideas, features, and designs until they were completely polished and ready to go. He’s a workaholic […] He expects people around him to be similarly into work and Tumblr, and often drove me hard with seemingly impossible demands. But David has a lot of Steve Jobs-like qualities, and like many people who worked for Steve, I look back on Tumblr’s crunch times with mixed feelings: I don’t want to return to that stress level, but David pushed me to do amazing work that I didn’t think was possible.

Certo, a me piace prendermi delle libertà. Non sono il tipo che si ammazza di lavoro, ma mi piace arrivare al traguardo in fretta con un buon prodotto. Per quanto sia deprecabile un atteggiamento che ti spinge a sovraccaricarti, comunque la realtà dei fatti è che a volte se il risultato sperato viene raggiunto pienamente ci si ritrova tutti più uniti come squadra. Questo non significa che ci sia sempre necessità di lavorare in questo modo, anzi; e dall’esperienza di Arment come lead developer, almeno per come la racconta lui, ho capito che per me non c’è niente di meglio che avere un goal fissato, formare una squadra, e dire “ok, quella è la bandiera: andiamo a prendercela”.

Prescindere da C nel 2016 – è possibile?

Purtroppo sono giornate veramente impegnative, per cui ho modo di scrivere poco, poco, poco. Per via di esami universitari e (sinceramente) un pizzico di diletto personale tuttavia mi sono trovato a scrivere di recente del codice C; e, riguardo questo, dato che C non lo toccavo da un po’ di tempo, oltre a leggermi The Linux Programming Interface di Michael Kerrisk, ho anche letto sia How To C (As Of 2016) che la rispettiva critica che ne è seguita. O almeno una delle più quotate :-)

Programmando programmando, mi sono chiesto: “ma è veramente possibile prescindere da C nel 2016?” – e beh, la mia risposta è che no, non possiamo. Non possiamo per una serie di ragioni, prima di tutto perché comunque conoscere il basso livello è importante per chiunque, per imparare che una macchina è un cuore pulsante di metallo e bit, quindi è bene (qualsiasi che sia il livello di astrazione) imparare a scrivere codice con criterio al fine di gestire le risorse in maniera non-cinobalanica. Probabilmente C come linguaggio e le tecnologie embedded come “target” insegnano più di tutto il resto come affrontare le problematiche con un approccio orientato al risparmio di risorse; non è la panacea ad ogni male, ma è sicuramente qualcosa che un programmatore deve conoscere e saper sfoderare alla bisogna.

E poi perché, diciamocelo, moltissimi runtime sono scritti in C (o C++), e sicuramente il C è ancora un linguaggio “fashioned”, dato che serve conoscerne quantomeno una fetta. È bello che ultimamente si stia riscoprendo “la gioia” del linguaggio compilato: negli ultimi anni c’è stato un rifiorire di tecnologie che permettono di avere molta potenza per le mani anche a basso livello. Il C, tuttavia, non è da dimenticare per nulla – anzi.

Negli ultimi giorni ho persino scritto un po’ di Makefile, dato che casualmente non l’avevo mai fatto :-D sto preparando un tutorial per niubbi, che poi pubblicherò. State tonnati.

Documentation first

Ancora un’altra frase iconica di Joey Hess, giuro che poi la smetto.

I write documentation first and code second.

Joey Hess e l'impegno come Debian Developer

Durante la piccola carrellata di post che ho attraversato scrivendo il piccolo (ed ennesimo) rant contro l’abuso delle riscritture delle history di progetto su Git tramite l’uso di git squash, ho letto qualche intervista in più a Joey Hess. In particolare mi ha attratto molto questa coppia di frasi:

I seem to have more time to spend in other online communities since I left Debian, but in a more diffuse way. Maybe that’s just what it’s like, to be involved in Free Software but not in the embrace of a big project like Debian.

Ho alzato le sopracciglia, principalmente per una ragione: l’affinità con il development sulla distribuzione di Joey ha attraversato le stesse fasi che ha attraversato la mia, suppongo. Avevo 50 pacchetti su AUR per Arch Linux, alcune mie cosette sono persino nei repository della distribuzione, eppure un giorno ho fatto “disown” di tutto, e ho lasciato il campo libero a chiunque volesse adottare la mole di roba che avevo da fare (che non era comunque troppa).

Da un momento all’altro ho sentito come di dover avanzare verso altro. Alla fine le community, i progetti open, io li vedo come luoghi dove una persona può passare grande parte del suo tempo, ma alla fine deve andar via verso una nuova avventura per affrontare un nuovo viaggio. La scelta di rimanere, che il luogo sia del codice o una distribuzione Linux, o qualsiasi altra cosa inerente l’open source, è una scelta forte; e ritengo che pensare di rimanere per sempre maintainer di un software, di un pacchetto, o di che altro, sia abbastanza degno di un Tacchino Induttivista.

Git squash, log riscritti, bazooka e mosche

Ieri sera, ho beccato sul feed reader un elemento che ha catturato immediatamente la mia attenzione; Matthew Garrett infatti ha esibito quanto fastidio possa dare l’impossibilità di comprendere il lavoro delle altre persone dovuta allo squash dei commit sulla history di un progetto Git, specialmente se tutto questo accade all’interno di un progetto open source:

I’ve got some familiarity with Kubernetes, but even then this commit is difficult for me to read. It doesn’t tell a story. I can’t see its growth. Looking at a single hunk of this diff doesn’t tell me whether it’s infrastructural or part of the integration. Given time I can (and have) figured it out, but it’s an unnecessary waste of effort that could have gone towards something else. For someone who’s less used to working on large projects, it’d be even worse. I’m paid to deal with this. For someone who isn’t, the probability that they’ll give up and do something else entirely is even greater.

Il punto che spesso mi piace sottolineare è messo a fuoco in modo spettacolare da Joey Hess, nel titolo stesso di “Our Beautiful Fake Histories”:

Beautiful fake histories. Because coding is actually messy; our actual edit history contains blind alleys and doublings back on itself; contains periods of many days the code isn’t building properly. We want to sweep that complexity away, hide it under the rug. This works well except when it doesn’t, when some detail airbrushed out of the only remaining history turns out to be important.

Ed è veramente così. Chiaramente c’è un sacco di Work In Progress di cui fare tanta pulizia alle volte, ma mi sembra che l’attenzione verso la history di un progetto sia portata alla luce da certi personaggi in maniera maniacale, come se fosse l’unica cosa di cui preoccuparsi, quando probabilmente l’unico vero paletto dovrebbe essere la qualità del codice. Il pattume nel log di git lo possiamo lasciare alle retrospettive, o comunque ad altri momenti del flusso di lavoro, che il progetto sia aperto o chiuso.

Onestamente, penso che chi passa il tempo a urlare contro le persone perché facciano rebase della propria history sia solo un incapace a cui piace mettersi in mostra senza mettere sul piatto nulla di tecnico se non paura e terrore instillato nei confronti di chi potrebbe contribuire in maniera più rilevante a un qualsiasi progetto. Alla fine, invece, quello che si ottiene è solo l’allontanamento di molti dal progetto stesso. Su un progetto open source smetteranno di contribuire. Su un progetto lavorativo, le persone troveranno (o inventeranno) altri task per allocarsi altrove.

Sulle persone che amano fare sceneggiate di questo tipo, Daniel Robbins ne dà un buon excursus durante “Costruire Una Distribuzione”. Cercate la parte sugli “strani”.