6 consigli per lavorare bene in team

Mentori

Come di consueto negli ultimi anni, qualche settimana fa abbiamo avuto un incontro tra i leader tecnici a tema «sviluppatori junior nel team». La sessione è stata piuttosto lunga per essere riassunta in un blog post, però è iniziata con un esercizio interessante: «trova alcuni aspetti dei tuoi mentori – quando hai iniziato a programmare – che ricordi in modo positivo».

Dopo averci pensato un po’, sono arrivato a questo elenco:

• pazienza
• indicazioni di massima
• pensiero laterale
• capacità di semplificare
• costanza nel prender nota di decisioni / riunioni
• capacità di organizzare il proprio lavoro

Vediamo un po’ perché penso che queste caratteristiche siano preziose per un mentore.

Pazienza

Ho iniziato a “programmare” abbastanza giovane, mio padre era un programmatore e ho avuto accesso a un 8088 subito dopo una macchina Apple II (che ho usato solo come utente, giocando con il leggendario choplifter!)

da destructoid.com

Ricordo di aver chiesto qualcosa come un milione di volte il nome di una parola chiave o il nome di un programma (o talvolta solo l’ortografia corretta) e ho sempre avuto una risposta calma, come la prima volta.

Indicazioni di massima

Ho iniziato a programmare in Visual Basic e poi in PHP, scrivendo software gestionale, quindi niente di complesso, tante interfacce grafiche, dati da manipolare, un po’ di logica aziendale.

Per fare un preventivo per un nuovo progetto mi è stato suggerito di contare le maschere e stimare il progetto in base a esse. E funzionava abbastanza bene, a volte una finestra semplice “copriva” una logica aziendale più complessa, a volte l’opposto.

L’indicazione di massima era: quando il problema è complesso, scegli una strategia per dividerlo.

Non importa quale strategia tu abbia scelto, il valore principale è quello di suddividere il problema in parti più gestibili.

Un altro esempio di questo tipo di insegnamento è lo «Zen di Python»:

import this # [ndr. tradotto dall’inglese]
Lo Zen di Python, di Tim Peters
Bello è meglio che brutto.
Esplicito è meglio che implicito.
Semplice è meglio di complesso.
Complesso è meglio che complicato.
Piatto è meglio di nidificato.
Sparso è meglio che denso.
La leggibilità conta.
I casi speciali non sono abbastanza speciali da infrangere le regole.
Sebbene la praticità superi la purezza.
Gli errori non dovrebbero mai passare silenziosamente.
A meno che non sia esplicitamente messo a tacere.
Di fronte all’ambiguità, rifiuta la tentazione di indovinare.
Dovrebbe esserci un – e preferibilmente solo un – modo ovvio di farlo.
Anche se quel modo all’inizio potrebbe non essere ovvio a meno che tu non sia olandese.
Adesso è meglio che mai.
Anche se mai è spesso meglio di *proprio* adesso.
Se l’implementazione è difficile da spiegare, è una cattiva idea.
Se l’implementazione è facile da spiegare, potrebbe essere una buona idea.
I namespace sono una grande idea: usiamone di più!

Queste regole sono troppo vaghe per essere direttamente applicabili ma sono abbastanza chiare da dare una direzione.

Un’altra regola che cerco di rispettare riguarda l’applicazione della regola EAFP: «Più facile chiedere perdono che permesso».

if os.access("myfile", os.R_OK):
    with open("myfile") as fp:
        return fp.read()
return "some default data"

contro

try:
    fp = open("myfile")
except PermissionError:
    return "some default data"
else:
    with fp:
        return fp.read()

Questa regola si applica ogni volta che si intravede una race condition, ma non è una regola rigida. Se la funzione nidificata necessita di alcuni prerequisiti sull’input da verificare, l’errore in caso di input non valido potrebbe essere un criptico ValueError o KeyError senza abbastanza contesto per capire il problema. Vedi anche l’articolo di Brett Cannon «Idiomatic Python: EAFP versus LBYL» per una analisi un po’ più ampia.

Tutte queste regole di massima sono delle indicazioni vaghe, fallisci presto, o anche esplicito è meglio che implicito, entrano in gioco in modo non ben definito, l’obiettivo è dare maggior peso a quella più adatta al contesto.

Pensiero laterale

La maggior parte delle volte stiamo affrontando problemi di cui nessuno conosce veramente la soluzione corretta e la maggior parte delle volte il nostro percorso è impostato dai nostri primi passi in una o nell’altra direzione.

La parte difficile è che spesso, una volta iniziato un percorso, iniziamo a cercare solo le modifiche minime che migliorano il nostro lavoro. Ma senza cambiare la struttura rischiamo di restare bloccati in un minimo locale.

Se abbiamo amici dotati di questo pensiero laterale, discutiamo con loro il nostro problema o la nostra architettura e forse avremo una nuova prospettiva, forse un nuovo percorso più semplice da seguire riutilizzando almeno parte del lavoro già fatto.

Quando qualcosa sembra non ottimale, brutto, fai un passo indietro, inizia con la mente fresca, metti in discussione i tuoi presupposti. È meglio riscriverlo ora che non c’è altro lavoro costruito sopra che più tardi.

Capacità di semplificare

Ecco un’altra applicazione della regola di massima dividi un problema complesso, come nella comprensione di un problema, anche nella creazione di una soluzione, dividere e semplificare sono ottime strategie.

Qualunque sia il problema da risolvere, per quanto complesso possa essere, può risultare utile risolverne una versione semplificata, anche solo per comprenderne meglio il contesto.

A volte è possibile iniziare a semplificare nella fase di pianificazione, a volte invece è necessario farlo quando si presenta un problema che invalida il piano iniziale.

Inizia a pensare al quadro generale, quindi inizia dal primo passo che ti dà un valore, può essere un’API o qualcosa di funzionante. E poi itera per piccoli miglioramenti di funzionamento.

Costanza nel prender nota di decisioni / riunioni

verba volant, scripta manent, «le parole pronunciate volano via, le parole scritte rimangono».

Di solito parliamo molto durante una riunione, affrontiamo vari argomenti, ma dopo l’incontro … cosa rimane? Spesso abbiamo annotato qualcosa che ricordiamo benissimo ed invece non ci ricordiamo qualcosa che abbiamo tralasciato di annotare. Spesso per fortuna non eravamo da soli, quindi a volte basta chiedere a qualche collega per ricostruire il puzzle.

Scrivere aiuta a ricordare le decisioni, sintetizzare le divagazioni, identificare un passaggio logico mancante in una discussione verbale. Inoltre, le note di una riunione sono un buon posto per assegnare compiti e scadenze.

A meno che tu non abbia una super memoria[^1] e anche se ne hai una, sii gentile con gli altri: scrivi una sintesi dopo ogni riunione, decisione, brainstorming, assegnazione di compiti e scadenze.

Condivido la maggior parte dei suggerimenti in questo post: Gestire riunioni efficienti con gli ingegneri.

Capacità di organizzare il proprio lavoro

C’era una volta un tempo in cui avevamo un singolo compito nel nostro team e qualcun altro ci guidava assegnando le cose da fare e ci seguiva chiedendo dei nostri progressi. Ora forse abbiamo 3 progetti di sviluppo da seguire con 6 sviluppatori, 1 imminente conferenza da organizzare, 1 post sul blog da scrivere per il blog tecnico dell’azienda e un corso di 2 giorni da preparare. Per non dimenticare i 3 stand-up e il flusso di notifiche senza fine della chat preferita dalla tua azienda.

Lavorare su un singolo compito è un sogno dimenticato, la nuova realtà è il cambio di contesto. Ma, se lasci che i tuoi compiti ti guidino, alla fine della giornata, quando gli altri se ne andranno a casa, finirai pensando «Wow! Finalmente posso iniziare a fare qualcosa oggi!»

Non esiste una soluzione facile per questo, o, almeno, se ne hai una, per favore fammela sapere! L’unico modo che ho trovato per sentirmi (e forse essere) un po’ più produttivo è pianificare qualsiasi attività sul calendario, registrare tutte le attività con dettagli sufficienti per ricordare cosa si è fatto leggendo l’elenco qualche giorno dopo (toggl.com è il mio strumento preferito).

Se hai una riunione, forse dovresti essere preparato sull’argomento di cui stai per discutere, quindi programma un po’ di tempo per prepararti, sul tuo calendario, al limite potresti anche programmare una riunione con te stesso, così anche gli altri sapranno che sei occupato.

Bonus track

Durante l’incontro TL abbiamo anche visto assieme l’intervento di Netta Bondy, presentato a You Gotta Love Frontend 2016: 6 cose che i tuoi sviluppatori junior non ti dicono, stesso argomento, spunti molto interessanti.

Conclusione

Questa è la storia di una sola persona, ma in quella riunione tutti avevamo una lista come questa, a volte simile a volte molto diversa. Comunque alla fine abbiamo avuto tutti bisogno di molto aiuto per iniziare, ed adesso siamo nella posizione di dover fare del nostro meglio e per aiutare i nuovi sviluppatori[^2].

Ecco qua, questa è un po’ di saggezza che credo di aver ricevuto dai miei mentori. Qual è la tua esperienza?

[^1]: Ho una memoria superpotente di Damian Gryski
[^2]: Il numero di sviluppatori al mondo (in questo periodo) raddoppia ogni 5 anni (fonte: The Changelog #367 – Back to Agile’s basics).