“Stay relevant”…

Più volte ho affrontato il tema dell’aggiornamento professionale inteso come individuo che deve mantenere attuali, fresche le sue conoscenze in modo da mantenersi costantemente competitivo.

Lo stesso discorso vale per le aziende viste come un tuttuno.

Anzi, nel caso l’azienda abbia un particolare ruolo del mercato – ad esempio detenga una fetta consistente di un certo “business” – ecco che mantenersi competitivi è un obbligo ancor più vincolante rispetto a quello del singolo individuo.

Nel mondo IT, principalmente lato software e lato hardware, la competizione è sempre accesa e vincere significa primariamente essere rilevanti nel proprio mercato.

Sul “Design by committee” (antipattern)…

Qualche giorno fa ho avuto un piacevole scambio di opinioni con un conoscente sul tema di prendere le decisioni giuste pur tenendo conto delle varie opinioni “del popolo”.

Pur lavorando lui in un ambito differente dal mio, sentendolo parlare non ho potuto che concordare con il suo ragionamento che in sostanza si riassume in:

“E’ giusto sentire tutte le parti coinvolte in un dato contesto. E’ giusto tener conto delle loro richieste, suggerimenti e critiche. Tuttavia alla fine bisogna decidere e qualcuno deve imporre la sua soluzione, sapendo benissimo che con tutta probabilità causerà panico, sgomento e fastidio in qualcuno.”

Dopotutto, così come non si può piacere a tutti, la stessa cosa vale per le decisioni prese da qualcuno.

Questioni di rispetto nel codice…

Un po’ di tempo fa, mentre parlavo e spiegavo ad un conoscente l’uso di una data funzione di libreria in C è partita una mini-discussione sul perchè, prima di chiamarla e dopo averla chiamata, avessi sistematicamente compiuto alcune operazioni apparentemente superflue dato il contesto come pulire/ripredisporre dei buffer e reinizializzare alcune strutture in memoria.

La cosa “strana” ai sui occhi è stato che quella funzione fosse in realtà chiamata solo ed esclusivamente in un punto del nostro codice cosicchè il “chiamante” e “consumatore” del risultato prodotto di fatto fosse uno solo: noi, nelle sembianze della la nostra funzione.

Il suo ragionamento è stato:

“Ma se tanto chi usa quella funzione g() è sempre la stessa funzione, la nostra f(), perchè dovremmo perdere tempo per assicurarci di reinizializzare tutto? Tanto non c’è nessun altro che la usa in questo codice perchè è nostro!”

La mia risposta al momento è stata un filo stringata:

“Precauzione!”

Mi rendo conto che si tratta di una risposta troppo concisa (soprattutto per me!), per cui forse è bene dire qualche parolina in più…

Recensione “Peopleware: Productive Projects and Teams”…

E’ davvero un bel po’ che non recensisco un libro: non che abbia smesso di leggerne ma un po’ di pigrizia, un po’ il metodo di recensione che mi ero autoimposto (*), alla fine non ho più proseguito con questa sana abitudine.

Per cui, per rimettermi in carreggiata, credo sia opportuno ripartire con uno dei libri più belli che abbia mai letto, uno di quelli che non possono passare inosservati e che sento il dovere di segnalarvi.

Inoltre, con questa recensione, riesco finalmente a mantenere svariate promesse di cui ben due a Stefano (riprendere con le recensioni e parlare proprio di questo libro).

Ecco a voi, infine, “Peopleware: Productive Projects and Teams“.