L’ultima volta si è parlato molto su twitter dell’ingegnere 10x che ha dato il via a un grande dibattito su cosa rende un buon ingegnere. Sono state menzionate alcune cose davvero stupide come “gli ingegneri 10x odiano le riunioni” e “gli ingegneri 10x arrivano tardi in ufficio” e “lo sfondo del laptop degli ingegneri 10x è solitamente nero”. In generale, sembra che alcune persone pensino che se sei abbastanza intelligente, va bene essere uno stronzo.
In Wix cerchiamo di lasciare gli stronzi fuori dalla porta. Crediamo che gli ingegneri 10x non siano solo persone che possono produrre 10 volte più velocemente della maggior parte delle persone, ancora di più, sono persone che possono rendere un intero team 10 volte migliore avendo un’influenza positiva su chiunque lavori con loro.
Molte persone passano gran parte della loro carriera a diventare quello che noi pensiamo come un ingegnere decente. Significa che sei un buon codificatore, che può risolvere i problemi e fluente nell’uso degli strumenti che sono a tua disposizione come IDE, debugger, servizi e frameworks. Questo articolo cerca di descrivere ciò che noi, in Wix Engineering, crediamo faccia di un discreto ingegnere un ingegnere 10x.
Una delle capacità più importanti di un ingegnere è la capacità di lavorare in modo indipendente. In poche parole, questo significa sapere sempre cosa devi fare e raramente trovarti in una situazione in cui aspetti che qualcuno ti dica cosa fare. Non significa che siete in grado di fare tutto da soli, significa solo che sapete come sbloccarvi e come sbloccare gli altri nel vostro team in un modo pulito che crea un debito tecnico minimo. Per esempio, se venite bloccati da qualche problema, troverete una soluzione per esso, sia che si tratti di ottenere assistenza dai vostri pari o di risolverlo da soli. Gli ingegneri indipendenti hanno la capacità di portare un progetto dall’idea alla produzione attraverso tutte le sue fasi. Sono in grado di definire quali sono le cose di cui hanno bisogno per essere in grado di portare a termine un compito e sanno quando alzare una bandiera se hanno bisogno di assistenza.
Pianificazione
La cosa più difficile con cui si vedono gli ingegneri meno esperti lottare è essere in grado di prendere un grande compito e dividerlo in passi più piccoli. Questo è importante non solo per essere in grado di stimare quanto tempo ci vuole per qualcosa, ma è anche una parte critica della costruzione di software di alta qualità. Pianificare correttamente significa che lo sviluppatore può rilasciare la versione iniziale del prodotto il prima possibile e iniziare a ricevere feedback prima. Pianificare correttamente significa avere un design del sistema in anticipo e avere una buona immagine di ciò che si sta per fare prima di buttarsi in acqua. Pianificare correttamente significa che non ci sono grandi sorprese che rompono il tuo progetto mentre lo sviluppi. Un buon ingegnere dovrebbe essere in grado di scomporre un compito, definire il design e le fasi di rilascio, e fornire documenti di design e stime per mostrare il suo piano.
Humiltà
Questa è una cosa difficile. Anche gli ingegneri più forti molte volte hanno posto per crescere quando si tratta di umiltà. Significa non essere innamorati delle proprie soluzioni. Essere in grado di ascoltare e accettare le soluzioni degli altri. Dare per scontato il meglio dei propri colleghi e quando si vede qualcosa che sembra un errore, cercare di capire il ragionamento che c’è dietro. Aprire le cose alla discussione. Lasciare che le persone suggeriscano le proprie soluzioni. Condividete le vostre idee e non preoccupatevi di ottenerne il merito. È più importante che tutti si sentano a proprio agio con un’idea e sentano che è stato un lavoro di squadra piuttosto che tutti sappiano che è stata una tua idea. Siate onesti. Date credito alle persone. Non abbiate mai paura di dire che avevate torto o di riconoscere che qualcun altro ha ragione. La gente rispetta le persone che possono cambiare la loro opinione.
Riutilizzare
Può sembrare banale, ma la maggior parte delle persone non capisce che il modo migliore per fare progressi è costruire sopra il lavoro precedente. Gli ingegneri meno esperti hanno sempre la cattiva abitudine di pensare che il modo migliore per loro di muoversi velocemente sia ignorare tutto ciò che già esiste e ricominciare da capo. I buoni ingegneri cercheranno sempre a fondo, impareranno, chiederanno e capiranno tutte le soluzioni esistenti già disponibili. Anche se la soluzione esistente è carente, cercheranno di vedere come migliorarla prima di decidere di sostituirla. Non scarteranno mai una soluzione esistente senza averla studiata a fondo e senza aver parlato con il proprietario della soluzione esistente.
Mentalita’ delle infrastrutture
Come descritto sopra, riutilizzare il lavoro precedente puo’ avere un enorme impatto sulle persone. Questo significa che gli ingegneri dovrebbero essere sempre all’erta per vedere se hanno l’opportunità di creare qualcosa di riutilizzabile. La cosa più facile da fare quando si ha una tale opportunità è ignorarla. Rendere le cose riutilizzabili costa sempre di più al “creatore” che renderle non riutilizzabili, così molte persone con la vista corta ignorano i benefici che loro e altri team raccoglieranno lungo la strada. Un buon sviluppatore identificherà le opportunità di creare cose riutilizzabili, saprà come renderle riutilizzabili nel modo migliore e investirà gli sforzi per farlo.
Master your domain
L’unico modo per trovare buone soluzioni è comprendere a fondo il prodotto su cui si sta lavorando. I buoni ingegneri non solo hanno una profonda comprensione del prodotto che sviluppano. Capiscono anche tutti i casi d’uso, capiscono la motivazione del prodotto e possono facilmente avere una conversazione significativa con il product manager, sfidare le decisioni e offrire alternative. Sanno quali sono le caratteristiche importanti e quali sono le cose meno importanti e sanno come dare priorità in base ad esse e offrire soluzioni alternative quando necessario. Questo è importante non solo per il prodotto su cui si lavora, ma anche per qualsiasi prodotto con cui si integra.
Curiosità
I buoni sviluppatori devono avere una sana curiosità che si estende ben oltre i confini del loro dominio. Questo è particolarmente vero per imparare come funzionano effettivamente le tecnologie sottostanti, ma è altrettanto importante capire i prodotti su cui stanno lavorando altri team, la loro architettura e come si collegano come un sistema completo. Avere questo contesto più ampio può essere inestimabile quando si risolvono problemi complessi e una fonte di ispirazione.
Non ci sono confini
Vediamo spesso che la fonte di cattive soluzioni e cattive architetture è radicata nelle persone che hanno paura di cambiare le cose che sono fuori dai confini della loro scatola. Lo sviluppatore di client tenderà a risolvere le cose sul client, anche se è meglio risolverle sul server. Lo sviluppatore di applicazioni tenderà a risolvere il problema localmente anche se la soluzione appartiene alla piattaforma o all’infrastruttura. La ragione di questo è semplice. È più facile non creare discussioni con un team diverso, è più facile trattare il mondo al di là della tua portata come una scatola nera, è più facile trattare con il diavolo che conosci. Ma i buoni ingegneri devono sapere che sono parte di un unico grande sistema e che nessuna parte del sistema è davvero fuori dalla loro portata. Discutere il cambiamento dell’architettura con un’altra squadra è salutare e utile e potrebbe aumentare la vostra prospettiva. Offrirsi di contribuire al cambiamento richiesto è ottimo per costruire la fiducia tra i team. Toccare un nuovo dominio è un’esperienza da cui si può solo trarre beneficio. Soprattutto, quando i vostri confini diventano più flessibili, significa che il vostro impatto cresce. Ogni volta che eviti di raggiungere i tuoi confini, renditi conto che quello che stai facendo in realtà è trattenerti dall’avere un impatto maggiore.
Responsabilità / proprietà
Anche se non è immediatamente evidente, molto spesso se scavi alla radice del perché qualche progetto è stato ritardato o fallito, troverai che si riduce alla proprietà e alla responsabilità. Le persone tenderanno sempre ad incolpare l’ambiente circostante: “Ho dovuto aspettare un altro team per completare qualcosa”, “Ho avuto un problema di sistema e nessuno ha avuto il tempo di aiutarmi”, “Ho ricevuto le definizioni troppo tardi”. Un buon ingegnere sa che queste cose sono quasi sempre scuse. Quando sei il proprietario del compito e la responsabilità di farlo accadere è su di te, la tua mentalità dovrebbe essere che ogni problema che incontri è qualcosa che devi risolvere. Se sei bloccato da un’altra squadra, vai a parlare con loro. Offriti di fare coppia sul problema e non “gettare” la responsabilità su qualcun altro. Se non avete ancora ottenuto le definizioni, fate delle ipotesi su quali saranno le definizioni. È meglio fare dei progressi e poi fare degli aggiustamenti, piuttosto che sedersi e aspettare. Se qualcosa di grosso vi sta ritardando, sappiate quando alzare la bandiera e sapere come aggirare il problema in modo da poter almeno fare progressi su un altro fronte. Non essere mai in una situazione in cui qualcun altro è responsabile di risolvere il tuo problema, è il contrario – tu sei responsabile di arrivare al traguardo e devi affrontare gli ostacoli lungo la strada.
Comunicazione
Questa è una vera svolta e spesso la cosa più critica da avere per un ingegnere per essere in grado di avere un enorme impatto su tutta la squadra. Essere in grado di comunicare è la singola cosa più grande che ha permesso all’umanità di diventare quello che è, ovviamente la stessa cosa è altrettanto critica per qualsiasi aspetto della vita, compresa l’ingegneria del software. I buoni ingegneri devono essere in grado di spiegare eloquentemente le loro idee e opinioni. Devono essere in grado di discutere in modo intelligente e rispettoso con i loro pari. La comunicazione non è solo parlare, è ancora più importante saper ascoltare. Non tutti nel team saranno in grado di esprimere le loro idee allo stesso modo e un buon ingegnere deve essere paziente e fare le domande giuste per capire cosa stanno pensando gli altri e aiutarli ad essere ascoltati. Tutto questo è altrettanto importante sia per la comunicazione verbale che per quella scritta, e soprattutto non è solo conversare – la vita degli sviluppatori è piena di tonnellate di forme di comunicazione: documenti, presentazioni, documentazione, commenti al codice, messaggi di commit. Anche scrivere codice leggibile e scegliere buoni nomi di variabili è una forma di comunicazione.
Lavoro di squadra
Questo è uno dei posti dove anche gli ingegneri esperti falliscono molto spesso e non sanno nemmeno che sta succedendo. Pensate a tutte le volte che avete detto “è troppo complicato, lasciatelo a me”. Pensate a tutte le volte che avete detto “questo compito è un lavoro per una sola persona, aggiungere altre persone non lo renderà più facile”. Pensate a tutte le volte che non avete avuto il tempo di aiutare qualcun altro e non avete mai seguito, o avete aggiustato/rifatto il codice di qualcuno senza chiedere la sua revisione, o avete fatto un grosso cambiamento senza consultare il vostro team. Ci sono tonnellate di esempi. E il fatto è che anche per gli ingegneri esperti sembra al momento la cosa giusta da fare. Ma questo è un pensiero tattico che paga solo a breve termine. Se vogliamo realizzare grandi cose dobbiamo assicurarci di poter collaborare come una squadra. Non è un caso che il lavoro di squadra venga subito dopo la comunicazione. Queste sono le cose che ci rendono più efficaci, è biologia di base. I grandi ingegneri non solo collaborano, si consultano, imparano da, assistono, accoppiano e rispettano i loro pari, ma fanno anche da mentori, fanno notare i problemi, trovano interesse e imparano da tutto ciò che succede nel team e cercano proattivamente di essere d’aiuto anche per cose che non li riguardano direttamente. Gli ingegneri straordinari sanno quando e come proporre progetti che renderanno più facile per molte persone collaborare su cose in cui ci si aspetta molto lavoro.
Mantieni la semplicità
La complessità di una soluzione può essere uno dei killer silenziosi della capacità del team di andare avanti e adattarsi. È come la pressione alta. Per un occhio inesperto sembra che tutto vada bene e che tutto funzioni come previsto, ma in realtà, nel profondo, qualcosa che non influisce direttamente su nessuna funzionalità principale ti sta lentamente uccidendo. I buoni ingegneri creano soluzioni pragmatiche e codice leggibile, anche se si scrivono più righe di codice. Non mostrate quanto siete “intelligenti” usando tutte le capacità del linguaggio, creando livelli ridondanti di astrazione, o scrivendo una funzione in una riga che nessun altro può capire o fare il debug. Non essere un purista, non sovra-ingegnerizzare le soluzioni dove non è assolutamente necessario e non aver paura di prendere qualcosa che è già complesso e cercare di semplificarlo.
Prioritizzare
Non possiamo fare tutto. Non possiamo risolvere tutti i problemi. Non possiamo vincere tutti i dibattiti. Non possiamo rendere tutto perfetto. Abbiamo un tempo limitato e risorse limitate e dobbiamo usarle saggiamente. Questo significa che dobbiamo essere in grado di distinguere tra ciò che dobbiamo insistere a fare, ciò che possiamo rimandare e ciò che dovremmo ignorare. Gli sviluppatori prendono queste decisioni decine di volte ogni giorno. Quando consideriamo se indagare su un bug, quando consideriamo di fare qualche refactor, quando consideriamo di gestire qualche caso d’uso o caso limite, quando consideriamo di fare una deviazione dal nostro compito pianificato e anche quando investiamo tempo per convincere qualcuno della nostra opinione. I buoni ingegneri sanno essere implacabili nel correggere, investigare, ricercare o insistere per far valere il loro punto di vista per le cose che sono veramente importanti. Sanno prendere nota e tornare su qualcosa più tardi se è importante ma non urgente. E sanno lasciare qualcosa da parte o accettare l’opinione di qualcun altro anche se non ne sono soddisfatti quando non è davvero così importante.
Gestione del tempo
Come detto sopra, la triste verità della nostra esistenza è che siamo legati al tempo. I prodotti che sviluppiamo alla fine devono andare in produzione, abbiamo scadenze, stime e obiettivi da raggiungere. I buoni sviluppatori devono sviluppare non solo un’intuizione per stimare quanto tempo richiedono i loro compiti, ma devono anche essere intelligenti su come suddividere e ordinare i loro compiti in parti ancora più piccole. Hanno bisogno di gestire saggiamente le interruzioni e il cambio di contesto. Questa intuizione della stima del tempo è una parte inseparabile dell’essere in grado di dare priorità come descritto sopra. Per esempio, se qualcosa è abbastanza breve, potrebbe valere la pena farlo anche se non è super importante. E se è troppo lunga, potrebbe essere meglio rimandare un po’ o consultarsi con i propri pari o con il manager.
Conclusione
Come detto prima, crediamo che gli ingegneri esperti in tutto ciò possano rendere il team 10 volte migliore influenzando e ispirando i loro pari. I grandi ingegneri devono sempre ricordare che questo fa parte del loro lavoro quotidiano: influenzare e ispirare. Significa che dovete trovare il tempo non solo per fare il vostro lavoro, ma anche per aiutare gli altri a fare il loro lavoro. Questo si presenta in molte forme: fare da mentore alle persone del tuo team, creare risorse per educare le persone, assicurarsi che tutto sia ben documentato, essere sempre aperti a spiegare e fare coppia con le persone e molto molto di più. Essere un buon mentore ed educatore significa non solo aiutare i membri del tuo team a crescere, ma anche approfondire la tua comprensione di tutto ciò che fai e ti dà una nuova prospettiva sulla chiarezza delle cose, la complessità del sistema e i luoghi dove le cose possono migliorare.
Queste sono le caratteristiche degli ingegneri 10x, non solo nel loro impatto individuale, ma anche nel loro impatto su tutti gli altri. Chiedetevi sempre cosa potete fare per rendere il vostro impatto più grande, c’è sempre più spazio per crescere.
Si può fare di più.