3 commenti

Gestore di ingegneria

Era tempo che non provavo il terrore e l'ignoranza associate ad un nuovo lavoro. Dopo un decennio di carriera come sviluppatore, ormai mi sentivo a casa. Dettagli dell'implementazione a parte, avevo aperto tutte le sorprese e sapevo in quali cassetti trovare le posate. Ora che sono improvvisamente un engineering manager, è riapparso il terrore di fondo: cosa è importante? sto facendo le cose nel modo giusto? quali domande voglio fare a chi?

Il cambio è stato abbastanza rapido: forse tre settimane fra notare l'idea in un angolo della testa, guardarmi in giro ed investigare, colloquio e firma contratto. Spostarsi nella stessa ditta forse non conta, ma la tradizione/maledizione richiede un cambio di lavoro biennale (è già successo una, due, e tre volte) e questo cade a puntino.

Le mansioni di questa posizione variano nell'industria, ma per quanto mi riguarda sono responsabile di quattro-cinque sviluppatori, ed di una dozzina di progetti e sottosistemi. Mi addentro in un mondo assai diverso. Perché? Perché era li.

Dopo un anno di manager in arrivo ed in partenza sopra di me, ho già coperto parte del lavoro: prendere un progetto, farlo a pezzi, trovare le altre persone che vanno tirate dentro; capire il più possibile, ridurre rischi, e saltare nel progetto con sufficiente certezza—è importante che eventuali rabbit hole non si rivelino abissi; seguire il team ed aiutarli a costruire roba che funziona, non si rompe, e che di cui non si vergogneranno fra sei mesi. Ma se anche ho fatto parte del lavoro, ci sono ancora infiniti misteri: interagire con gli strati superiori della ditta, ma anche con gli sviluppatori con cui ho condiviso la trincea, e di cui all'improvviso sono responsabile. Ho cominciato tre libri diversi sull'argomento. Per fortuna il supporto interno è ottimo, ed include un corso in 22 parti, lungo un anno, che sembra coprire tutti i pezzi che mi mancano.

Il cambio di ruolo è orizzontale: non è una promozione, ma il passare ad una carriera diversa. E questa carriera non include scrivere codice. Mi aspetto difficoltà su questo lato, soprattutto lo staccarmi dalle decisioni strutturali, e da quelle cose che impari lavorando su grossi sistemi dove complessità ed entropia stanno vincendo su flessibilità e comprensibilità: lo spingere e tirare codice per tenerlo sui binari. Ora arriva il difficile momento di spiegarlo, non via dimostrazione pratica, ma... non son certo, via convincenti parole?

La prima settimana (corta) si chiude con un sospiro di sollievo. Ho passato ore a parlare con colleghi di cui ero a malapena a conoscenza, come se si fosse aperto un nuovo orizzonte. Meno sviluppatori, più manager e personaggi vari che magari arrivano con Cose Importanti™. Rispondere "non ora" adesso è il mio lavoro e, devo ammettere, una notevole soddisfazione.

Commenti

  • Chiara

    Tutti i cassetti pieni? I miei non lo sono mai, sigh... E quando penso di averne riempito uno di solito mi compare all'improvviso un'intera cassettiera nuova 🤦🏻

  • dreadnaut

    Occhio che il cassetto del JavaScript ha il fondo rotto, e la roba continua a cadere fuori. L'unica soluzione a lungo termine è usarne il meno possibile, e di certo non come fondamenta di un front-end. Chi suggerisce altrimenti garantisce anni di dolore e tovaglie strappate da sotto ai piatti.

  • Chiara

    Ne sono già persuasa ma come convincere il resto del mondo? Mi sono trovata persino davanti ad un Django con un frontend che non usava Django ma JavaScript...