fbpx
Close

7 Marzo 2020

Programmatore Junior, Programmatore Senior

Un programmatore viene classificato in base agli anni di esperienza.
Solitamente abbiamo che:

  • 0-3 anni di esperienza: Junior
  • 8+ anni di esperienza: Senior

Nel mezzo a questi due ci sta il cosiddetto Mid level.

C’è solo un problema legato a questa classificazione: il tempo non ha nulla a che vedere con la qualità del lavoro di un programmatore.

Quali esperienze hai fatto in questi anni?
Di fronte a quali problemi ti sei trovato?
Qual è stata la tua attitudine?
Quante cose nuove hai imparato?

Cosa rende un programmatore Senior tale?

Se il tempo non è una discriminante allora cosa lo è?
Come faccio a diventare un programmatore Senior?
Quando e come avviene il passaggio e smetto di essere uno Junior?

Queste sono le domande che ci balenano in testa ma avranno veramente una risposta?
E se il titolo di Junior/Senior fosse veramente assegnato in base al tempo?

Voglio fare un passo indietro e parlarvi della mia esperienza.

Quando ero Junior

Ricordo ancora il bellissimo periodo della mia “infanzia” da programmatore: scrivere codice per me era la cosa più importante e caspita quanto ero bravo!

Ogni momento della giornata pensavo al codice, guardavo tutorial su vari linguaggi/framework, leggevo libri su come scrivere del bel codice (Clean Code e Clean Architecture vi dicono nulla?) e… programmavo.

Questa era la mia giornata tipica e mi sentivo veramente una rock star del codice.

Poi arrivò la realtà.

L’inesorabile realtà: il primo confronto con i clienti

Come ogni programmatore che ama il suo lavoro volevo mettere in mostra le mie qualità e trovare un ambiente che mi spronasse/aiutasse ad accrescerle: per questo decisi di unirmi ad un’azienda.

Le cose andavano lisce, a scrivere codice ero davvero bravo ma nel lavoro non era sufficiente: l’azienda mi affidò il mio primo cliente!

Il mio compito era quello di parlare con il cliente, capire le sue esigenze e le sue idee e trasformarle in realtà.

Ebbi questo incontro e nel giro di 10 minuti avevo già capito tutto: “Cosa ci sarà mai di difficile nel fare un sito di qualche pagina?!” pensai.

In seguito alla chiacchierata iniziai a scrivere codice, non mi fermavo mai se non per bere un caffè che mi avrebbe donato ancora più velocità e lucidità… ed eccolo là, il sito che il cliente desiderava era pronto, ed ero pure stato ampiamente nelle tempistiche accordate.

Fiero del mio lavoro scrissi al cliente per mostrargli il risultato ma la sua reazione non fu quella desiderata… Il cliente rifiutò il sito perché non rispecchiava le sue aspettative.

La reazione

Ero arrabbiato, frustrato, il cliente non capiva nulla, se il sito non rispecchiava le sue aspettative era perché non aveva le conoscenze tali per riconoscere che il mio lavoro era ottimo, il codice impeccabile, nulla di cui una persona sana di mente avrebbe potuto lamentarsi.

Ovviamente mi sbagliavo, il cliente non ha mai torto.

Il mio compito era quello di comprendere le esigenze del cliente nel dettaglio e di assicurarmi che le sue aspettative venissero rispettate, ma la presuzione di sapere tutto, di non poter sbagliare, mi ha annebbiato e sono stato superficiale.

Al tempo ero troppo immaturo per rendermene conto ma questo episodio mi ha permesso di comprendere le differenza tra un programmatore Junior ed uno Senior.

Le cose che un Senior ha più di uno Junior

Considerando un assioma che scrivere codice sia una parte fondamentale del lavoro del programmatore, qual è dunque la vera differenza tra l’essere Junior e l’essere Senior?

In primis, uno Junior non ha le conoscenze necessarie per rendersi conto della realtà: uno Junior crede di essere il migliore e di sapere tutto.
Il Senior invece ha le conoscenze necessarie per rendersi conto della realtà: un Senior è abbastanza maturo da sapere che ha ancora tanto da imparare.

Oltre a questa presa di consapevolezza, che sicuramente da una marcia in più ai Senior, i Senior hanno vari vantaggi. Di seguito elenco quelle che sono le skill chiave di un Senior:

– Un Senior è analitico: un vero Senior non inizia mai uno sviluppo senza prima aver analizzato quali saranno i linguaggi, i framework, le piattaforme e varie altre cose che saranno utili al completamente del progetto.

– Un Senior è critico: un Senior cerca sempre di prevedere i principali pain point che il progetto si porterà dietro. Un esempio eclatante sono i costi di sviluppo della soluzione che proporrà al cliente (non si parla sempre e solo di codice come puoi vedere).

– Un Senior si mette in discussione: mettersi in discussione è un’abilità fondamentale per vari motivi: ti permette non solo di crescere ma ti permette pure di trovare le soluzioni in maniera veloce.

Mettersi in discussione

Questa è una skill che mi sta molto a cuore perché mi ha permesso di crescere particolarmente nella mia professionalità (e anche nella mia professione): per questo motivo volevo portare un esempio che ne mostrasse l’importanza:

La situazione iniziale

Sei di fronte ad una situazione in cui il cliente lamenta che la comunicazione tramite API tra il tuo software ed un altro software non funziona.

Il non dubbioso

Ovviamente tu sei uno che non sbaglia mai dunque risponderai al cliente di contattare lo sviluppatore dell’altro software per trovare una soluzione.

Se sei fortunato il cliente ti contatterà dicendo che avevi ragione e tutto è finito per il meglio.

Se sei sfortunato il cliente ti ricontatterà dicendo che lo sviluppatore dell’altro software asserisce che il tuo software non funziona.

A questo punto partirà una guerra per decretare chi ha il software più robusto.

Durante questa guerra il malcontento del cliente aumenterà perché la soluzione tarderà finché entrambi gli sviluppatori non si metteranno l’anima in pace e faranno i dovuti controlli.

Ecco che arriva il giorno del giudizio: se verrà fuori che il problema era lato tuo software avrai non solo fatto una brutta figura ma avrai pure perso la fiducia del cliente (se non il cliente stesso).

HAI PERSO

Il dubbioso

Se tu invece fossi stato dubbioso di te stesso avresti fatto i controlli del caso sin da subito creando due situazioni molto positive:

La prima, il tuo software sta funzionando ed hai raccolto le prove a favore delle tue affermazioni. Lo sviluppatore e il cliente non possono ribattere e devono collaborare per risolvere: il cliente è felice.

La seconda, il tuo software non sta funzionando come ti aspettavi ma a questo punto puoi creare il fix necessario e comunicare al cliente che tutto è tornato a funzionare regolarmente: i danni sono stati contenuti, le tempistiche di risoluzione sono state ottime e il cliente è felice.

In entrambi i casi

HAI VINTO

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

×