Il mito del Programmatore

* Il mito del Programmatore

Il popolo bue crede che il software e i siti web siano realizzati dal Programmatore (alias Developer, alias Software Engineer, alias Sviluppatore, alias Coder, alias...) figura leggendaria mitologica che picchietta sulla tastiera come un pazzo e cinque minuti dopo magicamente compare tutto perfetto e funzionante, anche le cose che il committente non aveva ancora immaginato. Questo equivoco è talmente diffuso che perfino nelle aziende vige spesso la stessa creduloneria.

In realtà nella realizzazione del software ci sono diversi ruoli - con annessi problemi quando una singola persona ne riveste più di uno.

Commerciale: quello ingiaccato e incravattato che va dal cliente a fare mercato delle vacche poiché non capisce niente di software, programmazione, ecc., ma è bravissimo a dire paroloni elegantoni (buzzwords).

Programmatore: bassa manovalanza, quello che materialmente scrive il codice del programma o del sito web. Uno o più programmatori costituiscono un "team di sviluppo". Quando uno ha esperienza quasi zero o non capisce niente, viene qualificato sprezzantemente come junior. Per venire incontro al mercato le università hanno creato le "lauree brevi" in informatica in modo da sfornare molti junior; le lauree "lunghe" sono quelle in cui il programmatore capisce che il software che scrive deve non solo essere compilabile senza errori ma dovrebbe almeno un po' funzionare.

Tester: l'incaricato di collaudare i componenti software appena sviluppati o modificati, verificare se funzionano secondo i requisiti, provare a usare casi limite per vedere se vengono gestiti o si inceppa tutto... insomma, trovare i bug e documentarli per far richiedere le correzioni necessarie. Uno o più tester costituiscono un "team di collaudo". Qualifica che, quando esiste, viene rifilata agli incapaci o alle donne (comico ma vero) perché è il lavoro più meccanico e noioso.

Il guaio è che per essere un buon tester occorre anzitutto essere un buon programmatore, per sapere subito quali errori si possono commettere nello scrivere codice e quali test strani ma non irragionevoli bisogna fare.
Barzelletta: un tester va al bar. Ordina una birra. Ordina quattro birre. Ordina zero birre. Ordina 65536 birre. Ordina -1 birre. Ordina 5*3+17 birre. Ordina “ªΩÞ³ıÆ⅝” birre. Ordina ';drop table ordini;' birre. Ordina due birre ben calde.

Designer (o molto più spesso programmatore senior): alta manovalanza, quello che scrive le parti più delicate del programma. In genere è uno che conosce la differenza fra complessità lineare ed esponenziale, sa quando è il caso di lavorare su disco o in memoria, sa quando è meglio usare bitmap piuttosto che stringhe, sa maneggiare con dimestichezza puntatori ai puntatori, ecc. (n.b.: tutte cose normalmente ignorate da chi lo ha assunto). L'attitudine, nel mondo dell'informatica, è di dargli la stessa paga di uno junior (sai, l'azienda non può permettersi troppo, ma poi cresceremo insieme, avrai opportunità e visibilità, ecc.).

Project Manager (più in genere: PM): quello che deve continuamente ripulire il progetto da incrostazioni come requisiti ambigui o irragionevoli, far implementare le features previste dalle specifiche, far correggere i bug e le vaccate, assicurarsi che ogni parte del programma abbia i propri test (e che vengano superati tutti), faccia completare le parti incomplete, si assicuri della qualità e manutenibilità del codice, faccia l'analisi dei rischi laddove necessario, ecc. Praticamente non scrive codice e non fa i test, per cui molti programmatori aspirano a diventare PM illudendosi di poter comandare e spadroneggiare... e quelle rare volte che ci riescono si accorgono che a causa delle troppe urgenze non se li caga proprio nessuno.

Si presume che un PM sia almeno un esperto programmatore, designer e tester, capace di valutare il codice, i test, le soluzioni escogitate, e suggerire cosa fare e cosa non fare, e avere sempre ben chiari i tempi di sviluppo e collaudo. Si presume, appunto.

System Architect: figura presente solo nelle Grosse Aziende™, colui che guida i vari PM e stabilisce come vanno integrati i progetti tra loro; una sorta di super-PM.

System Analyst: quello che traduce i desiderata del cliente in componenti software/web da sviluppare e li descrive in maniera formale e chiara per i PM e per i sottoposti. Da ciò è anche in grado di stabilire tempi e costi e di suggerire modifiche/aggiunte al progetto. In teoria dovrebbe imporsi in modo furioso e brutale ai Commerciali per evitare che questi ultimi vendano al cliente soluzioni impossibili da realizzare nei tempi e modi previsti.

Nota bene: le figure dai titoli ampollosi (Lead Senior Architect Manager Chief Executive Vice President Analyst...) servono solo per dire "non ti do un aumento di stipendio ma ti potrai vantare su Linkedin di essere qualcuno importante qui dentro".

---

* Il tipico guaio: due o più incarichi alla stessa persona.

La figura dell'Analista Programmatore, cioè dell'esperto creativo capace di fare tutto da solo (dall'Analyst al Programmatore, appunto) tranne la parte commerciale, è una figura mitologica leggendaria inventata da certe aziende italiane che volevano risparmiare sugli stipendi. Fin da quando ero ragazzino, infatti, ho sempre trovato gente che mi dice: "Ma tu Perché Non Fai Qualche Grosso Programma e Lo Vendi?"

("Anche mio Fuiglio, ma non perché mio Fuiglio, è Muolto Bruavo con Guìndous Nuovanta Ciuinque!")

Infatti quando la stessa persona ha due o più incarichi, sono guai. Per esempio:

- il System Analyst è anche il Commerciale: dunque diventa irragionevolmente ottimista sui tempi e modi di realizzazione;

- il Programmatore è anche Tester: dunque scrive e modifica programmi senza provarli per bene, specialmente se il tempo è scarso e il cliente scalpita;

- il Project Manager è anche System Architect/Analyst: dunque tenta di ridurre i test in modo da risparmiare tempo necessario allo sviluppo...

- il PM è anche System eccetera e Commerciale: dunque applica il mercato delle vacche alla realizzazione del software ("Presto! Presto! è pronto? Presto! a che punto siamo? Presto! Presto! basta che regga in piedi, poi lunedì ricontrolliamo!").


Caso estremo: il team di sviluppo software è così composto: quattro figure Lead Architect Senior Specialist Solutions Manager, tre Commerciali, un PM, e un Programmatore che funge anche da Tester, Designer, System Architect, System Analyst. "Allora, è pronto?"

4 menager li tenemo, l'analista funzionale pure, er coach agile ce sta, mò ce basta un programmatore junior e amo fatto er team de 7 persone

— Aggile Giggi (@agilegigi) 2017

---

Conclusione

Domanda (fatta con voce sgomenta): ma... ma tu dove hai lavorato?

Risposta: in Italia.

Specifiche (cioè il contrario di "vedémo, mettémo, levàmo, checcevò?")

Mini serverino casalingo Intel NUC (in basso)
con scheda grafica esterna (in alto)
inclusa nel suo specifico case esterno con ventole
e collegata al serverino su porta Thunderbolt 3.
Non c'entra niente con l'articolo ma mi piace.

Per scrivere un software servono le specifiche, cioè la descrizione completa, precisa, senza ambiguità, coerente, verificabile, sia per il contenuto che per l'autorità ("chi" può aggiornare "cosa"), tracciabilità ("chi" ha stabilito "cosa"), priorità ("questo" è più importante di "quello"). In breve: le specifiche servono a togliere dubbi passati, presenti e futuri.

Più è delicato il software e più le specifiche devono rispettare quelle caratteristiche. Ogni ambiguità o mancanza, infatti, sostituisce l'ingegnerizzazione con la fantasia e le incertezze (e dunque la fretta e la confusione) di chi dovrà scriverlo, collaudarlo e documentarlo. Le specifiche non devono dire quanto tempo e quante risorse servono: questi sono infatti aspetti commerciali, non tecnici, e vanno concordati in altra sede.

Quando alla committenza viene dimostrato che le specifiche fanno veramente cagare, immediatamente cambia idea (il che significa che lo sapevano già e che nel frattempo hanno tentato di prenderti per il sedere). Per questo è indispensabile continuamente dichiarare a prescindere che le specifiche fanno cagare: in tal modo la committenza sfoltirà da sola, a poco a poco, gli svarioni più madornali, oppure rifilerà il pastrocchio a qualcuno più ingenuo di te.

Vediamo qui sotto alcuni esempi in cui bisogna prendere a calci nel sedere chi ti consegna specifiche non proprio perfette.

---

Esempio 1: specifica incompleta o addirittura inesistente.

"Ma come? ti ho scritto una mail di due pagine per spiegarti come devi realizzare una via di mezzo tra Facebook e Twitter orientata alla vendita di cibo per cani, e ti lamenti pure?" ... "Ma come? ti ho detto in ogni dettaglio come devi realizzare un clone del prodotto Sbirgnaus del nostro concorrente e aggiungere l'indicizzazione, e ti lamenti pure?" ... "Ma come? ti ho girato i risultati di ricerca Google su come si implementa il protocollo, e ti lamenti pure?"

No comment.

---

Esempio 2: specifica imprecisa o troppo generica.

"Ma come? ti ho detto che per sicurezza gli accessi devono essere protetti da password, e ti lamenti pure?"

Spiegazione (molto breve) di "protetti da password": database utenze con replicazione, validazione e scadenze password, canale criptografato e workaround conseguenti, separazione privilegi dentro e fuori, livelli di clearance per la manutenzione, aggiornamenti di sicurezza continui con relativi restart, nuove limitazioni alle vecchie e nuove procedure, misure anti-hacking e relativo collaudo, simulazione di intrusione e relativa mitigazione, compliance con le best practices, possibile riscrittura from scratch di procedure basate su librerie obsolete, poco manutenute, o di dubbia fama... (poi i mega-manager si chiedono come mai ragazzini craccano siti web e programmi)

In altre parole: la specifica doveva spiegare cosa si intendeva per "sicurezza" e quali passi occorrono per ottenerla. Non è che uno dice "password" e magicamente le minacce che verranno inventate in futuro vengono già sconfitte.

---

Esempio 3: specifica ambigua, tipicamente da parte di chi non sa esattamente cosa vuole.

"Ma come? nella specifica c'è scritto chiaramente che l'User Id è incrementato automaticamente e che non devono esistere due utenti con lo stesso account, cos'è che non si capisce?"

Ambiguità: non si capisce se lo User Id è unico, e non si capisce nemmeno se Utente e Account esprimono lo stesso concetto. Per esempio sarebbe stato molto più chiaro così: "l'Account utente è univocamente identificato da un User Id, unsigned 32 bit che cresce monotonicamente".

"Ma come? nella specifica c'è scritto chiaramente che le API supporteranno JSON e XML. Di che ti lamenti?".

Ambiguità: supporteranno adesso oppure in futuro? Le specifiche devono parlare come se il software che descrivono esiste già. Le specifiche non sono letteratura, non servono a far bella figura, ma a farsi capire da chi deve lavorarci su. Devono dare risposte, non domande. Devono fugare dubbi, non crearne.

---

Esempio 4: specifica non autoritativa, cioè l'estensore non sa fare il suo mestiere.

"Ma come? nella specifica c'è scritto chiaramente che crediamo che siano da supportare più interfacce e che siete invitati ad aggiungere quelle che vi sembrano convincenti, e indicarle qui sotto..."

Questa non è una specifica ma solo l'opinione di uno che ha le idee poco chiare, e che invece di spiegare cosa va fatto e come va fatto chiede opinioni e iniziativa. In realtà andava scritta così: "sono da supportare solo le interfacce Sbrauz 1.x e Sbarabambagnaus, più la Sbrauz 2.0 in sola lettura per i flussi singoli".

Se si prevedono aggiornamenti, possono provenire solo dalla stessa autorità che l'ha scritta e sempre rispettando le sue caratteristiche: "aggiornamento (GD, 47/2017): il supporto della Sbrauz 2.0 deve prevedere anche la lettura di flussi multipli, come documentato negli allegati tecnici 131-GD-2017 e 133-GD-2017".

---

Esempio 5: specifiche non verificabili, cioè confusionarie.

"Ma come? non è chiaro? l'utente deve poter scorrere la lista immagini dei prodotti in modo veloce e fluido".

Il requisito funzionale ("scorrere immagini") viene vincolato a uno non funzionale, addirittura un concetto ambiguo ("scorrere veloce e fluido"). La parte funzionale è verificabile (si può facilmente stabilire se il software permette di scorrere la lista immagini o no), la seconda parte non è verificabile ("quanto" deve essere veloce? come si misura la fluidità? in quali ambienti deve risultare veloce e fluido?), e addirittura non si capisce se sia più importante la lista o la velocità. Certo che se metto una sola immagine sarà tutto veloce e fluido, no?

Magari poi ti arriva un nuovo requisito funzionale: "scorrere anche le sotto-liste di prodotti". La fluidità si deve applicare anche a queste? Quanto veloce deve essere? Ok, "entro 500 millisecondi": ma su quale piattaforma hardware? con quante immagini e di che dimensioni? Da quale momento deve cominciare il conteggio dei 500: dall'inizio del caricamento della pagina, o dal suo completamento?...

"Ma di che ti lamenti? i report vengono generati in PDF quando richiesto, e devono essere scaricati o inviati via e-mail. Più chiaro di così?"

Confusionario. I report di "cosa" e generati da "chi"? Dell'utente o del manutentore? In quali circostanze possono essere "generati" e in quali no? La confusione è dovuta all'esprimersi con verbi impersonali e senza far capire chiaramente "chi" fa "cosa".

---

Esempio 6: micromanagement, cioè specifiche che scendono troppo nei dettagli.

"Ma di che ti lamenti? l'utente deve autenticarsi attraverso Facebook cliccando sul tasto di login, e il suo username, avatar ed email andranno inseriti in database".

Le specifiche devono essere complete ma questo non significa spiegare i minimi dettagli. Non si capisce se il dire "inserire in database" implichi come requisito l'avere un database in più, oppure è solo un suggerimento di usare qualcosa di concettualmente simile ad un database. E non si capisce se l'inserimento riguarda solo quei quattro campi oppure se riguarda almeno quei quattro campi.

---

Esempio 7: specifiche incoerenti.

"Ma di che ti lamenti? il nostro obiettivo deve essere un'interfaccia user friendly ottimizzata per le prestazioni; la parte client va scritta in Java perché così sarà più veloce".

E quando la parte user friendly impedisce di ottimizzare meglio le prestazioni, quale dei due concetti va considerato? E come si fa a verificare quale dei due obiettivi (o entrambi) è stato raggiunto? E cosa garantisce che il solo "scrivere in Java", in quel preciso contesto, migliora la velocità percepita dall'utente finale?

---

Esempio 8: specifiche senza glossario, le capisce solo chi le ha scritte.

"Ma di che ti lamenti? il TDR delle richieste va in TO a 3000, più chiaro di così!"

Solo che non c'era un glossario che ti dice "TDR = tempo di risposta espresso in millisecondi" e "TO = timeout". Il primo caso è un concetto noto ma espresso con una sigla gergale (e non necessaria), interna a certi settori dell'azienda, il secondo caso è un concetto noto ma espresso con una sigla inutile (nessuno abbrevia "timeout", tanto meno con "TO"). Le sigle come TCP/IP, FIFO, ecc., rintracciabili su wikipedia vanno bene; ma le sigle sconosciute all'esterno dell'azienda vanno spiegate tutte.

Come PAGARE POCO i programmatori!!

Quando un'azienda ha bisogno di produrre software, deve affrontare una spesa fastidiosa e imprevista: pagare i programmatori. Che non rispettano quasi mai le scadenze di consegna decise a tavolino dai manager. Che a volte hanno bisogno di un giorno di ferie per questioni familiari, e certe volte addirittura si ammalano. Che a volte addirittura si licenziano per andare a lavorare da qualche altra parte o mettersi in proprio. Che in certi casi trovano addirittura l'appiglio per chiedere aumenti di stipendio.

Vediamo dunque i Dieci Trucchetti per Pagare Poco i Programmatori, tutti basati sul principio che per pagare il meno possibile bisogna non solo tener bassi gli stipendi, ma anche dar loro meno appigli possibili.

1) La paga deve essere un argomento tabù. Nell'azienda non si deve mai discutere di stipendi, bonus, benefit, eccetera. Non sia mai che un programmatore scopra di essere pagato meno di qualche collega nullafacente e incompetente. Non sia mai che un programmatore capace e di grande esperienza scopra di avere lo stesso stipendio della segretaria. Se nell'ambiente l'argomento è già tabù (come quasi ovunque a causa delle invidie e dei curiosoni che ti fanno i conti in tasca su ogni cosa), i nuovi arrivati si adegueranno subito, credendo magari di essere dei privilegiati ed eviteranno di far domande scomode.

2) Aumenti e benefit devono essere del tutto imprevisti. Non devono esserci regole (neppure verbali e informali) su quando e come arriverebbero, per evitare che qualcuno se ne ricordi e soprattutto per evitare che qualcuno pensi di meritarne a causa dei risultati appena raggiunti. Se chi ha il potere di decidere gli aumenti li concede in maniera imprevedibile, anche i più meritevoli resteranno lungamente in attesa di quel momento magico, anche se si sentono sottopagati.

3) Tener tutti sotto controllo. Server di posta aziendale, computer aziendale, magari anche telefonino aziendale, videocamere di sorveglianza e macchina aziendale con tracking GPS. Anche senza spiarli davvero, bisogna fare in modo che non osino contattare altre aziende o abbiano conversazioni "private ma di lavoro" durante gli orari di lavoro. La sola paura di essere scoperti a "tradire" l'azienda per qualche dollaro in più è un ottimo deterrente alle richieste di aumenti di stipendio e benefit.

4) Accordarsi coi concorrenti: io non tocco i tuoi, tu non tocchi i miei. Se qualcuno dei miei ti manda un curriculum, voglio essere il primo a saperlo, e farò altrettanto per te. Tra manager ci s'intende - questo genere di accordi funziona benissimo - e se qualche manager non si accordasse lo capirà non appena tenterai di reclutare personalmente qualcuno dei suoi migliori programmatori offrendogli un dieci-quindici per cento in più di quanto già prendeva.

5) Stressare i programmatori. Non devono mai sentirsi freschi o rilassati. Devono sempre avere scadenze strette, problemi da risolvere, compiti arretrati da riconsiderare, e parecchi sensi di colpa - grazie ai quali si sentiranno a disagio nel chiedere aumenti. Il progetto deve sempre sembrare in ritardo e loro devono sentirsi il più possibile responsabili di intoppi e problemi, temendo di sentirseli rinfacciare in caso di richieste di aumenti.

6) Promettere non significa mantenere. Perciò si possono promettere futuri aumenti, imminenti investimenti, ma sempre da rinviare ad un imprecisato "momento giusto" dopo le calende greche, mai da associare a eventi importanti e verificabili. Poi, al "momento giusto", invece dell'aumento si può comprare una nuova lussuosa macchinetta per l'angolo caffè, cosa che susciterà vasto plauso e costerà meno di un singolo aumento.

7) Distribuire titoli nobiliari. In certi posti con molto personale questa strategia funziona perché i gonzi provano più gusto a scrivere sul proprio Linkedin i titoloni insignificanti Technical Architect Team VicePresident Senior Lead Consultant Specialist Manager che chiedere quanto manca ancora al benedetto "momento giusto" di quell'aumento più volte promesso e mai arrivato. E quando veramente meriterebbero un aumento, invece di concederlo falli sentire importanti: fa' chiamarli da uno degli altolocati super-manager che reciti loro un bel sermone sugli ottimi risultati conseguiti, consegni un'elegante lettera di encomio, e dia perfino in omaggio il prestigioso portachiavi aziendale (o gadget altrettanto insignificante).

8) Costruire un ambiente "familiare". Eventi aziendali, torte di compleanno, panettone a Natale e colomba a Pasqua, posto auto come se fosse un prezioso ineguagliabile diritto, angolino caffè con lussuosa macchinetta a cialde e distributore automatico di merendine, magari il diritto di portare il proprio cane in ufficio, o addirittura la Giornata dei Figli in Ufficio, talvolta persino scrivanie nuove e computer ben carrozzati (meglio spendere seicento euro per un PC nuovo che dare cento euro mensili di aumento). A furia di ripetere che i soldi "non sono tutto", di fronte a tutti questi micro-benefit uno si sentirà traditore dei valori familiari-aziendali nel chiedere un aumento...

9) Concedere generosamente aiutini. Deve comprare la macchina e non sa come gestire le rate? Deve organizzarsi per qualche cartella delle tasse? Deve prenotare una visita specialistica? Deve spedire i punti della Mira Lanza e gli mancano busta e francobollo? Si faccia in modo che la segretaria sbrogli le loro pratiche (così anche lei produce qualcosa di più utile che le solite telefonate e fotocopie) e loro pensino di aver immeritatamente sfruttato risorse aziendali per i propri comodi.

10) Sii un amico. Questa è la tecnica più potente di tutte. Devi essere amico dei tuoi programmatori, perché è difficile negoziare soldi con un amico. Per cui in aggiunta a tutti quei benefit che costano poco all'azienda, aggiungi telefonate non di lavoro, la cena con le loro famiglie (magari anche a casa tua), perfino i biglietti omaggio per il cinema "non posso usarli ma so che a tua moglie piacerebbe vedere quel film". All'amico è difficile dire di no quando si tratta di rimanere in ufficio oltre l'orario di lavoro, ma guarda caso l'amico del programmatore non ha mai tempo per parlare di busta paga e di aumenti. E poi, programmatore incontentabile e viscido, dopo tutto quello che l'azienda ha fatto per te vieni pure a chiedere altri soldi?

Promemoria: ridurre il proprio CV

La miglior cura contro la stitichezza è quando il capo mi dice: «ce sarebbe 'sta risorsa, te giro er civvù». Infatti nel campo dell'informatica i curriculum vitae sono un ottimo lassativo.

Per valutare bene una risorsa occorre leggere il codice sorgente che ha consegnato e che è stato utilizzato oltre che rivisto, le soluzioni che ha escogitato, modi e tempi in cui ha corretto i bug, e poi anche farsi un'idea delle persone che usano le sue soluzioni, dei feedback che hanno dato... Insomma, non storcete il naso: bisogna davvero guardare ai suoi contributi open source: sono sotto gli occhi di tutti (cappellate e genialate incluse), non sono protetti da clausole di segretezza, confermano se c'è una passione oltre che una capacità, fanno capire come scrive e cosa rilascia... Molto meglio di ciò che possono fare un curriculum e diversi colloqui.

Perciò la prima domanda deve essere: quali sono i progetti open source a cui hai collaborato? Quale è il tuo portafoglio progetti su Github o piattaforma simile?

Se uno ha pubblicato poco o niente, significa che o è troppo timido (teme che i suoi sorgenti facciano schifo? ha paura di ricevere feedback negativi o di non riuscire a migliorarsi?), oppure che lavora solo per sopravvivere (per cui al di fuori dell'orario di lavoro pensa ad altro, cioè non ha passione), o che non riesce a rendere minimum viable product i propri progetti perennemente incompleti, o semplicemente gli manca creatività. Tutti e quattro sono pessimi indicatori, tanto più che la maggioranza dei tool indispensabili in ambiente di lavoro sono open source.

La seconda domanda deve essere: quali sono i tuoi contributi al risolvere problemi pubblicati on-line? Per esempio: quale è la tua "reputazione" su domande fatte e domande a cui hai dato risposta su siti come StackOverflow?

Infatti chi non domanda non apprende, oppure si limita a chiedere a Google qualcosa di già pronto, o semplicemente non sa domandare (non necessariamente per timidezza). Inoltre, chi non risponde non ha niente da dire, cioè non sa cimentarsi su problemi complicati o assai specifici. Troppo facile mettere insieme soluzioni già pronte e incassare lo stipendio a fine mese e chiamarla "esperienza pluriennale" (come se questa, da sola e senza bisogno di verifiche, garantisse automaticamente qualità e utilità).

Spesso questi soggetti si giustificano dicendo che basta parlare coi colleghi per trovare soluzioni. Se in certi casi può essere vero, in generale significa dipendere troppo dai propri senpai - e se capita qualcosa di urgente e i tuoi colleghi esperti sono assenti? Quando si viene pagati a deliverables, nessuno ha voglia di aiutarti per più di venti secondi (e ti è già andata bene), e a memoria d'uomo nessun problema tecnico serio è mai stato veramente risolto con due chiacchiere in pausa caffè (cioè stando lontani dai documenti e concentrati su altro); telefonate e meeting sono una pura perdita di tempo (impossibile negarlo, al massimo servono per dire chi fa cosa), le email richiedono troppo tempo per essere ordinate (e restano comunque dispersive); solo i sistemi di ticketing sono meno inefficienti (a condizione che vengano usati con serietà anziché come l'ennesimo ammennicolo di cui sotto sotto tutti vorrebbero fare a meno).

La terza domanda deve riguardare quanto si investe su sé stessi. Cioè - ad esempio - le certificazioni prese a pagamento, specialmente quelle in cui non superando l'esame finale sono persi i soldi spesi per prenderle. Se uno cresce quasi esclusivamente per contributi "esterni" significa che non investe nella propria crescita, aspettando che vi investano "altri".

Chi investe su sé stesso lo fa per non essere come la massa: lo fa su qualcosa di nicchia, e lo fa bene. Di "programmatori Java" o di "esperti SQL" se ne trovano fin troppo facilmente: cos'è che ti distingue? Quando uno si qualifica come "esperto MySQL + Oracle + SQLite + PostgreSQL" significa che di database ne capisce il minimo indispensabile. Come il resto della massa di "esperti SQL".

Vale anche per attività esterne, come ad esempio l'aver tenuto una talk a qualche conferenza o aver pubblicato un libro o un brevetto: se uno riesce a tenere una talk non dico al Chaos Communication Congress ma almeno a PGconf.eu, RustFest, RubyConf o simili, significa che ha superato una non banale peer review oltre ad aver investito tempo e soldi. Anche un blog su temi informatici può essere un buon indice, qualora i contenuti siano di qualità (non un Aranzulla) e il contenuto dei commenti lo confermi (più con le domande specifiche che con i complimenti).

Inutile aggiungere che tutti questi esempi già da soli dimostrano la padronanza dell'inglese ed eventualmente di altre lingue, la capacità di pianificare, organizzarsi, collaborare, la creatività, il saper estrarre conoscenze e risultati, la capacità di trovare soluzioni... Nelle aziende generalmente si ignora che il vero lavoro in team è quello fatto da individualisti capaci che fanno la propria parte senza coinvolgere (cioè rallentare) gli altri. Ignorandolo, diventa statisticamente normale che più di due terzi dei progetti IT falliscano.

Insomma, le robette che si scrivono nei curriculum - aziende presso cui si è prestato servizio, anni di "esperienza", titoli di studio (tranne che di università estere particolarmente selettive), non significano granché. E non vale la pena assumere uno con tante conoscenze ma poca capacità di sfruttarle e di farle crescere.

Non tutte le offerte di lavoro sono ghiotte e irrinunciabili opportunità

Premessa: le frasi citate in neretto provengono da vere telefonate che ho ricevuto.

---

“Stiamo cercando una figura professionale seria,

ci serve un vero Batman”

Traduzione: lavorerai come un Batman (incluse le ore notturne) ma con la paghetta di un tirocinante ventenne sbarbatello, poiché qui oltre ad essere senza soldi siamo nella merda: col cliente abbiamo fatto una figuraccia molto poco professionale e molto poco seria.

Come rispondere: «se avete deliberato che vi serve un Batman, saprete già che vi costerà più un incredibile Hulk; se il netto annuo ha meno di sei cifre, allora non possiamo neppure proseguire la telefonata».

---

“Questo nostro progetto è speciale,

è particolarmente interessante”

Traduzione: siamo nella merda e non possiamo dirti di cosa si tratta perché siamo stufi di sentirci mandare a cagare, il progetto va portato in porto anche se sono state sbagliate tutte le decisioni iniziali e intermedie, e comunque gli aggettivi "speciale e interessante" valgono già come busta paga.

Come rispondere: «ottimo! per il CERN ho già lavorato, e aspettavo con impazienza che voi della NASA mi contattaste proponendomi uno stipendio strepitoso, liberandomi da proposte molto ben pagate».

---

“No, così saremmo fuori budget... Però le assicuro

che ci sono ottime opportunità di crescita”

Traduzione: siamo senza soldi, ma il termine "opportunità di crescita" vale già come busta paga.

Come rispondere: «benissimo! aspetto con impazienza una vostra chiamata non appena le "opportunità di crescita" si saranno realizzate e saranno entro il budget».

---

“È un lavoro in sede, in orari di ufficio”

Traduzione: in un angolino di un chiassoso open space (o forse in corridoio) rimedieremo una sedia sgangherata e vecchio e rumoroso PC per te, ma siccome siamo nella merda tienti pronto anche a qualche trasferta dal cliente e a lavorare anche di sabato e domenica. Entrambe le sedi non sono proprio facili da raggiungere, ma ti ci abituerai presto.

Come rispondere: «ancora non ho capito quale è esattamente la mia mansione e la mia retribuzione netta».

---

“Buonasera, come va? Tutto bene?”

Traduzione: spero che a furia di telefonarti ogni mese per riproporti sempre la stessa offerta che hai sempre rifiutato, tu prima o poi ceda.

Come rispondere: «non sono interessato a lavorare nella vostra azienda».

---

“Stiamo portando avanti un grosso progetto

e abbiamo notato il suo interessante profilo Linkedin...”

Traduzione: siamo nella merda e stiamo disperatamente contattando cani e porci, perfino i profili Linkedin abbandonati da anni come il tuo.

Cosa rispondere: «perbacco, è davvero così vecchio e sgangherato il codice sorgente del vostro progetto?»

---

“Abbiamo visto alcuni suoi sorgenti software nell'internet”

Traduzione: lo sappiamo bene che sono solo briciole; ci interessano invece i dettagli tecnici della soluzione che hai consegnato ad un certo nostro concorrente...

Cosa rispondere: «come? volete pagarmi per sviluppare in open source? grandioso!»

---

“Richiediamo uno particolarmente skillato

molto competente ed esperienziato

disposto anche a spostarsi per qualche mesetto”

Traduzione: tutti i nostri tecnici hanno famiglia e non sono disponibili a trasferirsi per sei mesi a ottocentonovanta chilometri da casa, siamo nella merda e ci serve urgentemente un Batman da piazzare in quelle lande brulle e desolate presso le sedi del cliente.

Cosa rispondere: «tengo famiglia, mi è appena morto il cane, e con la paga che mi proponete mi sentirei in imbarazzo perfino a lavorare solo un pomeriggio a settimana a casa mia. Ma voi non avevate a disposizione quel tirocinante ventenne psicolabile che non vedeva l'ora di girare per il mondo?»

---

“Per il nostro progetto c'è bisogno di uno

con dieci anni di esperienza in

#{tecnologia_nata_sei_mesi_fa}”

Traduzione: siamo nella merda e dopo numerose estenuanti riunioni abbiamo deciso che ci serve al più presto una bacchetta magica e soprattutto uno che la sappia usare.

Cosa rispondere: «ma davvero? io sono uno di principali progettisti di quella tecnologia, abbiamo cominciato quindici anni fa a implementarla...»

---

“Se conosce qualche altro sviluppatore interessato

a lavorare sul nostro progetto, mi faccia sapere”

Traduzione: siccome siamo nella merda, non fa differenza se accetti tu o se prendiamo un altro, l'importante è che qua si ricominci a lavorare Asàppe* perché il cliente ci sta già facendo un culo così.

Cosa rispondere: scegliere tra «OK, mi impegno a fare io il vostro lavoro di ricerca del personale» oppure «ne conosco un paio: quale sarebbe la mia commissione per ogni persona che vi presento?»

*Asàppe = traduzione in romanesco del termine gergale americano "ASAP" (As Soon As Possible).

---

“Quanti anni di esperienza ha in

#{tecnologia_morta_da_anni}?”

Traduzione: l'ultimo nostro dipendente che la conosceva ci ha lasciato un mese fa e siccome non troviamo un sostituto siamo nella merda.

Cosa rispondere: «mai sentita nominare; può ripetermi il nome?»

---

“Abbiamo un'attività spot”

Traduzione: siamo nella merda perché per risparmiare sui costi abbiamo fatto fuggire tutti i dipendenti che avevano il know-how, e ogni volta che un cliente ci chiede qualcosina noi gli rispondiamo «vedémo, mettémo, levàmo, checcevò?» in modo da prendere tempo per trovare un tecnico molto professionale ma molto economico che ci tolga rapidamente le castagne dal fuoco e si tolga dalle balle subito dopo che l'attività è completata.

Cosa rispondere: «a sor Peppì, ma vàttela piànderculo».

Promemoria: domande prima di accettare di prendere in carico un software

Elenco delle domande da fare (cioè delle risposte da ricevere chiaramente per iscritto) ogni volta che mi fanno ereditare un progetto software fatto da altri.

Sviluppo:

- come si fa a installare i tool di sviluppo?
- devo usare per forza il vostro IDE? se sì, perché?
- compilatori e librerie: state usando le versioni più recenti? se no, perché?
- come e quando vanno aggiornati compilatori e librerie? a chi fare riferimento?
- quale sistema di version control si usa per i sorgenti? a chi fare riferimento?
- quali sistemi di bug tracking? sono integrati col version control? a chi fare riferimento?
- quali convenzioni occorre rispettare nel codice?
- cosa si usa per la documentazione?
- chi e quando fa la revisione del codice?
- c'è un database? viene aggiornato? c'è un DBA a cui fare riferimento?

Collaudo:

- come si fa il deploy di prova? e in ambiente di collaudo? e in rilascio?
- chi e come conferma la correttezza dei deploy? se fallisce, chi e quando se ne deve occupare?
- chi e come può accedere ai log? posso accedere ai log aggregati? se no, perché?
- come si eseguono i test? i test disponibili coprono tutta la casistica?
- riguardo alla sicurezza, ci si può già fidare a mettere il progetto in "produzione"?
- quale è normalmente il carico di lavoro? come si può misurare?
- può sopportare carichi improvvisi e imprevisti? si può verificare?

Esercizio:

- come posso sapere se una mia modifica ha drasticamente rallentato o appesantito il sistema?
- cosa perde il cliente in caso di disservizio in esercizio?
- il contratto col cliente prevede una SLA? chi è il responsabile che la deve assicurare?
- le violazioni alla SLA sono trattate come bug del software?
- in caso di disservizio dovuto a fattori esterni, entro quanto tempo deve tornare operativo il sistema?
- cosa deve succedere in caso di disservizio iniziato in giorni festivi?

Cosa significa essere "della vecchia scuola"

Un giovane app developer sveglio e brillante ed un burbero panciuto cinquantenne programmatore old-school stanno bevendo qualche drink al bar. Dopo qualche bicchierino di troppo, decidono di avviare un Potente Progetto sulla Sicurezza di Internet: scandire ogni mese tutti gli indirizzi IPv4 e tener nota degli host che rispondono al ping e che hanno aperta qualche porta FTP o Telnet, espandendo magari in futuro il software per supportare qualche altra porta.

Vediamo le differenze tra il giovane e pimpante skilled App Developer e il vecchio trippone programmatore rispetto a quattro punti importanti:

1. come si fa;
2. quale metodo è il più veloce;
3. quale è il più estensibile (aggiungere altre porte);
4. quale è il più costoso in termini di potenza di calcolo, memoria, disco.

---

1. Scelta del linguaggio di programmazione.

AppDeveloper: bisogna usare Python, facile da imparare, performante, facile da manutenere.

Trippone: per queste cose si lavora in C, veloce, performante, grosso modo facile da manutenere.

---

2. Scelta delle strutture dati.

AppDeveloper: eh, qui bisogna usare JSON (che oggi si usa dappertutto, è facile da leggere, e tutti lo sanno usare): ogni host sarà descritto da qualcosa del tipo:

{
 "ip": "123.45.67.89",
 "state": "up",
 "ports": {
  "20": "open",
  "21": "open",
  "23": "closed",
 }
}

Gli indirizzi IPv4 sono 2³², cioè circa 4,2 miliardi, di cui stimeremmo circa 300 milioni attivi. Sono sufficienti perciò 50-60 gigabyte di spazio su disco. Aggiungere altre porte è banale: basta qualche riga in più nel pacchetto JSON.

Trippone: lo stato è solo up/down (1 bit), le tre porte sono solo open/closed (1 bit ciascuna), per cui bastano quattro files che contengano un array di bit (4,2 miliardi di bit = 512Mb ciascuno = due gigabyte totali di spazio su disco). Aggiungere altre porte è banale: basta qualche file in più di 512 Mb.

---

3. Statistica mensile sugli host attivi e sulle porte open

AppDeveloper: ooh, qui facciamo Big Data! Posso scandire l'archivio con la tecnologia Hadoop, oppure indicizzare i documenti JSON aggiungendo un file indice di una decina di gigabyte. Per esempio conosco qualche libreria che...

Trippone: mi basta contare i bit uguali a 1 nel rispettivo file di 512Mb; può bastare una banalissima lookup-table del tipo: "quando vedi un byte 11010011 allora aggiungi 5 al conteggio". Praticamente è O(n) con una costante piccolissima.

---

4. Verifica di un singolo indirizzo IP

AppDeveloper: ehi, smart! qui mi basta fare una ricerca binaria nel file indice di una decina di gigabyte, ed estrarre il pezzetto JSON che ci interessa. Se la ricerca non trova nulla, allora l'host è down e non ha porte open.

Trippone: l'archivio indirizzi è sequenziale (512 Mb) per cui in O(1) si trova la posizione del bit in ognuno dei file e dal valore 0/1 si capisce up/down o open/closed.

---

5. Verifica di un gruppo di indirizzi IP (per esempio una subnet/24)

AppDeveloper: cool story, bro! mi basta scandire il file indice e fare pattern-matching con le regular expressions. Oppure fare 256 ricerche binarie sugli indirizzi di tutta la subnet (poiché infatti una subnet/24 corrisponde a 256 indirizzi).

Trippone: avendo mappato gli indirizzi IP consecutivamente, una subnet/24 consisterà di 256 bit consecutivi: basta calcolare l'indirizzo del primo e leggere i 256 bit (cioè 32 bytes) a partire da lì dal file corrispondente di 512 Mb. Praticamente O(1).

---

6. Conteggio del numero di host che hanno una determinata combinazione di porte open

AppDeveloper: oh, yeah, American Dream! questo è un lavoro Bìggh Dèta per la tecnologia Hadoop, bisogna scrivere un map/reduce, oppure si può fare aggiungendo un nuovo indice.

Trippone: è di nuovo un conteggio? basta scandire i quattro file 512 Mb confrontando i singoli bit con la combinazione richiesta. Complessità lineare: O(n) sul numero dei files.

---

7. Conteggio di quanti host sono stati attivi durante gli ultimi tre mesi

AppDeveloper: don't break my heart, babe! per ogni mese creiamo un'apposita directory con il database e gli indici; quindi estraiamo da ogni database una lista di host attivi, e quindi joiniamo e deduplichiamo le ultime tre liste.

Trippone: creeremo un'apposita directory per ogni mese; basterà fare un'operazione "OR" bit a bit del file binario host delle ultime tre directory, conteggiando i bit risultanti a 1. Complessità O(n) con costante molto piccola.

---

8. Conteggio di quanti host sono stati aggiornati questo mese (cioe da up a down o viceversa)

AppDeveloper: I'm a Belieber, Justin! è facile, anche se costosetto: basterà scandire l'archivio di questo mese, estrarre il JSON di ognuno dei circa 300 milioni di host rispetto al mese precedente e verificare up/down e down/up.

Trippone: basterà fare un'operazione "XOR" bit a bit del file binario host degli ultimi due mesi, conteggiando i bit risultanti a 1. Solita O(n) con costante molto piccola.

---

9. Conteggio di quanti host sono stati attivi in almeno x degli ultimi 12 mesi.

AppDeveloper: funny compilation, dude! l'operazione è lunghetta perché bisogna creare un nuovo database in cui inserire i campi "indirizzo" e "mesi attivi", e poi scandire uno per uno i dodici database precedenti per aggiornare i conteggi, ed infine conteggiare quelli in cui il campo "mesi attivi" è maggiore o uguale a x.

Trippone: creo in RAM un array di 4 miliardi di interi da 4 bit ciascuno (dunque mi occupa 2Gb RAM), leggo uno per uno gli ultimi 12 mesi aggiornando i contatori corrispondenti. Alla fine conto quanti sono maggiori o uguali a x. Se invece la RAM scarseggia, allora posso suddividere l'operazione in "fette" da 16Mb-256Mb e sommare infine i conteggi parziali. Alla fine della fiera, in entrambi i casi, la complessità è O(n) con costante molto piccola.

---

Indovinate perché il giovane e sveglio app developer se n'è andato via stizzito e imbufalito.

L'esperienza nel campo dell'informatica

Di recente ho incontrato un amico a cui era stato proposto un licenziamento con ricca buonuscita. Lui ha accettato - pareva un ottimo affare - ma ora si ritrova in difficoltà a trovare un altro lavoro.

Questo amico ha lavorato nel settore informatico per più di trent'anni, evolvendosi da computer operations a system administrator fino a DevOps man mano che il campo maturava. Quando gli capitava la possibilità di far carriera nel management lasciava perdere, concentrandosi piuttosto sull'acquisire altre skill tecniche. Insomma, è come se avesse messo le mani su qualsiasi cosa dall'introduzione delle workstation fino ai cloud.

E questo potrebbe essere il motivo per cui oggi nessuno vuole assumerlo. Mi dice: "Vado a fare colloqui e mi vedo davanti dei manager di quindici o vent'anni più giovani di me. E conosco molte cose più di loro, ho visto molto più di loro, fatto molto di più... e penso che questo li spaventi".

Non aveva mai immaginato di ritrovarsi, poco dopo i suoi cinquant'anni, a chiedersi cosa ne sarebbe stato del mondo dell'informatica.

Anche se quel mondo ama spacciarsi come un concentrato di competenze di giovani pimpanti, molte delle sue esigenze hanno origini in tecnologie vecchie di almeno qualche decennio. Unix ha superato da poco i quarant'anni, il Web esiste da più di un quarto di secolo, e perfino gli Amazon Web Services vanno avanti ormai da quasi dieci anni.

Ora che l'informatica ha una sua storia dietro di sé, il vero valore sta in quelle persone che hanno contribuito a scriverla e che hanno imparato da essa. Vien fuori uno strano bug da qualche arcano tool degli ambienti Unix? È possibile che un vecchio professionista dell'informatica ne sappia già qualcosa, e sappia già come aggirarlo.

Nei primi anni '80 un lavoro in un dipartimento di informatica poteva tranquillamente durare un decennio e più. Gli informatici potevano passare da azienda ad azienda (come ho fatto io stesso) ma il personale delle operazioni backbone rimaneva lì, anno dopo anno, a garantire consistenza. Col risultato che le aziende potevano affrontare l'introduzione di nuovi servizi o dei tremendi cambiamenti tecnologici con minime interruzioni del servizio. Ed era quello staff di supporto che teneva insieme tutti i pezzi (spesso addirittura senza automatizzare nulla).

Oggi un'azienda può fare outsourcing del proprio dipartimento informatico delegandolo a qualche gigante indiano o filippino, se non addirittura usare servizi come Freelancer.com (e i suoi numerosi cloni) per "comprare talenti" sul mercato, frazionandoli a ore. È tutto più economico e flessibile, ma non c'è più la profondità di esperienza che proveniva da un lungo periodo di lavoro in un'azienda.

Insomma, il vero costo nascosto della tanto decantata "flessibilità" è la minor resilienza, cioè la minor capacità di affrontare problemi. I sistemi complessi diventano fragili laddove il talento che li ha messi in piedi è stato "tagliato" per ridurre i costi. Col risultato, specialmente in Italia in questi ultimi dieci-quindici anni, di grosse aziende che dopo aver "tagliato i costi" (cioè dopo essersi liberate del proprio personale competente, tenendosi in pancia solo gli aristocratici nullafacenti) non solo non crescono più tecnologicamente, ma fanno sempre più fatica a mantenere in piedi l'esistente.

È vero che un sysadmin arrabbiato poteva mettere in ginocchio la propria azienda. Ma è anche vero che un sysadmin con esperienza poteva salvarla da un disastro. Non è indispensabile affidarsi tutti i giorni a un tale talento, ma è bene averlo sempre in azienda, perché non sai mai quando ti diventerà necessario. L'esperienza è in fin dei conti la migliore assicurazione. Per formare un tecnico con cinque anni di esperienza sulla tua infrastruttura (che è diversa da quella dei tuoi concorrenti e dei tuoi simili), ti servono cinque anni: non c'è scampo.

Se nel mondo dell'informatica si comincia a ignorare la necessità di quelle esperienze, finirà che troveranno un altro modo di rientrare. Ho notato che il mio amico sopra citato ha cominciato a proporsi on-line trovando lì clienti che avessero bisogno della sua expertise. Ma sospetto che sotto sotto ci sia un movimento assai più vasto che potrebbe cambiare l'intero scenario.

Per mezzo secolo il mondo dell'informatica ha spazzato via posti di lavoro. Le legioni di impiegati e segretarie responsabili del mantenimento delle aziende si sono ridotte passando dalle macchine da scrivere ai computer, mentre il settore dei servizi - dal commerciale al finanziario, con tutto ciò che c'è nel mezzo - si è adeguato ai processi creati dai business analysts e dai programmatori e sysadmins.

Oggi quel serpente ha cominciato a mordersi la coda.

A gennaio abbiamo avuto un breve assaggio del futuro dell'informatica quando l'azienda canadese ROSS ha lanciato il suo omonimo prodotto basato su Watson, il "computer cognitivo" con tecnologia vagamente di intelligenza artificiale, e con una vasta libreria legale. ROSS analizza tutti i testi legali, li "capisce" in qualche modo, e offre suggerimenti e consigli su questioni legali.

Questo è già interessante: ma cosa succede se qualcuno ha la pazza idea di dare in pasto a Watson intere "biblioteche" informatiche (dai libri ai contenuti dei social network) come Stack Overflow, O’Reilly, Slashdot, Google Groups, GitHub e tutto il resto dei siti web che noi informatici utilizziamo come risorse per lavorare?

Negli scorsi anni abbiamo usato le tecnologie cloud per non dover più avere a che fare con servers fisici e centri di elaborazione dati. Quando il "Watson informatico" diventerà disponibile on-line (e io scommetto che succederà già durante quest'anno), istantaneamente automatizzerà una enorme parte del lavoro umano degli informatici che non sia stato già spazzato via dall'outsourcing. Cinquant'anni dopo aver reso inutili gran parte di impiegati e segretarie, l'informatica renderà inutile gran parte dei suoi lavoratori.

Qualcuno magari dirà che è la prevedibile eterogenesi dei fini.

Per fortuna l'informatica crea anche posti di lavoro. Certi business inconcepibili fino a pochi anni fa oggi prendono piede perché l'informatica ha permeato la nostra vita quotidiana. Quel mio amico ora cerca lavoro non presso un centro elaborazione dati, ma in qualche startup basata su ciò che essa stessa ha creato.

(mia traduzione annotata di

un articolo di Mark Pesce)

RUDAL, chi è costui ?

Ecco la proposta: un contratto di lavoro che includa una clausola di Risoluzione Unilaterale da parte del DAtore di Lavoro (RUDAL).

Cioè il datore di lavoro può licenziarti liberamente, dandoti solo il preavviso specificato nel contratto.

Ovviamente, se si firma un RUDAL con un preavviso breve, lo stipendio sarà più alto.

Vantaggi per il datore di lavoro: assumere e licenziare senza infognarsi in vertenze e cause.

Vantaggi per il dipendente: più è elastico e più lo stipendio è alto. Inoltre è più facile essere assunti, poiché il noto terrore dei datori di lavoro è di prendere un disonesto sfaticato a tempo indeterminato e non potersene più liberare.

Ne parla più estesamente Eugenio Benetazzo in questo articolo, che ha ricevuto un fiume di minacce da anonimi estremisti di sinistra, sempre pronti a difendere sindacalismi e Casta.