PUBBLICATO ORIGINARIAMENTE IL 22/05/2015
Che lavoro fai nella vita? programmatore!!
ohhhh che lavoro figo.... si certo!!!
Bene, ben tornati, parliamo oggi di qualcosa al di fuori dei miei soliti argomenti, vi racconterò della vita del programmatore.
Siamo onesti quando qualcuno pensa al programmatore ha un'idea confusa, distorta, sbagliata di questo lavoro.
Partiamo quindi dalla definizione della solita enciclopedia:
Il programmatore (noto anche con le espressioni inglesi developer, ovvero sviluppatore, e coder, traducibile come "creatore di codice"), in informatica, è un lavoratore professionista che, attraverso la relativa fase di programmazione, traduce o codifica l'algoritmo risolutivo di un problema dato nel codice sorgente del software da far eseguire ad un elaboratore, utilizzando un certo linguaggio di programmazione. La professione del programmatore è relativamente recente e si è sviluppata di pari passo con l'aumento dei campi di applicazione dell'informatica.
Se dobbiamo essere sinceri le tipiche immagini del programmatore sono sostanzialmente due:
1) Quella distorta data dai film, telefilm, fumetti, libri ecc. dove personaggi tipo lui,
che avranno riconosciuto in 4 se tutto va bene, a colpi di codice creano meraviglie del calibro di
(e magari arriviamo a 6 che conoscono la citazione).
Questa categoria è principalmente affascinata da quanto ha visto e, siamo onesti, chi è diventato programmatore si è fatto abbindolare da questa visione distorta.
Vedere film dove la realtà virtuale,
mondi paralleli all'interno di un elaboratore,
o semplicemente essere in grado di entrare in archivi segretissimi in pochi minuti con rapidi colpi di tastiera ha fatto fare la bavetta a molti di noi.
Poi lo sdoganamento negli ultimi anni della figura del Nerd ha fomentato ulteriormente la convinzione che "basta poco, che ce vò".
Poi se pensiamo che gente del tipo
oppure
"si potrebbe pulire letteralmente il culo coi pezzi da 500", ti fai due conti che potrebbe essere estremamente redditizio.
2) La seconda visione della figura del programmatore è quella più concreta e terra terra, dove la frase tipica è e rimane: "tu che sei bravo coi computer....".
Ma poi sappiamo tutti come va a finire, nel 99,99% dei casi si riduce a semplicemente a:
A) Installa la stampante
B) Guarda cos'ha che è lento
C) Installa la WIFI
D) Metti l'antivirus
Nel corso del tempo, visto che i cellulari sono diventati dei mini computer, si è arrivati anche a:
E) Aggiorna il cellulare
F) Installa il programmino
G) Scarica questo, quello, quell'altro
Questa categoria a volte è anche la più infima, specialmente se chi chiede è stronzo e colpisce nell'orgoglio il programmatore.
In prima battuta, specialmente se è un amico, lo fai anche con piacere, e spesso finisce li. Ma invece ci sono altri elementi che quando gli dai un dito, si prendono tutta la mano, braccio compreso. Ti abbindolano, "ma tu sei bravo", "io non capisco nulla", "facciamo presto". L'ultima frase è la peggiore, se vi dicono "facciamo presto" scappate, credete all'idiota che scrive.
Anche qua comunque si possono notare due distinte sotto categorie:
Il "voglia di fare saltami addosso, che tanto ho trovato il pirla che lo fa per me". Definizione lunga ma decisamente completa. L'elemento citato ti chiede inizialmente una mano perchè non è capace di fare una cosa, si segna, o fa finta di segnarsi le cose per potersi arrangiare ma poi, categoricamente non ce la fa. E quindi rispieghi. Lui segna tutto, ha capito, ma la volta dopo si re-inizia da capo in un loop infinito dove le opzioni sono due:
A) Ti arrangi per conto tuo, non perdi neanche più tempo a spiegare e gli fai le cose.
B) Gli bestemmi dietro e gli dici di trovarsi un altro pirla.
La seconda categoria è addirittura anche peggio "tu che sai, potresti controllare...". Queste sono le persone che parton dal pratino e vanno fino in cielo.... scusate era un'altra cosa. Dicevo, sono quelli che partono dalla pulizia del PC perchè sono capre ignoranti che aprono mail dove non conosce il mittente o che promettono vincite miliardarie, al "tu che sei bravo col computer, perchè non guardi perchè fa rumore la ventola del condizionatore?" E così da tecnico PC diventi, elettricista, falegname, postino... "E' un etto e 20, che faccio, lascio?"
Sulla questa seconda sotto categoria avrei inoltre un altro appunto. Si fanno prendere talmente la mano che "visto che sei bravo" non solo metti a posto le loro rogne, ma anche del parentado, vicinato o del primo coglione che passa la strada.
Vabbè torniamo alla vita del programmatore. Come dicevamo all'inizio, molto spesso chi intraprende questa carriera, spesso è abbindolato dalla visione distorta del tutto. Gente quasi onnipotente che all'interno della realtà virtuale può tutto,
o personaggi tipo Nolan Ross
che possono entrare e hackerare qualsiasi cosa in brevissimo tempo, hanno dato l'imprinting a chi intrapreso questa carriera.
Se poi aggiungiamo il carico che la programmatrice donna è anche gnocca,
diciamo che il fascino della carriera aumenta notevolmente.
Ma poi si sa, e gli Articolo 31 lo avevano detto, "la vita non è un film" e purtroppo torni alla triste realtà.
Parlo per esperienza personale, non solo per sentito dire, quindi credetemi, programmatrici/informatiche donne fighe... carine... accettabili... sono merce rara, se non inesistente. Basti pensare ai tempi dell'università, facoltà di informatica sotto matematica, il meglio che trovavamo erano il cane, l'orso e la scimmia.
Ehi ehi!!! tu in ultima fila, smettila di sghignazzare... tanto sai che è vero.
Ma... a questo punto, qual'è la verità sul programmatore?
Una delle cose che sicuramente, anche nella versione più distorta vista nei film è sempre vera, è che il programmatore è nerd. Chi più, chi meno, trovatemi un programmatore che non citi film, telefilm, fumetti, videogiochi e quant'altro. Infatti la versione primordiale del nerd era un occhialuto sfigatello che era appassionato di tutto questo mondo spesso ignoto al resto dell'umanità. Per fortuna ci siamo evoluti.
Altra cosa è che il programmatore, se parla con un suo pari, discute in un linguaggio incomprensibile, anche ai suoi stessi colleghi. Fateci caso, spesso se iniziate a elaborare di un qualsiasi sviluppo da fare e sul come realizzarlo, specialmente se ci sono due o più programmatori nella seduta, si finirà a tecnicismi dove, volente o nolente si arriverà alla frase, "a beh! se vi siete capiti voi, siamo a posto" che, in soldoni, le terze persone non programmatori, non hanno capito una madonna.
Se proprio vogliamo essere sinceri, valutando la mia esperienza nel campo, io la figura del programmatore la associo a quella del manovale. Un manovale del 21 secolo. Niente di più, un banale manovale, quello insomma che volente o nolente, "i ze sempre cassi sui". Scusate il venetismo ai non veneti, ma penso si capisca. Il programmatore ha spesso la responsabilità di quello che fa e, specialmente di quello che non va.
Indovinate, dove stanno i programmatori??
Giusto, direte voi, si sa... "da un grande potere, derivano grandi responsabilità", e fin che è una sua responsabilità, ci mancherebbe. Peccato non sia sempre così e vi spiego perchè. Come dicevamo il programmatore è il manovale, quello che fa il lavoro... in soldoni, l'ultima ruota del carro. Spesso chi stà più in alto di lui, si occupa di fare le analisi di sviluppo. Peccato che troppe volte succedano i seguenti intoppi:
A) L'analista capisce (in parte) quello che il cliente vuole, ma non capisce una madonna di come si potrebbe realizzarlo, per cui promette. Il programmatore capisce quello che gli dice l'analista, ma non può realizzarlo come voluto. Quando dico non può è perchè non si può con gli strumenti a disposizione, non perchè non vuole. Il programmatore deve ingegnarsi e trovare il compromesso più veloce e la prende in culo perchè non realizza nei tempi stabiliti. Diciamo che, fortunatamente, non mi è successo troppo spesso.
B) L'analista si mette d'accordo col cliente, il quale però capisce fischi per fiaschi. Il programmatore realizza quello che è stato concordato ma ovviamente, al cliente non va bene. Si cagnano tra analista e cliente perchè ognuno a le sue ragioni. Il programmatore deve mettere a posto, spesso stravolgendo quanto fatto. Caso molto noto al sottoscritto.
C) L'analista si mette d'accordo col cliente e stende un'analisi. Il cliente l'accetta, il programmatore fa e spiega all'utilizzatore finale. Quest'ultimo prova e la risposta standard è "così non mi serve a un cazzo". Quindi pur essendo sviluppato ad arte, il cliente non si interfaccia con le persone che devono utilizzare realmente il programma e, di conseguenza, il programmatore ha fatto un lavoro a metà. Più lavoro e più vedo che il caso base.
D) Ultimo, ma non meno importante, il lavorare per il cazzo. Ancora una volta l'analista si mette d'accordo col cliente e stende un'analisi. Il cliente l'accetta, il programmatore fa e spiega all'utilizzatore finale. Questo la procedura, perchè non vuole adattarsi, non utilizzerà mai quanto fatto. Indirettamente qua il programmatore la prende più per una sconfitta morale, perchè non viene apprezzato quanto hai fatto. Sapete che vi dico? hanno pagato? Si!!! sbattetevene i coglioni.
Oltre al rapporto con l'analista, c'è anche il rapporto col collega programmatore. Questo si complica se il programmatore in questione è anche analista. Questo stende l'analisi, inizia a sviluppare ma, per cazzi burocratici si ferma e passa il testimone al collega. Quest'ultimo, oltre a bestemmiare per cercare di capire codice non suo, spesso, giustamente, chiede lumi a chi ha scritto l'analisi, che deve (???) sapere come svilupparla visto che se l'è scritta. E qui le opzioni sono due:
A) Ti viene spiegato per filo e per segno cosa aveva in mente, come realizzarlo, e magari si discute su idee alternative. Bestemmi sempre per capire il codice non tuo, ma alla fine arrivi alla soluzione. Però... fatemi pensare, quante volte è successo? MAI!!!, mai cazzo.
B) La seconda opzione è più credibile. Chi ha scritto il documento, ha scritto cagate. Bei paroloni su come dovrà essere realizzato ma, concretamente, non sapeva dove sbattere la testa. Quindi il pirla che prende in mano il progetto, bestemmia due volte, non solo per il codice, ma anche per capire quanta droga si era sparato quando aveva scritto quella cazzo di analisi. Se poi si azzarda a chiedere lumi... le risposte saranno "boh, non mi ricordo", "si può fare, ma adesso non ho tempo di spiegartelo"... in pratica.... arrangiati.
Altra cosa importante è che il programmatore, spesso, ha la visione dall'interno del programma. Per cui tante volte non conosce tutte le funzioni del progetto, come lavora il cliente, quali decisioni sono state prese da chi ha fatto istruzione. Per cui non sa, ma anche se chiede, la prenderà in culo comunque, fidatevi.
Ultimo ma non meno importante, sono i test. Una regola che TUTTI dovrebbero rispettare è chi sviluppa può provare la sua procedura, ma deve essere un altro a testarla. Questo perchè chi ha fatto la procedura segue l'iter corretto e tante volte non fa il "test scimmia" schiacciando cose a caso. Ovviamente nessuno ha mai tempo, quindi il programmatore prova per conto suo e la prende regolarmente in culo.
A questo punto potreste chiedervi quale sia la "formula magica" per poter vivere in pace come programmatore. Le regole, a mio modo di vedere dovrebbero essere semplici, peccato che spesso non vengano rispettate, ma vediamole insieme.
1) Per uno sviluppo ci deve essere una persona, chi fa istruzione, chi imposta il lavoro al cliente (visto che ha il quadro d'insieme) recupera le necessità. Successivamente si discute col programmatore e si valuta una soluzione fattibile. Fattibile si intente senza troppe rotture di coglioni o stravolgimenti assurdi del programma. Da li si stende un'analisi, che dovrebbe essere fatta dal programmatore che realizza il lavoro. Il collega che ha preso in carico l'analisi la legge, la capisce e valuta se quanto scritto è quanto richiesto. Successivamente la si discute col cliente, il quale DEVE capire cosa si va a fare. Se tutto a posto si passa allo sviluppo e alla consegna.
Errori tipici di questo punto: Chi prende in carico la richiesta fa di testa sua e mette giù cose a caso, perchè magari non ha il quadro d'insieme della realtà del cliente. A volte chi scrive l'analisi non ha capito un cazzo di quanto detto e scrive cose a caso. A volte analista e sviluppatore non si parlano. Troppo spesso il cliente dice di aver capito, ma in realtà non è così.
2) Lo sviluppatore dovrebbe avere ALMENO un altro programmatore che usa i suoi stessi strumenti, per confrontarsi. Anche per un semplice scambio di idee o per avere un punto di vista diverso sulla possibile realizzazione.
Errori tipici: o chi lavora non ha nessuno con cui confrontarsi, oppure fa troppo spesso di testa sua.
3) Chi sviluppa non deve testare. E' giusto che a testare sia il tecnico che installerà, chi conosce la realtà del cliente. Questo perchè chi sviluppa, come dicevamo prima, sa dove mettere le mani.
Errori tipici: Non c'è tempo per cui il programmatore deve arrangiarsi a testare.
4) Il programmatore non DEVE MAI, fare cinquanta progetti assieme. Deve farli uno alla volta.
Errore tipico: il lunedì fa questo, il martedì quello, il mercoledì l'altro e via così, in maniera ciclica finchè non li finisce tutti.
5) Ultima regola, non fate ricadere sempre la colpa al programmatore se questa non è sua.
Questo è tutto, direi quindi valutate bene se fare il programmatore....
Vi lascio con quello che dovrebbe diventare lo schema di base nella vita di un programmatore.
Nessun commento:
Posta un commento