Affrontare la giusta montagna

Catria

Ho letto numerosi libri in cui si sostiene che le sfide sportive più difficili possono essere vinte grazie alla forza di volontà.
La mente può influenzare il corpo e quindi se immagini di farlo lo puoi fare.
Mi piace pensare che la forza di volontà abbia questo potere, ma la mia esperienza diretta è che abbiamo dei limiti: fisici, caratteriali, psicologici con cui dobbiamo fare i conti.
Tentare di superare questi limiti per migliorare se stessi è doveroso e lodevole, ma non è sempre possibile.
Affrontare sfide più grandi di noi, denota coraggio ma in caso di fallimento può anche essere fonte di grande frustrazione.
Io amo la montagna, ma sul K2 non ci andrò mai: non è una sfida alla mia portata.

Questa consapevolezza però non mi impedisce di continuare ad amare la montagna e frequentare i nostri cari Appennini.
Si dice che tentare non nuoce ma non credo sia esatto, tentare imprese più grandi di noi può nuocere alla propria autostima.
Se vi incamminate per una meta che non è alla vostra portata lungo la strada dovete stare attenti ai segnali che il vostro corpo vi manda o rischiate di perdervi nell’impresa.
Walter Bonatti, in una delle sue ultime interviste, disse che la sfida degli scalatori non è tanto arrivare in vetta quanto tornare a casa sani e salvi, ciò naturalmente implica anche decidere di rinunciare alla scalata se necessario.
Nell’ultima ciaspolata che feci qualche anno fa, ultimo di un gruppo di 4 persone, a 3/4 del percorso, già molto affaticato, in un tratto molto ripido, mi dovetti fermare e cominciai a sbadigliare.
Rimasi colpito da questo strano segnale che il corpo mi lanciava e che sembrava fuori luogo, ma il senso ero chiaro: mi stavo spegnendo.
Il cervello diceva di proseguire, ma il corpo reclamava.
Decisi perciò di fermarmi e mi appoggiai con la schiena sulla neve. Trascorsi circa 5 minuti ad ammirare il panorama che mi si apriva davanti e approfittai per riprendere fiato.
Il sudore sulla pelle si raffreddò velocemente e non potendo rimanere lì fermo, dovetti scegliere cosa fare. Prima che il freddo si facesse sentire, mi rialzai e lentamente raggiunsi il resto del gruppo sulla cima del Catria.
Qualche anno dopo senza alcun tipi di preavviso ebbi qualche problemino con il cuore.
Non potei fare a meno di pensare che in quel frangente sulla montagna forse la mente aveva chiesto troppo al corpo e quella breve pausa era stata quantomai preziosa. Chissà ?
Insomma in quel caso la tigna mi portò fino in cima, ma avrei anche potuto scegliere di tornare indietro.
Naturalmente quando si affronta una sfida è importante mettercela tutta, ma se si tocca un proprio limite è importante ricordarsi che si può tornare indietro o cambiare strada.
Quando si sceglie una montagna da scalare è importante scegliere la montagna giusta.

L’utile costruttore

PL\SQL è un linguaggio procedurale ma è possibile adottare uno stile di scrittura orientato alla programmazione ad oggetti.

In un package PL\SQL è frequente dover definire un modello dati in memoria a supporto degli algoritmi di elaborazione.
Per far ciò, io personalmente preferisco utilizzare TYPE RECORD definiti all’interno del package stesso invece di TYPE OBJECT, perché ciò rende il package auto consistente.

Dato un TYPE RECORD è possibile definire uno o più RECORD di questo tipo di dato. L’inizializzazione di queste variabili può essere effettuati in punti diversi del codice nei modi più diversi, ma non si ha alcuna garanzia che il record venga inizializzato sempre in modo completo e corretto.
Questo rischio aumenta quando è necessario estendere il TYPE RECORD aggiungendo un attributo per esempio.
Il rischio è che, le procedure che utilizzano tali RECORD, risentano della inizializzazione incoerente di questi e che ciò produca errori a run-time.

Il concetto di costruttore è una soluzione efficace a questo problema: quando si usa una struttura dati, prima di usarla, è necessario avere garanzia che essa sia stata correttamente inizializzata.

Nel nostro caso l’idea è di considerare un TYPE RECORD l’equivalente di una CLASS e definire una FUNCTION che svolga il ruolo di costruttore.
Il costruttore accetta in ingresso tutta una serie di parametri che consentono di inizializzare il RECORD e restituisce il RECORD stesso.
La regola non scritta, si parla appunto di stile di programmazione, è che prima di usare RECORD di questo tipo si invoca sempre il suo costruttore.

SUBTYPE tItemId IS VARCHAR2(50);
SUBTYPE tCurrency IS NUMBER;

TYPE tItem IS RECORD(
   id     tItemId
  ,descr  VARCHAR2(255)
  ,price  tCurrency
  ,qty    NUMBER
  ,total  tCurrency
);
FUNCTION itemNew RETURN tItem IS
  this tItem :=NULL;
BEGIN
  this.qty   := 0;
  this.total := 0;
  RETURN this;
END;

FUNCTION itemNew(
   id IN tItemId
  ,descr IN VARCHAR2
  ,price  tCurrency
  ,qty    NUMBER
) RETURN tItem IS
  this tItem :=itemNew();
BEGIN
  this.id := id;
  this.descr := descr;
  this.price := price;
  this.qty := qty;
  RETURN this;
END;
DECLARE
  item tItem := itemNew();
BEGIN
  item := itemNew(id=>'ID123',descr=>'HAMMER',price=>1.3,qty=>2);
END;

Questo approccio può sembrare costoso a prima vista ma in realtà è semplice e facilmente ripetibile.

Il suo utilizzo rende il codice facilmente comprensibile.
Inoltre nel caso in cui si debba estendere il il TYPE RECORD, alterando il costruttore, avremo garanzia che l’intervento venga effettuato in modo coerente in tutti i punti del codice in cui il costruttore è invocato.

Il consiglio è di predisporre sempre un costruttore base non accetta alcun parametro e che inizializza tutti gli attributi ad un valore di default: nel gergo dei programmatori C un costruttore VOID.

Naturalmente sfruttando l’OVERLOADING è possibile definire una famiglia di costruttori che espongono parametri diversi in base alle varie esigenze applicative.

Un cronografo piccolo piccolo

A volta capita che una procedura PL\SQL sia lenta.
In questi casi per individuare le porzioni di codice lento è utile misurarne il tempo di esecuzione.
Per far ciò ho realizzato un package che implementa un cronografo.

CREATE OR REPLACE PACKAGE CRONO IS
   TYPE tTimer IS RECORD(
      s TIMESTAMP
     ,e TIMESTAMP
   );
 FUNCTION  new     RETURN tTimer;
   PROCEDURE stop    (this IN OUT NOCOPY tTimer);
   PROCEDURE reset   (this IN OUT NOCOPY tTimer);
   FUNCTION  time    (this IN OUT NOCOPY tTimer) RETURN VARCHAR2;
   FUNCTION  hour    (this IN OUT NOCOPY tTimer) RETURN NUMBER;
   FUNCTION  minute  (this IN OUT NOCOPY tTimer) RETURN NUMBER;
   FUNCTION  second  (this IN OUT NOCOPY tTimer) RETURN NUMBER;
 END;
CREATE OR REPLACE PACKAGE BODY CRONO IS
  
  FUNCTION  new RETURN tTimer IS
    this tTimer := NULL;
  BEGIN
    this.s := SYSTIMESTAMP;
    this.e := NULL;
    RETURN this;
  END;
  
  PROCEDURE starting(this IN OUT NOCOPY tTimer)IS
  BEGIN
    this.s := SYSTIMESTAMP;
  END;
  
  PROCEDURE stop (this IN OUT NOCOPY tTimer) IS 
  BEGIN
    this.e := SYSTIMESTAMP;
  END;
  
  PROCEDURE reset (this IN OUT NOCOPY tTimer) IS
  BEGIN
    this.s := SYSTIMESTAMP;
    this.e := NULL;
  END;

  FUNCTION  time (this IN OUT NOCOPY tTimer) RETURN VARCHAR2 IS
    ret VARCHAR2(32767):=NULL;
  BEGIN
    ret := this.e - this.s;
    
    ret := ret || ' ' || 'h:' || (extract(hour from this.e - this.s));
    ret := ret || ' ' || 'm:' || (extract(minute from this.e - this.s));
    ret := ret || ' ' || 's:' || (extract(second from this.e - this.s));
    
    RETURN ret;
  END;

  FUNCTION  hour (this IN OUT NOCOPY tTimer) RETURN NUMBER IS
    h NUMBER :=NULL;
  BEGIN
    h := (extract(hour from this.e - this.s));
    RETURN h;
  END;

  FUNCTION  minute (this IN OUT NOCOPY tTimer) RETURN NUMBER IS
    m NUMBER :=NULL;
  BEGIN
    m := (extract(minute from this.e - this.s));
    RETURN m;
  END;

  FUNCTION  second (this IN OUT NOCOPY tTimer) RETURN NUMBER IS
    s NUMBER :=NULL;
  BEGIN
    s := (extract(second from this.e - this.s));
    RETURN s;
  END; 
END;

Il suo utilizzo è molto semplice.
A seguire un esempio:

DECLARE
  t1 CRONO.tTimer; --Variabile di tipo cronometro

  --Codice che consuma tempo
  PROCEDURE NOP(cycle IN NUMBER)IS
  BEGIN
    FOR i in 1..cycle LOOP
      DECLARE
       c NUMBER := 0;
      BEGIN
        select 1 into c from dual;
      END;
    END LOOP;
  END;

BEGIN
  --Il cronometro t1 viene creato ed avviato
  t1 := CRONO.new();
  
  NOP(cycle=>1000);
   
  --Il cronometro t1 viene fermato
  CRONO.stop(t1);

  --Si stampa il tempo misurato dal cronometro t1
  DBMS_OUTPUT.PUT_LINE('Tempo trascorso A:' || CRONO.time(t1));

  --Si resetta il cronometro t1
  CRONO.reset(t1); 
  
  NOP(cycle=>500);
 
  --Il cronometro t1 viene fermato
  CRONO.stop(t1);
   
  --Si stampa il tempo misurato dal cronometro t1
  DBMS_OUTPUT.PUT_LINE('Tempo trascorso B:' || CRONO.time(t1));
 
END;

La psicologia “semplice” del developer

Ho sempre ritenuto che nel nostro lavoro la componente psicologica sia molto importante, purtroppo ho registrato spesso una scarsa sensibilità verso questo tema.

Ma è veramente così difficile avere a che fare con i developer ?
E’ possibile disegnare il profilo psicologico di un developer ?

Recentemente, durante una di queste riflessioni, ritengo di aver colto una verità interessante.

Un developer professionale è molto simile ad un artigiano, i suoi manufatti sono diretta espressione della sua arte e del suo genio.

Inoltre:

  • trae piacere nel fare bene il suo lavoro e cerca l’eccellenza
  • ha bisogno di dare un senso al proprio lavoro e quindi cerca conferma che il suo manufatto sia utile
  • ha stima di chi fa il suo stesso lavoro e trae beneficio dal far parte di una comunità

Da ciò discente in modo chiaro che chiedere ad un developer di produrre “cacca” equivale a soffocare il sue ego ed infangare la sua arte, ingenerando un profondo senso di frustrazione. 

Di converso per alimentare e mantenere alta la motivazione dei developer è facile individuare una serie di azioni:

  1. manager competenti
  2. retribuzione commisurata al valore prodotto
  3. ambiente informale
  4. auto organizzazione
  5. disponibilità degli migliori strumenti
  6. agevolare l’accesso a informazioni e a formazione
  7. agevolare la partecipazione a community
  8. ridurre il debito tecnico
  9. rendere il lavoro sostenibile

Naturalmente ci sono dei lati oscuri che conviene tenere in debita considerazione:

  1. la ricerca dell’eccellenza è nemica della gestione del tempo
  2. l’ego spiccato può determinare sporadici deliri di onnipotenza

Sulla contrazione dell’universo

Le aziende sono organizzazioni che cambiano nel tempo.
La crescita di un’azienda è un fenomeno simile all’espansione dell’universo.
Quando il numero di persone cresce tipicamente si cerca di contrastare l’entropia creando nuove funzioni, livelli e ruoli aziendali che vanno ad accrescere la struttura gerarchica aziendale a forma piramidale.

La realtà e che non siamo affatto certi che l’espansione dell’universo sia continua. Allo stesso modo non possiamo dare per scontato che l’azienda cresca in modo indefinito.
Negli ultimi decenni abbiamo sperimentato un’altissima variabilità sui mercati e ci siamo dovuti ricordare che la crescita non è una costante.

Un’azienda allora per essere longeva dovrebbe assumere una struttura plastica, malleabile al bisogno e con bassa inerzia al cambiamento.
Prendere coscienza di questa necessità spesso innesca transizioni verso strutture organizzative più moderne e a sviluppo orizzontale.

Se strutturare un’azienda in fase di espansione può essere relativamente facile, gestire una fase di contrazione ed appiattire la gerarchia è impresa ardua.
I livelli, i ruoli e le funzioni creati nel tempo debbono essere revisionati in modo profondo e spesso doloroso.
Per le persone coinvolte in queste transizioni è come trovarsi nel compattatore dei rifiuti di Star Wars: è naturale opporsi in tutti i modi, cercando di sabotare la stessa sala comandi.

Per questo un processo del genere deve necessariamente partire dall’alto, ma oltre all’autorità serve autorevolezza.
La prima cosa da fare infatti è allineare tutti i livelli sui principi ed i valori nuovi.
Ciò può risultare estremamente difficile se negli anni precedenti i comportamenti e la linea di condotta hanno smentito nei fatti i principi ed i valori che si cerca di radicare: quello che serve è una buona dose di credibilità, ma ci vuole tempo.

Per questo motivo è più semplice creare da zero un’azienda che aderisca a certi principi e valori piuttosto che riconvertirne una esistente.

Contenitore Vs Contenuto

Qualche giorno fa sono entrato in una Libreria.
Era molto tempo che non lo facevo più.
Ho scorso velocemente la sezione di science-fiction.
Me stavo andando quando un libricino ha attirato la mia attenzione: “Lo Zen nell’arte di scrivere”.
Il formato e la promessa che il titolo nascondeva erano stuzzicanti, il fatto che l’autore fosse Ray Bradbury mi ha convinto.
Ho soppesato un attimo l’idea di acquistarlo su Amazon in formato elettronico, ma mi sono abbandono al romanticismo: stavo già accarezzando le pagine e non vedevo l’ora di leggerlo.
Ho comperato il libro a 15 EUR. Una volta uscito ho resisto all’impulso di verificare quanto sarebbe costato su Amazon.

Qualche ora più tardi ho ceduto alla curiosità.
Su Amazon lo stesso libro in formato cartaceo costa 13 EUR ma in formato elettronico 5 EUR!

Sono rimasto piuttosto stupito, il romanticismo mi è costato caro.
Ma ciò che mi ha colpito è che il contenuto pesa solo per 1/3 sul prezzo complessivo di questo libro cartaceo.
Tutto ciò mi sembra sinceramente assurdo.

Naturalmente un solo libro non è un campione significativo, ma è facile capire perché il mercato dei libri stampati sia in crisi.

Da tempo ormai preferisco gli ebook per motivi di praticità.
Il libro stampato però ha una caratteristica che tende ad essere sottovalutata: con le dovute cautele (persone affidabili) può essere prestato e ciò lo rende un prezioso vettore di idee.

Come si può attraversare un fiume ?

Fiume
Fiume

Qualche tempo fa ho partecipato ad un bell’evento sul gaming.
Tra i vari giochi uno richiedeva di scrivere in 10 minuti in solitaria un elenco di modi per attraversare un fiume.

Comincio scrivendo le mie soluzioni:

  • con la barca
  • a nuoto
  • con un ponte
  • con una liana
  • con una pertica
  • con un tronco
  • ecc.

Finisce il tempo ed il coach chiede ad un partecipante di leggere una soluzione.
La persona si alza e declama: “Sulle spalle di un altro…”
Lì per lì rimango di stucco poi comincio a riflettere.

Parto da me. Probabilmente per me e per i miei colleghi del gruppo tutti di estrazione ingegneristica è stato naturale scovare strumenti per attraversare il fiume, ciò ha determinato automaticamente l’esclusione di una persona come strumento.

Mi metto nei panni dell’altro. Forse la persona è un manager. I manager per definizione gestiscono risorse tra cui esseri umani. I manager non sono uomini del fare. I manager da un certo punto di vista utilizzano le persone per lavorare, quindi tutto sommato la risposta non dovrebbe stupire.

E’ stupefacente come un gioco di tale semplicità possa far emergere in modo così chiaro una tale differenza d’impostazione nella mentalità di una persona.

Il background ed il contesto influenzano il nostro modo di pensare e di affrontare i problemi, limitando di fatto l’area in cui cerchiamo le soluzioni.

Cosa rimane dell’Agile?

Qualche settimana fa ho partecipato al corso MASS Metodologie Agile di Sviluppo Software. Gli argomenti trattati:

  • Agile Manifesto
  • Scrum
  • Lean Software Development
  • XP

Ho avuto modo di approfondire temi a me cari e di fare esercitazioni di gruppo. Ho acquisito consapevolezza della relazione che esiste tra : Valori, Principi e Pratiche. E’ stato piacevole sentire citare il manifesto in una sede istituzionale da un docente aziendale; non più farneticazioni di qualche individuo controcorrente. Ho visto le facce dei miei colleghi prendere coscienza che esiste un modo diverso di intendere il nostro lavoro. Facce stupite di persone che scoprono un nuovo mondo in cui il buonsenso e’ dominante. Persone che a questo punto cominciano ad interrogarsi e farsi domande: e questo e’ già un grande risultato. Ma le transizionia Agile debbono partire dall’alto quindi non ci sono le condizioni. Allora prima che lo stupore scemi e si trasformi in frustrazione dobbiamo portare a casa i VALORI ed i PRINCIPI e qualche PRATICA (unit test) . Confrontarsi tutti i giorni con questi elementi ci renderà migliori e portatori di un messaggio forse controcorrente ma positivo e di buonsenso.

 

Lo spirito del formatore

Vengo da una famiglia di docenti: professori, maestri, mio nonno paterno fu preside, quindi l’attivita formativa fa parte del mio background culturale.
Tra il 200o ed il 2005 ho avuto la fortuna di svolgere io stesso l’attività di docente per numerosi corsi di formazione in ambito informatico: HTML, OOP, C, C++, Database Relazionali ecc con feedback sempre piuttosto positivi.
Qualche settimana fa mi è capitato di aiutare un collega preoccupato di non conoscere C#.
Per me nulla è impossibile quindi vedere un programmatore “scantato” di fronte ad un problema superabile non è accettabile.
Così per dimostrargli che passare da un linguaggio ad un altro meno è difficile di quanto sembri, l’ho aiutato 1o minuti a scrivere “Hello World” usando un ambiente di sviluppo per C# online.
Per lui è stato come scendere una pista nera senza sapere nulla degli sci: avventato e pericoloso ma divertente.
Il suo commento finale “Azz ma allora funziona, bè non sembra così complicato” mi ha dato grandissima soddisfazione.
E’ stato molto bello provare di nuovo, dopo tanto tempo, il piacere di insegnare qualcosa di nuovo ad una persona.
Ricordo perfettamente le settimane full-immersion dei corsi C e C++ a Milano in cui si alternava la mattinata di teoria al pomeriggio di laboratorio.
Per quanto i concetti del mattino sembravo essere stati trasmessi correttamente alla classe almeno a giudicare dalle espressioni del viso, nel pomeriggio, costruendo in prima persona dei piccoli programmi, accadeva spesso che il viso di qualcuno si illuminasse per poi esclamare: “A ecco come funziona! Adesso ho capito!”, segno tangibile che il concetto oltre ad essere stato ricevuto ed accettato per “fede” era stato verificato empiricamente e quindi fatto proprio, in modo maieutico.

Il pensatore

Questa statuetta in legno e’ il regalo che una coppia di amici mi fece di ritorno dal viaggio di nozze. Nel regalarmela mi dissero che si intitolava “il pensatore” e che mi simboleggiava. A quel tempo ciò mi fece piacere e mi stupì. Oggi a distanza di 20 anni e con una maggiore consapevolezza di me, sento che questa statuetta mi rappresenta piuttosto bene, anzi forse la sua energia mi ha influenzato ed indotto a creare questo blog…