Una questione di stile
Scritto

Non conosco developer che non ridano della cosa tipicamente nostra di perderci in coversazioni inutili su temi irrilevanti. Eppure non conosco developer che non si siano ritrovati ad avere una di queste conversazioni, spesso animate, sempre inutili.

Tanto che la pratica ha un nome: bike shedding.


Mettetevi comodi che è una storia lunga.

Se non siete sviluppatori non spaventatevi: ho qualche termine tecnico qua e là ma non serve per la comprensione dell'aneddoto, è solo per rassicurare i veri nerd™️ e farli sentire a loro agio mentre parlo di Interpersonal Skills 1 .


Da quasi un anno sono il manager di un team in cui sono rappresentate varie discipline. Uno dei componenti del team, che chiameremo Renzo, è un data engineer che scrive in Python e si occupa estrazione/manipolazione/qualsiasicosazione dati.

Recentemente Renzo ha mostrato interesse nell'espandere i suoi orizzonti: vuole iniziare a contribuire alla codebase principale del team – un monorepo di servizi serverless scritti in Javascript.

// nerd alert: il prossimo paragrafo è tecnico

La nostra codebase è stata ereditata da un team di contractor e ha un'impostazione fortemente funzionale, e con un utilizzo massicio di Ramda – una libreria che, piaccia o meno 2 , dovrebbe rendere la cosa più semplice. Tra funzionale e Rambda, il codice è sostanzialmente illeggibile 3 . La nostra azienda ne aveva già iniziato la rimozione da altri progetti. Quindi ci siamo felicemente adeguati.

Quale occasione migliore da offrire a Renzo: una serie di funzioni ben testate scritte in Rambda da riscrivere in plain javascript. Piece of cake.

// end nerd alert

Alla seconda PR 4 , Renzo ha iniziato a sentirsi a suo agio ed ha presentato una serie di cambiamenti abbastanza corposi che hanno richiesto varie tornate di feedback. Col senno di poi avremmo fatto bene a chiedergli di spezzettarla, ma ormai eravamo in gioco 🤷‍♀️

Renzo nel tempo ha iniziato a frustrarsi per il numero di richieste di cambiamento da parte del senior dev nel team, chiamiamola Antonella, e a diventare difensivo rispetto alle sue scelte, specialmente quando si trattava di stile 5 .

Dopo un certo numero di botta e risposta, rendendomi conto che la situazione stava lentamente degenerando, mi son messo in mezzo e gli ho chiesto di adeguarsi, promettendo di sederci a un tavolo alla prima occasione buona per parlare del code style.


Siamo un team relativamente nuovo, non abbiamo mai ridiscusso le regole imposte dai contractor da cui abbiamo ereditato il tutto, e finora io e Antonella abbiamo guidato le scelte, un po' per esperienza, un po' perchè ci siam beccati in termini di idee su come gestire il codice, un po' perchè gli altri componenti del team non avevano abbastanza esperienza per proporre alternative.


Al meeting, ieri, abbiamo fatto un esercizio in cui in una 10ina di minuti dovevamo individuare i pain points della nostra codebase e fare una lista delle nostre "strong opinions".

Antonella e io ce ne siamo usciti con una serie di cose abbastanza simili, la principale delle quali era "se me lo chiedi, qualcosa da dire ce l'ho, ma alla fine non me ne frega nulla, a patto che ci sia un tool che imponga le regole e che non dobbiam stare a discuterne mai più nella vita: I'm too old for this shit".

Salta fuori che Renzo, invece, non solo non è d'accordo con molte idee uscite da noi due, ma addirittura non vuole che ci sia una serie di regole pre-impostate e che una PR possa venir rifiutata sulla base di dette regole, che considera arbitrarie.


Questa rivelazione mi coglie impreparato: i motivi per avere degli standard in un contesto in cui devono contribuire più persone sono abbastanza comprensibili anche senza un background tecnico.


La mia reazione iniziale è di incazzo: ci son modi molto migliori di spendere il tempo di tutti senza dover ripartire dalle basi e Renzo ha più esperienza di così, magari non nel linguaggio in questione, ma è un developer con un po' di esperienza...

Dissimulo elegantemente e affermo che che ci sia è non negotiable, ma che vorrei capire bene il punto di vista, perchè ritengo che l'opinione di tutti abbia valore. Propongo quindi un follow up solo con un paio di persone – Renzo e un'altra componente del team con altre opinioni un po' eccentriche – e chiudiamo la sessione, ormai giunta al termine.

Renzo mi scrive in privato di lì a breve dicendo che non capisce a cosa serva un altro meeting, se ho già deciso e se comunque c'è già una maggioranza. Ribadisco, tra un meeting e l'altro, che per me è importante capire il punto di vista delle persone nel team, non solo il prendere decisioni a colpi di maggioranza: bisogna sì prendere la decisione, e se non si trova l'unanimità è parte delle mie responsabilità prendere la decisione che reputo la migliore per il progetto, ma questo non significa calpestare le opinioni altrui. Ribadisce che non capisce che senso abbia.


Un'inciso, nonostante la lunghezza del post, è necessario.

In passato son stato control freak, molto control freak, e se un qualsiasi developer mi avesse detto che non voleva una styleguide lo avrei mandato in culo. Sereno, senza pensarci o ripassare dal via. Ora son a un punto della mia vita in cui capisco che un'affermazione del genere da qualche parte viene, e voglio capire da dove. O, se volete dirla in modo diverso: qual è il trauma che ti porta ad avere questo tipo di opinione su un tema talmente consolidato e "banale", se vogliamo.

In ogni azienda, in ogni progetto open source con un livello minimo di maturità ci sono regole di ingaggio, e per contribuire è necessario adeguarcisi, è incomprensibile come un professionista possa suggerire che non dovrebbero esserci.

Trovo la posizione immatura e inutilmente provocatoria


Uno dei vari meeting che ho avuto ieri mattina è stato un 1:1 col mio capo, che chiameremo Ester.

Ester è una manager da cui sto imparando tanto: ha una capacità incredibile di leggere le situazioni e le persone coinvolte, e nel formulare i pensieri in modo da ridurre le possibilità che vengano malinterpretati.

Parliamo di varie cose, dopodichè le menziono l'aneddoto, più come un FYI che altro. Dopo aver concordato sulla immaturità della posizione di Renzo, inizia a farmi una serie di domande aperte, ma centrate, su Renzo e mi porta a considerare sulla possibilità che in realtà sia solo estremamente insicuro.

Se Renzo si è sentito attaccato da Antonella, potrebbe aver sviluppato questa posizione perchè si sente in un angolo. In questo caso, insistere perchè spieghi la sua posizione non porterebbe a nulla, perchè potrebbe non averne una, il che finirebbe per radicalizzare la sua difensività.

Scrivo a Renzo, gli dico che alla fine non voglio forzarlo in un meeting che ritiene inutile, ma che vorrei comunque trovare un momento nel prossimo faccia a faccia per chiudere la questione. Accetta, la situazione si rasserena, parliamo dei suoi piani per il prossimo paio di giorni, in cui è in ferie.

I miei talking point per il 1:1 con Renzo saranno relativi non tanto a discutere nuovamente la questione, ma a prendere una posizione chiara, che è: mi spiace che non ci sia una linea comune, ma che ho la responsabilità di garantire la qualità del progetto e che non possiamo metterci a ridiscutere degli standard che sono ormai consolidati, di fidarsi di chi ha lavorato in Javascript per più tempo e sa i pro e i contro del linguaggio e, per favore, di accettare il fatto che anche se non è la scelta che avrebbe fatto lui mettersi di traverso non aiuterebbe il team e il suo sviluppo personale. Sostanzialmente di comportarsi in modo professionale, senza dirlo espressamente per non implicare che non lo stia facendo – e in effetti non lo sta facendo, per ora la conversazione per quanto ai limiti dell'assurdo è stata assolutamente nei binari della professionalità.

Vedremo come andrà.


Sì, ma... quindi?

Dopo sto pippone, io porto a casa un paio di cose utili:

  • se il rubber ducking funziona col codice, provate ad applicarlo a problemi interpersonali: gli umani son infinitamente più complessi delle macchine e avere qualcuno – o, in mancanza, qualcosa – con cui condividere un problema, permette di elaborarlo più in profondità.
  • a volte è difficile capire da dove vengano o dove siano le persone: la mia attenzione era talmente centrata sul fatto di voler ascoltare cosa Renzo avesse da dire, che non ho nemmeno considerato la possibilità che magari non avesse niente da dire e che insistendo su quanto era importante che io, manager, lo ascoltassi, non facevo che metterlo ancora più sulle spine.
  • parlare di coding style è una mossa rischiosa, sarebbe meglio – e provvederò a farlo – parlare di conding principles 6 , lo stile diventa una conseguenza e non il punto del contendere

1. https://www.youtube.com/watch?v=4F4qzPbcFiA

2. decisamente "o meno", molto "o meno"

3. litighiamo un'altra volta sul funzionale estremo, ho le mie ragioni per pensarla come la penso, stacce.

4. per i non nerd, forse questo è l'unico termine che serve imparare: la Pull Request è il modo in cui noi sviluppatori comunichiamo gli uni con gli altri. Quando un dev dice "ti mando una PR", significa "gentile collega, potresti dedicare un po' del tuo tempo prezioso a quello che ho scritto e dirmi che ne pensi in modo che entrambi possiamo crescere nella nostra comprensione del problema e di come meglio risolverlo?" e l'altro te l'approva o richiede modifiche. In un mondo perfetto una PR raccoglie critiche costruttive che servono al ricevente per crescere o domande/risposte che servono a capire il contesto in cui vengono introdotti i cambiamenti. Entrambi i partecipanti ne escono arricchiti. In un mondo perfetto.

5. per i nerd: lo stile è ovviamente enforced da eslint e prettier, qui si parla di stile un po' più ad alto livello e cose che, avendo ereditato la codebase da contractor non eravamo poi andati a guardare – tipo usare metodi con valore semantico per iterare, tipo map e foreach, invece dei for/while, il nome delle variabili, quando e cosa abbreviare vs lasciare i termini estesi etc.

6. per esempio: la priorità è scrivere codice leggibile e manutenibile o  le performance non sono un problema finchè non lo diventano e cose così – ovviamente ogni progetto o team avrà le sue priorità.