04 Nov 2019
Quante riflessioni si possono ancora fare sul tema blogging quando nel frattempo la Rete va a farsi friggere, nessuno è più padrone di niente, mastodonti dai nomi altisonanti si appropriano di contenuti che noi decidiamo di dargli per alimentare algoritmi che fanno solo la nostra infelicità e frustrazione? Diciamo infinite, e diciamo pure che io sono una persona semplice: Andrea fa un post su quanto è necessario prima ancora che fico e facile avere un blog alla fine di questo pazzo 2019, io banalmente lo riprendo e lo commento.
Tuttavia, nel mentre si aspetta una “riforma” delle piattaforme CMS, i creatori di contenuto devono e possono darsi una mossa. È tremendamente facile aprirne uno e non ci sono scusanti.
Addirittura “ai bei tempi” pensavamo che chiunque avrebbe aperto un blog. Per un periodo è stato così, grazie a Splinder e IoBloggo, o altre piattaforme simili; poi sono arrivati i “walls”, è arrivato Facebook, è arrivato Twitter, e tanti saluti a chi non solo non aveva voglia di mantenere uno strumento così complicato, ma non aveva nemmeno contenuti così “ad effetto wow” da condividere.
Così per tutto quello che nessuno vorrebbe leggere su un blog, per i nostri “garbage post” ci siamo rifugiati su piattaforme che non accentuassero la memoria delle nostre corbellerie, gettandoci a nuoto in un fiume in piena che porta via qualsiasi cosa consentendocene la visione solo poche volte, creando discussioni brevi e non approfondite. Forse il genere umano in maggioranza ha paura dell’approfondimento? Su Facebook è raro vedere un bel thread dove due persone evolvono la loro opinione in un dibattito normale. È raro persino vederlo nella vita normale. Ma in più di qualche occasione mi è capitato di leggere dei blog post e dei commenti a questi post veramente da cornice istantanea.
Qualche ragione stringata per cui un blog è una sfida con sé stessi:
- Il boxetto di Twitter o di Facebook crea meno ansia da prestazione e non ti dà quell’impressione da blocco dello scrittore che avrebbe l’utente medio di internet;
- Per via del punto di cui sopra, poco sforzo: zero customizzazione, scrivi “fart”, prendi qualche like, ti parte il picco di adrenalina masturbatoria da reaction su social network, e la giornata l’hai portata a casa;
- Le persone non hanno tempo di sedersi davanti al computer, darsi una calmata e fare/scrivere qualcosa di strutturato;
- A ben pensarci, forse le persone non ne hanno neanche voglia;
- Uscire dal gioco significa dire no a quello che non ti piace ma anche a quello che ti piace: quante persone smetterebbero di volere il like degli amichetti sotto il post del giorno?
- il successo di Instagram (e TikTok?) dimostra che la civiltà contemporanea che abita l’Internet propende per immagini, spesso senza un senso associato e senza una caption strutturata, perché scrivere è troppo sforzo e leggere lo è altrettanto.
Eppure dal mio punto di vista avere un blog (o molti blog – se si scrive tanto e di svariati argomenti) è fichissimo, anche se per esempio nemmeno io riesco a scriverci quanto vorrei.
- Hai spazio per contenuti strutturati;
- Sei costretto a rileggerti se hai scritto una cacata;
- Puoi eventualmente scrivere cose brevi e nessuno ti sparerà per questo;
- Ti guardi allo specchio: mentre scrivi vieni profondamente a contatto con quello che pensi di un determinato argomento, e lo discuti prima di tutto con te stesso;
- Come Alan Jacobs consiglio l’elderblog sutra di Venkatesh Rao. Sono riflessioni interessanti, io stesso non ho avuto ancora il tempo di leggerle e metabolizzarle tutte.
Alan ha ragione:
So one of the things I want to be thinking about is: How can I encourage readers of my blog to seek some of the benefits that I get from it?
13 Oct 2019
Oggi ho letto questa frase interessante su un post di Marco:
fare carriera in ambito manageriale da un lato fa schifo, dall’altro offre un sacco di opportunità di fare la differenza. Un po’ come crescere.
Mi ha fatto riflettere parecchio, principalmente perché arriva in un momento della mia vita professionale in cui sono estremamente indeciso sul percorso da affrontare di qui a poco. In maniera speciale riguardo il dilemma se continuare su una traccia puramente tecnica, o puntare a qualche ruolo di people management.
Grazie Marco.
13 Oct 2019
Gergely Orosz, qualche giorno fa (e se non seguite il suo blog ve lo consiglio caldamente):
[…] “bad code” is a lazy expression. It’s not specific and means different things to everyone.
Suggerisce quindi alcuni consigli quando si arriva a criticare del codice in maniera sana suggerendo un refactoring o direttamente in fase di scrittura. Come sempre l’interazione coi compagni di team risulta cruciale:
- Be specific
- Give a specific suggestion
- Talk about the future implications of the code you see, if not changed
- Ask the person writing the code, what they think about your comments
Sono tutti consigli giusti, e sono tutti principi che metto in pratica costantemente e che impattano sulla qualità finale del codice. Mi sento di aggiungerne uno mio in coda: se qualcosa ti sembra generalmente debole, i tuoi commenti non vengono apprezzati, o banalmente non c’è tempo e le cose stanno funzionando in questo stato di precarità, copri quella funzione infame con una suite di test. Questo permette di metricare “quanto” effettivamente un pezzo di codice è prono a rompersi, attraverso test stressanti (quindi copertura dell’happy path e due/tre altri casi più “tricky”) che rendano più sicura l’evoluzione della codebase tangente quella funzione, quel metodo, quell’oggetto che stiamo prendendo in esame.
A quel punto non c’è niente da fare: una test suite scritta bene parla per te, e funge da dimostrazione euristica che le tue preoccupazioni sono infondate, oppure che c’è qualcosa che va aggiustato immantinente.
A quel punto se il test infame continua a rompersi, beh: non è un problema tuo no? Anzi: in fase di riscrittura o in generale di miglioramento, avrai le spalle coperte dal te stesso del passato.
13 Oct 2019
Un post recente di ThoughtBot riguardo i messaggi privati nei tool di comunicazione aziendali e non:
Private messages silo information, which means either people have to repeat themselves or others miss out on the conversation. When you don’t allow others the chance to participate, everyone misses out on an opportunity to learn from each other.
Nell’eventualità in cui Bob e Alice vogliano scambiarsi un messaggio, a meno che non sia qualcosa di estremamente faceto come una lista della spesa, o un paio di raccomandazioni su qualche posto dove mangiare a New Orleans, la vedo dura che un messaggio mandato in un canale pubblico sia oggettivamente di poca utilità. La vedo altrettanto dura che incoraggiare l’atteggiamento opposto, ovvero discutere di tutto in privato, sia produttivo sia per il team che per l’azienda.
Di solito quello che viene a crearsi è un sapere frammentato in insiemi delle parti.
Di seguito quindi le mie raccomandazioni riguardo la comunicazione asincrona per i lavoratori del digitale e non, remoti o on-site che siano:
- Manager/Leader: questo tipo di figure si dovrebbero assumere il compito di facilitare la comunicazione attraverso atteggiamenti concilianti e la diffusione di blameless culture. Allo stesso modo non dovrebbe far sentire gli altri costantemente osservati dall’occhio di falco del capo.
- Worker: chi mira a lavorare in un ambiente di questo tipo non dovrebbe avere paura di sentirsi osservato, perché sarebbe estremamente scorretto da parte di chi sta più in alto nell’organizzazione strumentalizzare i messaggi per usarli in altri tempi e altre sedi.
Team che affrontano i problemi di comunicazione usando l’approccio opposto devono prepararsi ad affrontare una serie di effetti collaterali dovuti ai silo che si creano per via di questo tipo di attività.
Il 99% dei team che ho preso in esame nella mia vita lavorativa, alla fine dei giochi, non erano pronti ad affrontare questo tipo di side-effect.
Lascio a voi l’esercizio di immaginare le conseguenze.
01 Sep 2019
Ho iniziato a leggere un thread affascinante su LWN, in ripresa di un post piuttosto lungo sul blog di Packt:
Systems programming often involves low-level manipulations and requires low-level details of the processors such as privileged instructions. For this, Rust supports using inline Assembly via the ‘asm!’ macro. However, it is only present in the nightly compiler and not yet stabilized. Triplett in a collaboration with other Rust developers is writing a proposal to introduce more robust syntax for inline Assembly.
Non penso che il punto sia rendere obsoleto C quanto ormai è obsoleto Assembly. Casomai, penso che il punto sia ridare dignità a ognuno di questi strumenti nel modo migliore. Rust è un ottimo rimpiazzo di C per quanto riguarda la programmazione di sistema, soprattutto quando vengono meno determinati bisogni (ovvero restrizioni dovute alla memoria che puoi avere su determinati chippetti). Assembly, viceversa, è un tool che a meno di assurde invenzioni non è possibile sostituire.
Rust indirizza tutti questi bisogni in una maniera estremamente elegante, unendo una sintassi estremamente efficace, tooling ottimo, soprattutto moderno, e alcune finezze funzionali che lo rendono il mio primo candidato quando si tratta di piccoli programmi.
Il thread su LWN è veramente ricco di spunti, ve lo raccomando. Per esempio dal commento di Archimedes:
cargo as build system is “nice and simple” and can handle a lot but falls short if complex builds are needed which can be done in C using the automake/autoconf, cmake, … hell …
Questo evidenzia una giovinezza in alcuni aspetti del tooling legato a Rust, e anche degli aspetti in cui la catena di montaggio attuale si può migliorare a tal punto da servire come punto d’appoggio per una brand awareness fortissima da parte di aziende che decidono di scrivere larga parte del loro software in Rust, e sentono questo tipo di necessità.
Poi non venite a dire che non ve l’ho detto. ;-)
