Clean Craftsmanship: le doti di uno sviluppatore coraggioso

Parliamo di ciò che forma il coragggio

Come CTO, ho diverse aspettative legate a questo concetto.

Coprirsi a vicenda

Usiamo la parola team per descrivere un gruppo di sviluppatori che lavorano su un progetto. Ma abbiamo davvero capito che cos’è veramente un team?

Un team è un gruppo di collaboratori che comprendono i loro obiettivi e la loro interazione così bene che quando un membro del team va in crisi per qualche motivo, continuano a fare progressi verso il loro obiettivo. Per esempio, ogni membro dell’equipaggio di una nave ha un preciso lavoro da svolgere. Ogni membro dell’equipaggio sa anche come fare il lavoro di qualcun altro, per ovvie ragioni. La nave deve continuare a navigare anche quando un membro dell’equipaggio va in crisi.

Mi aspetto che i membri di un team di programmazione si coprano a vicenda come l’equipaggio di una nave. Quando un membro del team va in crisi, mi aspetto che altri membri del team assumano il suo ruolo fino a quando egli non riprenderà il suo posto nel team.

I membri di un team possono andare in crisi per molte ragioni. Potrebbero ammalarsi. Potrebbero essere distratti da problemi a casa. Ma potrebbero benissimo andare in vacanza. Il lavoro sul progetto non può fermarsi. Altri devono riempire quel buco.

Se Bob è l’addetto al database e va in crisi, qualcun altro deve prendere in mano il lavoro sul database e continuare a fare progressi. Se Jim si occupa della GUI e va in crisi, qualcun altro deve prendere in mano il lavoro sulla GUI e continuare a fare progressi.

Ciò significa che ogni membro del team deve avere familiarità con qualcosa di più del proprio lavoro. Tutti devono avere una certa familiarità con il lavoro degli altri, in modo che possano intervenire se uno di loro andasse in crisi.

Ma capovolgiamo le cose. È tua responsabilità assicurarti che qualcuno sia in grado di coprirti. È tua responsabilità assicurarti di non essere l’unico esperto indispensabile del team. È tua responsabilità comunicare con gli altri e insegnare loro abbastanza del tuo lavoro da poterti sostituire al volo.

Come puoi insegnare agli altri il tuo lavoro? Probabilmente il modo migliore è sedersi con loro a una workstation e scrivere del codice insieme per circa un’ora. E se possiede saggezza, lo farai con più membri del team. Più persone conosceranno il tuo lavoro, più persone potranno coprirti se andrai in crisi.

E, ricorda: una volta non è abbastanza. Mentre continui a fare progressi nel progetto, dovrai tenere continuamente gli altri al passo con il tuo lavoro.

Troverai utile a questo proposito la disciplina della programmazione collaborativa.

Mi aspetto che i membri dei team di programmazione siano in grado di coprirsi a vicenda.

Stime oneste

Mi aspetto stime oneste.

Come programmatori, la stima più onesta che puoi dare è Non lo so, perché in realtà non sai quanto tempo ti richiederà l’attività. D’altra parte, sai per certo che probabilmente terminerai il compito in meno di un miliardo di anni. Quindi, una stima onesta è un amalgama di ciò che sai e ciò che non sai.

Stime oneste costruiscono il team.

Una stima onesta è simile a questa.

• Ho il 5 percento di possibilità di finire questo compito entro venerdì.
• Ho il 50 percento di possibilità di finire entro il prossimo venerdì.
• Ho il 95 percento di possibilità di finire entro il venerdì successivo.

Una stima come questa fornisce una distribuzione di probabilità che descrive la tua incertezza. Descrivere la tua incertezza è ciò che rende questa stima onesta.

Dovresti fornire stime di questo tipo quando i manager ti chiedono di stimare progetti di grandi dimensioni. Per esempio, potrebbero dover provare a valutare il costo di un progetto prima di autorizzarlo. Questo è il momento in cui questo tipo di onestà sull’incertezza è più prezioso.

Per compiti più piccoli, è meglio usare la pratica Agile dei punti storia. I punti storia sono onesti, perché non si impegnano per un lasso di tempo. Piuttosto, descrivono il costo di un’attività rispetto a un’altra. I numeri utilizzati sono arbitrari, ma relativi.

Una stima del punto storia somiglia a questa:

La storia Deposito ha costo 5.

Che cos’è quel 5? È un numero arbitrario di punti relativo a un compito di dimensioni note. Per esempio, supponiamo che alla storia Login siano stati assegnati arbitrariamente 3 punti. Quando stimi la storia Deposito, decidi che Deposito non è due volte più difficile di Login, quindi le dai un 5. Questo è davvero tutto quello che c’è da fare.

I punti storia incorporano già la distribuzione di probabilità. In primo luogo, i punti non sono date o orari, sono solo punti. In secondo luogo, i punti non sono promesse, sono solo supposizioni. Alla fine di ogni iterazione Agile (di solito una o due settimane), calcoliamo i punti completati. Così possiamo usare quel numero per stimare quanti punti potremmo completare nella prossima iterazione.

Mi aspetto stime oneste che descrivano la tua incertezza. Non mi aspetto una promessa di una data.

Saper dire di no

Mi aspetto che tu dica no quando la risposta è no.

Una delle cose più importanti che un programmatore può dire è No!. Detta al momento giusto, nel contesto giusto, questa risposta può far risparmiare enormi somme di denaro al tuo datore di lavoro e prevenire orribili fallimenti e imbarazzi.

Questa non è una licenza per andare in giro dicendo no a tutto. Siamo tecnici, il nostro lavoro è trovare un modo per dire sì. Ma a volte quel sì non è un’opzione. Siamo gli unici a poterlo stabilire. Siamo solo noi a saperlo. Pertanto, sta a noi dire di no quando la risposta è un no.

Supponiamo che il tuo capo ti chieda di fare qualcosa entro venerdì. Dopo aver ben valutato le cose, ti rendi conto che non c’è alcuna ragionevole possibilità di completare quell’attività entro venerdì. Devi tornare dal capo e dirgli No. Faresti bene a dire anche che puoi farlo entro il martedì successivo, ma devi essere fermo sul fatto che il venerdì è fuori questione.

I manager spesso non amano sentirsi dire di no. Potrebbero respingerlo. Potrebbero arrabbiarsi. Potrebbero anche urlarti contro. Il confronto emotivo è uno degli strumenti impiegati da alcuni manager.

Non devi cedere. Se la risposta è no, devi attenerti a quella risposta e non cedere alle pressioni.

E fai molta attenzione al loro Ci proverai, almeno?. Sembra davvero ragionevole chiedere di provarci, vero? Ma non è affatto ragionevole perché già ci stai provando. Non c’è niente di nuovo che tu possa fare per cambiare quel no in un sì, quindi dire che ci proverai è solo una bugia.

Mi aspetto che quando la risposta sarà no, tu sappia dire quel no.

Apprendimento aggressivo continuo

Il settore del software è estremamente dinamico. Possiamo discutere se sia giusto che sia così, ma non possiamo negare che è così. Quindi, dobbiamo apprendere continuamente in modo aggressivo.

Il linguaggio che usi oggi probabilmente non sarà quello che utilizzerai tra cinque anni. Il framework che stai utilizzando oggi probabilmente non sarà quello che utilizzerai l’anno prossimo. Preparati a questi cambiamenti e sii consapevole di ciò che sta cambiando intorno a te.

Apprendimento continuo e aggressivo: la ricetta per restare sulla cresta dell’onda.

Ai programmatori viene spesso consigliato di imparare un nuovo linguaggio ogni anno (David Thomas e Andrew Hunt, Il Pragmatic Programmer). Questo è un buon consiglio. Inoltre, scegli un linguaggio con uno stile che non conosci. Se non hai mai scritto codice in un linguaggio a tipizzazione dinamica, imparane uno. Se non hai mai scritto codice in un linguaggio dichiarativo, imparane uno. Se non hai mai programmato in Lisp o Prolog o Forth, imparali.

Come e quando svolgere questo apprendimento? Se il tuo datore di lavoro ti offre il tempo e lo spazio per fare questo tipo di apprendimento, allora approfittane quanto più puoi. Se il tuo datore di lavoro non è così avveduto, dovrai studiare nel tuo tempo libero. Preparati a dedicarci diverse ore al mese. Assicurati di dedicarci una quota del tuo tempo personale.

Sì, lo so. Hai obblighi familiari, ci sono conti da pagare e voli da prendere: hai una vita. Ok, ma hai anche una professione. E le professioni hanno bisogno di cure e manutenzione.

Mi aspetto che il nostro apprendimento sia aggressivo e continuo.

Mentoring

Sembra che abbiamo un bisogno senza fine di nuovi programmatori. Il numero di programmatori nel mondo sta aumentando a un ritmo vertiginoso ed esponenziale. Le università possono arrivare solo fino a un certo punto e, sfortunatamente, molte di esse non insegnano affatto.

Pertanto, il compito di insegnare ai nuovi programmatori spetta a noi. Noi programmatori che lavoriamo da qualche anno dobbiamo assumerci l’onere di insegnare a chi ha appena iniziato.

Forse pensi che sia difficile. Sì, lo è. Ma offre un enorme vantaggio. Il modo migliore per imparare è insegnare. Nessun’altra attività è più efficace. Quindi, se vuoi imparare qualcosa, insegnala.

Se programmi da 5, 10 o 15 anni, avrai un’immensa quantità di esperienza e lezioni di vita da insegnare ai nuovi programmatori, che hanno appena iniziato. Prendine uno o due sotto la tua ala protettrice e guidali per i loro primi sei mesi.

Siediti con loro alle loro postazioni di lavoro e aiutali a scrivere il codice. Racconta loro storie sui tuoi fallimenti e successi. Insegna loro le discipline, gli standard e l’etica. Insegna loro il mestiere.

Mi aspetto che tutti i programmatori diventino mentori. Mi aspetto il tuo coinvolgimento nell’aiutare gli altri a imparare.

Questo articolo richiama contenuti da Clean Craftsmanship.

Immagine di apertura di eleonora su Unsplash.