Home
Clean Craftsmanship: le doti di uno sviluppatore coraggioso

30 Dicembre 2021

Clean Craftsmanship: le doti di uno sviluppatore coraggioso

di

Cose da aspettarsi da un team di sviluppatori che sia veramente tale.

Parliamo di ciò che forma il coragggio

Clean Craftsmanship - Come CTO, ho diverse aspettative legate al coraggio

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.

Iscriviti alla nostra newsletter

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.

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 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 , 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.

Il linguaggio che usi oggi probabilmente non sarà quello che userai tra cinque anni. Preparati

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.

L'autore

  • Robert C. Martin
    Robert C. Martin, conosciuto anche come “Uncle Bob”, scrive codice dal 1970 ed è un consulente informatico di livello internazionale. Ha fondato le società Uncle Bob Consulting LLC, Object Mentor Inc e - insieme al figlio Micah Martin - The Clean Coders LLC. È stato caporedattore della rivista The C++ Report e presidente dell'Agile Alliance. Firmatario del Manifesto per lo Sviluppo Agile di Software, è autore di Clean Code, bestseller che vanta oltre 160.000 copie vendute nella sola edizione inglese.

Vuoi rimanere aggiornato?
Iscriviti alla nostra newletter

Novità, promozioni e approfondimenti per imparare sempre qualcosa di nuovo

Gli argomenti che mi interessano:
Iscrivendomi dichiaro di aver preso visione dell’Informativa fornita ai sensi dell'art. 13 e 14 del Regolamento Europeo EU 679/2016.

Corsi che potrebbero interessarti

Tutti i corsi
Programmare in VBA – Iniziare Bene-cover Corso Online

Programmare in VBA - Iniziare Bene

con Francesco Borazzo

Vuoi imparare a lavorare meglio con Excel? Analizzando fogli di calcolo complessi con il linguaggio VBA risparmi tempo prezioso Nel suo corso Francesco Borazzo ti insegna come.

399,00

Data di inizio:
22/2/2023


Libri che potrebbero interessarti

Tutti i libri

Code

Il linguaggio segreto di computer e software

37,91

39,90€ -5%

di Charles Petzold

Algoritmi spiegati in modo facile

Guida illustrata per programmatori curiosi

28,41

29,90€ -5%

di Aditya Y. Bhargava

La cattedrale e il bazaar

Riflessioni di un rivoluzionario per caso su Linux e l'open source

12,26

12,90€ -5%

di Eric S. Raymond


Articoli che potrebbero interessarti

Tutti gli articoli