Junior VS Senior: come il confronto aiuta entrambi a crescere

In ogni azienda, soprattutto se piccola, si affronta prima o poi la questione sull’assunzione di figure Junior. In un mercato come quello IT, in cui la domanda di Software Developers è decisamente più ampia dell’offerta disponibile, assumere persone da formare e far crescere internamente potrebbe essere la scommessa vincente.

Cosa ci spaventa allora?

Sicuramente i Senior hanno una conoscenza ed esperienza maggiore, che ci fanno sentire sicuri sulla qualità del lavoro prodotto, ma nessuno nasce già con queste competenze. Nessuno nasce Senior.

Bisognerebbe quindi focalizzarsi maggiormente sui vantaggi che assumere persone Junior porta in azienda… e noi in Ibuildings lo sappiamo bene: da sempre collaboriamo con le università per inserire figure Junior da crescere nei nostri team.

Gli sviluppatori Junior possono avere meno esperienza o skills tecniche, ma è proprio questa loro caratteristica di “tela bianca” che li rende contagiosamente motivati e super entusiasti di apprendere nuove cose.

Apprendono molto e velocemente, buttandosi a capofitto sui task a loro assegnati e in questo percorso di crescita influiscono positivamente sul mood di tutto il team.

Mentre i Senior sono un po’ più affezionati a certe tecnologie - a volte addirittura innamorati, disposti ad immolarsi in vere e proprie guerre di religione per difendere la propria presa di posizione - le figure più Junior hanno una mentalità più flessibile. Molto spesso hanno avuto modo e tempo di “giocare” con nuove librerie e componenti di cui possono poi riportare i pro e i contro, stimolando la discussione e il confronto.

La crescita riguarda però anche i Senior, che si troveranno ad essere non solo dei leader, ma anche dei mentori, in un rapporto di reciproca condivisione di conoscenze.

Come spesso abbiamo già sottolineato, la chiave per un’effettiva collaborazione in ogni team è sempre la comunicazione. Nel caso del mentoring, dovrà essere costruttiva, che invita a riflettere insieme su come affrontare le problematiche.

Il mentore dovrà essere bravo ad ascoltare e capire quelli che sono i punti di difficoltà del programmatore Junior, che lato suo dovrà invece porre parecchie domande, senza timore di infastidire o disturbare. La pazienza è una qualità che entrambi acquisirete a livello Dalai Lama.

Parlando di pazienza, il nostro Alessio, Team leader in Ibuildings, ha dei consigli su come rendere più efficace e costruttiva la collaborazione tra Senior e Junior.

Non dobbiamo pensare al mentoring unicamente come una lezione frontale dove il senior fa da insegnante e il Junior da studente, ma piuttosto deve essere vissuto come uno scambio alla pari, una sorta di mindset condiviso sull’ambiente di lavoro.

Un Senior developer, in aggiunta ad una “Seniority tecnica” (strettamente dipendente dall’argomento) possiede una “Seniority non tecnica” più legata alle soft skills, al problem solving e al modus operandi acquisiti con l’esperienza. Queste conoscenze non tecniche, spesso silenti o inconsce nei senior, sono in realtà un ingrediente fondamentale per il mentoring, in quanto, a differenza di quelle puramente tecniche, sono trasversali e accompagnano il junior nel suo percorso, rendendolo indipendente nella ricerca di soluzioni, nello studio autonomo e nel porsi le domande corrette, facilitandogli a sua volta il suo futuro da senior.

Dunque, ecco alcuni consigli per il mentore:

1. Non mettere troppa carne al fuoco

Ogni persona ha dei tempi di assimilazione differenti e nel nostro campo l’unico modo per rendere i concetti propri e compresi fino in fondo è implementarli.

Spiega un argomento per volta e lascia che i successivi argomenti di discussione vengano sollevati dai nuovi problemi riscontrati nell’attuazione dell’ultimo. Pretendere di esporre più argomenti con le diverse sfaccettature di dettaglio in un’unica sessione, risulta il più delle volte un approccio fallimentare, in quanto la figura Junior sarà in grado di seguire ad alto livello il discorso, ma giunti ai dettagli, che verranno esposti per ultimi, avrà delle lacune sulle basi dell’argomento stesso.

Lo so, non è facile. Spesso per effettuare un task serve avere una conoscenza orizzontale o comunque cross-argomento. Come ci comportiamo in questi casi?

Una linea che personalmente Alessio adotta è la seguente:

Questo schema, puramente concettuale, serve ad indicare che il rapporto tra il numero di argomenti trattati deve essere inversamente proporzionale al livello di dettaglio dei singoli argomenti.

Ciò significa che, nel caso nasca la necessità di esporre uno scenario cross-argomento di cui è necessario spiegarne almeno 1 nel dettaglio e di quest'ultimo entrare nello specifico di una sua peculiarità. Dal grafico posso subito immaginare che mi servano almeno tre sessioni intervallate da pratica, per far sì che siano realmente costruttive.

La prima sarà quindi una sessione orizzontale che introduce tutti i vari argomenti dello scenario fino a presentare per ciascuno il dettaglio minimo per la comprensione del flusso.

La seconda sarà focalizzata sul singolo argomento, arrivando a comprenderne tutti gli aspetti ad un livello medio.

Infine, la terza si terrà unicamente su un sotto argomento per cui, come evidenziato anche nel grafico, sarà possibile spingersi al un livello di dettaglio maggiore.

2. Comunicazione efficace

Una buona comunicazione efficace avviene solo se immersa in un ambiente ricco di energie positive e privo di pregiudizi, dove chiunque si possa sentire libero di fare domande o partecipare a discussioni, senza il timore di essere giudicato.

Dato per assodata questa premessa, Alessio ha quattro principali consigli:

• Sii costruttivo, piuttosto che dire “Si fa così” o “Perché hai fatto così?”, prova “Ho visto che hai fatto così, hai considerato quest’altro approccio?”, “Se avessimo questa eccezione come agiresti per prevederla?”.
• Adatta il tuo livello comunicativo all’esperienza del tuo interlocutore. Individua il suo livello di preparazione e adatta la tua esposizione secondo i suoi feedback. Cerca delle esperienze comuni sulle quali fare esempi, introduci metafore e disegna schemi durante le tue spiegazioni. Solo così la sessione sarà produttiva per entrambi e il Junior avrà dei riferimenti chiari per sostenere la prossima sessione.
• Fai molta introspezione. Da Junior, in alcune situazioni particolari, che ora probabilmente ti sembrano banali, avrai sicuramente provato stati d’animo ed emozioni contrastanti, spesso non positive o in alcuni casi paralizzanti: cerca di prevedere queste condizioni di stress in modo da provare ad arginarle e a non renderle un ostacolo alla vostra comunicazione.
• Fatti conoscere. Condividete idee, esperienze sia positive sia negative, ragionate ad alta voce, cercate risposte e scrivete codice insieme conversando sul problema. Comunicare con chi non si conosce porta ad una comunicazione formale, spesso povera e unilaterale, esattamente tutto il contrario di ciò che vogliamo.

3. Assegnazione dei task

Assegna sempre task misurati alla esperienza degli Junior, magari con in più qualcosa di nuovo. Spazia tra le diverse attività cambiando anche ambito di competenza (backend, frontend, UI, … ).

Inizialmente sarà difficile capire cosa la figura sarà in grado di portare a termine in autonomia, ma se mai si inizia mai lo si scopre e lui stesso non sarà in grado di auto valutarsi costruttivamente.

Con il tempo imparerai a conoscerlo sotto l’aspetto tecnico ed emergeranno da parte sua preferenze ed inclinazioni che renderanno ad entrambi il compito più semplice.

Nello Junior, insicurezza e bassa autostima generate dalla frustrazione sono un forte indicatore che i task assegnati sono al di sopra della sua portata: un buon mentore deve riuscire ad abbattere il carico ma allo stesso tempo colmare il gap artefice della frustrazione con una o più sessioni di mentoring per renderlo autonomo verso il compito.

Diventa invece essenziale riconoscere se questa insicurezza e bassa autostima siano causate da componenti emotive, come la paura di affrontare qualcosa di ignoto (cambio di competenza, linguaggio…) o dal fatto che gli si è davvero assegnato qualcosa al di sopra delle sue potenzialità: se il fattore è puramente emotivo, non legato a problemi tecnici, il mentore ha il compito di non lasciarsi influenzare e di guidare il junior verso la attività gradualmente, senza travolgerlo.

Sii paziente, credi in loro, sfida sempre le loro capacità e correggi il tiro in base ai loro feedback.

E ora, alcuni consigli per le figure Junior:

1. Comunicazione Smart

Fare domande è essenziale, è parte fondamentale del nostro lavoro, per cui, in ogni momento, non avere paura di alzare la mano e chiedere, sarà poi l’interlocutore a valutare velocemente quando e come potrà risponderti.

Oltre a sentirsi liberi di fare domande, è però fondamentale imparare a formularle nella maniera corretta e distinguerle in base al contenuto.

Dobbiamo pensare che spesso la persona a cui poniamo la domanda sta facendo tutt’altra attività ed è quindi concentrata su un altro problema.

Domande del tipo “Come si fa questo task?” implicitamente esigono una lunga ed elaborata risposta, per cui per molti risulterà naturale rimandare la formulazione della soluzione ad un momento più opportuno.

Diventa a questo punto necessario il concetto di Comunicazione Smart (più efficace se mediata da Chat). Continuando con l’esempio di “Come si fa questo task?”, l’approccio ideale è quello di analizzare il task secondo propri mezzi e capacità, identificando se l’attività è scomponibile in sotto-task, e in caso positivo scrivere una lista di ToDo, strutturando quest’ultima secondo il blackbox model (ogni ToDo è una scatola nera di cui conosco solo gli input e gli output ) e iniziare lo sviluppo una blackbox alla volta.

Ovviamente in base all’esperienza potreste trovare degli ostacoli, ma solo lo sforzo fatto per analizzare il task vi renderà abili a formulare delle domande Smart.

Esempi:

Il task risulta indivisibile, siete quindi già alla blackbox e avete provato a risolverlo, ma non riuscite a trovare una soluzione:

Questo task sembra non scomponibile, ho provato a fare “approccio 1” e “approccio 2”, senza risultato, hai un altro approccio da consigliarmi?

Avete diviso il task in A, B e C e non riuscite a risolvere B:

Ho provato a fare “approccio 1” e “approccio 2” per risolvere B senza risultato, dove sbaglio in questo passaggio?

Avete trovato più di una soluzione per un task ma non sapete capire quale di queste è più corretta:

Sto lavorando al task e ho pensato all’“approccio 1” e “approccio 2” pensavo di implementare il 2 per questo motivo …, è corretto?

Il concetto chiave è fondamentalmente uno: introdurre già nella domanda (dove possibile) una parte della risposta o un’idea di soluzione e rendere chiaro come e quanto si è già affrontato per risolvere l’attività. Questo vi renderà velocemente indipendenti, vi permetterà di avere risposte utili e repentine e consentirà al mentore di cogliere e monitorare il vostro percorso, così da rendere più efficaci e mirate le sessioni di mentoring.

2. Divide et impera

Come già si può intuire dalla Comunicazione Smart esposta sopra, l’approccio “Divide et impera” resta valido ad ogni livello. Questo è il pattern per eccellenza per avviarvi alla soluzione di ogni problema.

Non lasciatevi spaventare da un problema complesso, prendetelo, dividetelo in problemi più piccoli alla vostra portata e sconfiggeteli uno a uno.

Questo vale anche per la stesura del codice, non saltate i passaggi e non abbiate fretta di avere il codice fin da subito perfetto. Testate e assicuratevi un po’ per volta che quello che avete scritto sia corretto.

3. Prenditi una pausa

Ti senti bloccato? Non sai più come continuare? Ti sembra di averle provate tutte? Non hai la più pallida idea di cosa fare?

Prenditi una pausa!

Non ho detto arrenditi, ma libera la mente, alzati dalla sedia e pensa a tutt’altro per la durata del break. Quando tornerai al tuo problema lo vedrai da un altro punto di vista, aprirai nuove strade alla soluzione o se sei fortunato lo troverai funzionante perché stavi sbagliando a testarlo .

In caso la pausa non risultasse sufficiente per sbloccarti racconta il tuo problema ad alta voce a qualcuno, o se nessuno fosse disponibile ad ascoltarti, descrivilo a te stesso o ad un oggetto inanimato della tua scrivania: il Rubber duck debugging. Questo metodo nella sua semplicità risulta geniale: sforzandoti nell’esposizione del problema, ti obbliga infatti a razionalizzarlo e delinearlo in tutte le sue parti risultando il più delle volte sufficiente a sbloccarti.

4. Copia e incolla

Non è un segreto, tutti lo usiamo. Non bisogna dimenticarsi però che qualsiasi cosa incolliamo sui nostri progetti va comunque compresa fino in fondo. Incollare una soluzione solo perché risponde correttamente alla nostra ricerca Google, o perché l’avevamo già usata da un’altra parte non è di certo un approccio vincente.

Il mio consiglio è quello di mettervi sempre nella condizione di garantire il corretto funzionamento del vostro codice, e nel caso del copia-incolla (che invito a continuare a fare per evitare typos), l’unico modo è quello di comprenderne ogni singola riga e dove necessario modificarla secondo le vostre esigenze.

Sii paziente, sii comunicativo, credi in te stesso, conosci i tuoi limiti e impara a superarli!