Come si diventa senior software engineer?

Come ogni anno, questo è il periodo in cui a Sysdig si svolgono le performance review.
In Italia, per quanto ne so, non è una pratica molto frequente, quindi vale la pena spendere alcune righe prima di far sapere come è andata (non che sia un argomento così interessante, ma tant'è...).

Cosa è una performance review?

Sebbene il termine possa sembrare sconosciuto, sin da piccoli abbiamo dovuto convivere con delle performance review.
Si tratta di una valutazione periodica delle prestazioni, come quel temuto periodo in cui a scuola gli insegnanti cominciavano a decidere i voti che avrebbero scritto indelebilmente in pagella, il quale terminava con la consegna della stessa.
In modo simile, una volta l'anno, molte società americane dedicano un periodo di tempo nel valutare le prestazioni dei loro impiegati con una discussione formale sulla crescita e le prestazioni di ognuno.
Il fine di questa chiacchierata è quello di fornire un feedback coerente sui punti di forza di una persona e cercare di migliorare le aree più deboli. La discussione è aperta: il dipendente e il manager di grado superiore che deve dare un giudizio, dialogano apertamente scambiandosi delle opinioni sul lavoro svolto e sulla metodologia utilizzata approcciando ad esso, per poi giungere ad una conclusione condivisa. Ciò aiuta a migliorare la comunicazione all'interno del team che a sua volta porta a migliori prestazioni.

L'obiettivo di questo processo di valutazione è quello di migliorare il modo in cui un team o un'organizzazione funziona, per raggiungere livelli sempre più elevati di soddisfazione del cliente.
Un buon manager fornisce regolarmente dei feedback ai membri del team che gestisce, in questo modo, una persona non cade dalle nuvole se in fase di review vi sarà un risultato inaspettato.

Le compagnie che attuano questa politica di valutazione delle prestazioni, spesso fanno partire delle sessioni di formazione per i dipendenti che, sulla base dei feedback ricevuti durante la performance review, riconoscono di avere delle lacune in particolari aree di conoscenza.
Una regolare valutazione delle prestazioni può aiutare a determinare l'entità della crescita nella carriera di un dipendente e il livello di motivazione con cui contribuisce al successo di un'organizzazione.

I fattori discussi dirante il dialogo con il proprio responsabile possono includere temi quali condotta lavorativa, indicatori di prestazione, piani di lavoro, ruoli, responsabilità e descrizioni delle mansioni ricoperte da una determinata posizione.

La mia pagella

Puntualizzando il fatto che in questa occasione non c'era Alessandro Borghese che con il suo parere può confermare o ribaltare la decisione finale, per la mia review io ed il boss (un grande manager, non cito il nome perchè se poi si cerca su Google non voglio gli appaia questo articolo 😂 ) abbiamo allegramente toccato tre macro aree: personale, tecnica e manageriale.

1. Personally aww

Per quanto riguarda il lato personale, poco da dire: pare che le persone stiano bene nel lavorare assieme a me.
Sapere questo mi fa molto piacere anche se credo di non avere particolari meriti in tutto ciò, cerco di rompere le scatole il meno possibile e provo a trattare gli altri come vorrei esserlo io. Debbo dire che, fortunatamente, nella compagnia in cui lavoro questo scambio funziona molto bene.

2. Technically speaking

Pare che il mio lavoro sia apprezzato anche in ottica tecnica, altrimenti non si spiega perchè mi sopportano da 5 anni oramai 😅.
Questo è il punto che mi rende più felice dato che durante l'ultimo anno abbiamo stravolto il mondo che ci circondava, abbiamo cambiato tutto lo stack tecnologico in uso e la squadra ha dovuto affrontare concetti nuovi, apprendere tecnologie mai viste prima e misurarsi con sfide non semplici a livello ingegneristico.
Ritengo il feedback positivo ottenuto in questo ambito, un naturale riflesso del lavoro complessivo straordinario che è stato fatto dall'intero frontend team.

3. "Managing for dummies"

Dalla copertina del libro si intuisce come il punto principale in cui posso (e voglio) migliorare è quello di potenziare le mie capacità manageriali nel gestire i potenziali task entranti.
Nello specifico, sono quel tipo di persona che quando arriva una richiesta, prova ad espletarla anche se vi è già una lista abbastanza piena di cose da fare. Quello che mi viene chiesto è di riconoscere quando è il momento di respingere una determinata richiesta, anche proveniente da un altro team, invece di volerla completare ad ogni costo.
Comportamenti del genere finiscono per costringerti a lavorare ore extra per rispettare le scadenze imminenti, ma tutto ciò non è realmente necessario attuando una politica più oculata riguardo ciò che dovrebbe essere portato a termine piuttosto che task che non possono e non devono essere svolti. Spesso cerco di fare troppe cose per soddisfare tutti: sembra una buona cosa a prima vista, è controproducente nel lungo periodo.
Il feedback che ho avuto dal mio manager è che posso davvero fare un passo avanti in questa direzione nell'ottica di diventare un senior engineer. Si, nemmeno io ci credevo quando ho udito ciò: non faccio altro che accorgermi di non conoscere innumerevoli cose, il che mi porta spesso a pensare di essere meno di una figura junior 😅.

Sei un software developer o un software engineer? 😈

L'ultimo punto del paragrafo precedente mi ha portato così a meditare riguardo l'evoluzione che una persona può avere nelle dinamiche lavorative. Per capire cosa si può fare per diventare senior software engineer, bisogna prima capire la differenza tra un software developer ed un software engineer.

Rimanendo nell'ambito dello sviluppo di applicazioni web lato client, supponiamo che si debba creare una web app o un sito con un minimo di interattività.
La differenza principale tra i due ruoli sta nell'approccio allo sviluppo. Un tipico frontend developer potrebbe iniziare con un template o un layout predefinito e delle classiche impostazioni CSS come quelle presentate qui.
In questo caso, gli strumenti di lavoro principali saranno l'editor di testo per scrivere codice e i vari browser su cui testare il prodotto. Lo sviluppo frontend consisterebbe principalmente nel dividere un file PSD in sezioni, individuando gli elementi della pagina da riutilizzare per poi codificarli in un HTML funzionante e compatibile con i differenti browser esistenti (ho estremizzato un po' il concetto).
Nessun tipo di ottimizzazione sulla velocità di caricamento della pagina, nessun accorgimento sulla dimensione delle richieste HTTP e nessun problema di prestazione viene preso in considerazione.

Qualche anno fa, il boom dei dispositivi mobili ha portato a riconsiderare le condizioni in cui si può trovare un utente navigando in rete. Se prima egli era principalmente seduto davanti al suo PC con una connessione via cavo, adesso la maggior parte delle volte le persone navigano utilizzando connessioni 3G, 4G, Wifi, ecc...
Questo ha portato ad avere una maggiore sensibilità riguardo i dati che si devono scaricare quando si visita qualche pagina online, dunque si è iniziato a prendersi cura dell'ottimizzazione della velocità, della concatenazione degli script, della miniaturizzazione dei file, della compressione delle immagini...

Un moderno approccio ingegneristico nello sviluppo di applicazioni web lato client si differenzia dal processo tipico in diversi modi.
Con l'arrivo di Node e dei vari gestori di pacchetti quali NPM, Yarn e altri, un frontend software engineer deve ora occuparsi anche della CLI (Command Line Interface, interfaccia a riga di comando) per mettere in piedi un'infrastruttura che esegua in modo automatizzato i vari comandi ogni qual volta si debba effettuare una build del prodotto.

Il termine build fa riferimento al processo mediante il quale il codice sorgente viene convertito in un programma autonomo che può essere eseguito su un elaboratore. La build è costituita da più processi, i quali devono essere eseguiti tutti interamente, spesso seguendo un ordine ben preciso.
Uno dei passaggi più importanti è il processo di compilazione: i file del codice sorgente vengono convertiti in codice eseguibile.
Solitamente si effettua una nuova build quando è stato raggiunto un determinato punto di sviluppo ed il codice è ritenuto pronto secondo diversi criteri che variano da organizzazione a organizzazione.

Per fare un esempio reale al riguardo: i singoli processi che compongono una build, i quali sono lanciati ognuno in modo automatico, possono comprendere l'attività di compilazione del codice, da un qualisasi pre-processore CSS a codice CSS originale. La concatenazione di tutto il sorgente che compone lo stile, in un unico grande file ottimizzato. Tutto il JavaScript che rappresenta la codebase, in un solo file al fine di ridurre sostanzialmente le richiesta HTTP di tali risorse. Se si utilizza TypeScript, un altro processo sarebbe la transpilazione di tale codice in JavaScript, per far si che possa essere riconosciuto ed interpretato da tutti i browser in circolazione. Tali attività includono anche la miniaturizzazione dei file, la compressione degli stessi, il testing automatizzato, ecc...
Tutto questo, ha un'incidenza pesante sulle prestazioni finali del prodotto che stiamo creando.

E ora? 🤔

Abbiamo capito che il software developer è colui che scrive codice mentre il software engineer è colui che progetta soluzioni utilizzando codice e sistemi.
Ora si può provare a riflettere sulla seniority, me lo sono chiesto dopo la review che mi ha spinto a scrivere questo articolo.

Un senior engineer fa molto di più che scrivere codice e progettare sistemi.

Non è questione di hard skill: arrivati ad un certo livello tecnico, acquisite le dovute conoscenze, si produrrà più o meno sempre lo stesso codice, alla stessa velocità, in cui sono presenti dei bug.

Sono le soft skill che fanno la differenza.

Io credo si debba essere più indipendenti, senza il bisogno di essere gestiti da qualcun altro.

Come si diventa senior engineer?

I miei propositi per il prossimo futuro saranno quelli di entrare maggiormente all'intero del processo aziendale.

Ogni compagnia possiede un processo di sviluppo diverso, dunque è difficile scendere nei dettagli, sono le piccole cose, come sempre, che fanno la differenza.

Mi sono domandato cosa svolgo attualmente e cosa posso fare per alzare l'asticella.

Aspetto che qualcuno organizzi una riunione sulla nuova feature? Mi assicuro di essere in orario? Chiedo riguardo eventuali progressi di altri team che lavorano a qualocosa di cui necessito per il progetto? Cerco di individuare possibili ostacoli per risolverli?

Normalmente, provo a svolgere tutte queste cose, ma come si fa il salto di qualità?

Il manager mi suggerisce di fare più domande anzichè gettarmi a capofitto nel costruire subito qualcosa, dunque tenterò d'ora in avanti di adottare il seguente mantra:

1. Prendere in consegna il progetto.
2. Leggere le specifiche.
3. Fare domande.

Tantissime domande! Sin quando non mi sentirò sicuro di aver compreso le specifiche, ma, ancora più importante, ciò che ha mosso il product team a divulgare tali specifiche.

Questa fase è importante perchè l'obbiettivo finale è quello di essere proattivo qualora qualche spec sia stata pensata per risolvere un problema compreso in maniera diversa. Se questo dovesse accadere, dovrei cercare di suggerire dei miglioramenti o delle alternative che risolvano davvero il problema per cui erano state pensate, anche contattando esperti del team per farmi aiutare con le cose con cui sono meno familiare.
Probabilmente, nascondersi nel seminterrato cercando di capire tutto da solo non è "lavorare di squadra", anche se ciò significa lasciare che gli altri lavorino senza distrazioni.

Conclusione

Il mio amato manager, come dicevamo in precedenza, mi ricorda che non è giusto dire sempre:

Si, domani si farà.

Con determinate motivazioni, paradossalmente, è molto meglio un:

No, questo non sarà fatto, ed ecco perché...

Se il manager può contare su un nostro piccolo update quotidiano, non chiederà più alcun aggiornamento di stato. Quando questo viene richiesto è perchè non si ha idea di come procedano le cose.

Finito il task, l'obbiettivo è rompere le scatole affinchè la feature sviluppata venga testata, passi attraverso il Q&A team (quality assurance - controllo qualità) e il codice venga revisionato dai colleghi.

Per riassumente, quello che ho potuto capire da questa review, fondamentalmente è: si riesce a prendere cura di un progetto dall'inizio alla fine, senza l'input del manager?

Se la risposta è si, allora si è un senior engineer.

Tip: se lo si riesce a fare per un team intero che deve realizzare un progetto più ampio, si è un team lead!