Lead engineer di giorno, indie developer di notte

Ci sono due versioni di me che lavorano ogni giorno.

La prima è il Lead Software Engineer di Elemental Machines. Lavora su sistemi IoT, coordina decisioni tecniche in un team, ha revisioni di codice e meeting e priorità che cambiano. Pensa in termini di affidabilità, scalabilità, e impatto su un prodotto che non è suo.

La seconda è Daniele Molinari di Honeyside. Costruisce prodotti suoi, prende ogni decisione da solo, non ha review da nessuno, e risponde delle conseguenze direttamente. Pensa in termini di spedire, iterare, e sopravvivere.

Non sono la stessa persona. E non è sempre facile passare dall'una all'altra.

Cosa si impara in ciascuna direzione

Il lavoro a tempo pieno mi insegna cose che da solo non imparerei mai.

Lavorare in un team con engineer più senior di me — che esistono, nonostante il titolo — mi espone a modi di ragionare che non avrei sviluppato lavorando solo. Il modo in cui si gestisce la complessità a scala, come si decide quando refactorare e quando no, come si comunica un tradeoff tecnico a stakeholder non tecnici. Queste competenze non si acquisiscono costruendo prodotti da soli in un garage metaforico.

La dimensione del prodotto su cui lavoro a Elemental Machines — utenti reali, hardware fisico, SLA, ambienti che non posso spegnere a mio piacimento — mi dà un senso di responsabilità che è diverso da quello che sento con i miei prodotti. Non migliore o peggiore: diverso. Più formale, più distribuito, più dipendente dagli altri.

Il lavoro indie mi insegna cose che in un'azienda non imparerei mai.

Quando sei l'unico developer, non puoi delegare le decisioni difficili. Non puoi aspettare che qualcun altro risolva il problema di infrastruttura, o decida l'architettura, o capisce come funziona la fatturazione elettronica. Devi capire tutto abbastanza da poterlo fare, anche le parti che non ti interessano.

Questo crea una larghezza di competenze che il lavoro specializzato tende a non sviluppare. Non sono il miglior DevOps del mondo, ma so fare il deploy di un'applicazione e tenerla viva. Non sono il miglior designer, ma so costruire interfacce usabili. Non sono un commercialista, ma capisco il mio regime fiscale abbastanza da non dipendere completamente da altri.

Il costo del cambio di contesto

La parte che dall'esterno non si vede è il costo cognitivo di tenere entrambe le modalità attive.

Non è solo il tempo — sono le ore. Ma anche quando hai il tempo, ci vuole energia per passare da un contesto all'altro. Finire una sessione di lavoro intensa e aprire il laptop per lavorare su Barba Studio non è automatico. C'è una transizione — non sempre rapida — tra la modalità "Lead Engineer che sta risolvendo un problema di sistema" e la modalità "solo developer che deve decidere cosa spedire questa settimana".

Alcune sere la transizione non avviene. Chiudo il laptop, apro i progetti personali, e non riesco a entrare nel flusso. Non è pigrizia — è che ogni tipo di lavoro intenso consuma energia cognitiva, e forzare il cambio di contesto quando il serbatoio è basso produce risultati mediocri in entrambe le direzioni.

Ho imparato a non combatterlo. Le sere in cui non riesco a lavorare sui prodotti personali, non lavoro. Faccio altro. Il giorno dopo funziona meglio.

Le competenze che non trasferiscono

Non tutto quello che imparo in un contesto è utile nell'altro.

Le skills di coordinamento e comunicazione che uso come Lead — facilitare decisioni in gruppo, gestire priorità con stakeholder multipli, dare feedback costruttivo in code review — non servono quando lavoro da solo. Non c'è nessun team da coordinare, nessun stakeholder da persuadere.

Al contrario, la velocità e la disinvoltura con cui prendo decisioni da solo — senza consensus, senza validazione, spesso con informazioni incomplete — sarebbe sbagliata nel contesto aziendale. In un team, quella velocità si chiama unilateralità e crea problemi.

Il rischio è portare la modalità sbagliata nel contesto sbagliato. La velocità decisionale che funziona da solo diventa unilateralità in un team. La cautela collaborativa che serve in azienda diventa paralisi su un progetto personale. Riconoscere in quale contesto ti trovi — e adattare il modo di lavorare di conseguenza — è la competenza che tiene insieme le due cose.

Perché continuo a fare entrambe le cose

La risposta onesta è che nessuno dei due da solo mi basterebbe.

Il lavoro a tempo pieno dà stabilità economica, esposizione a problemi di scala che da solo non avrei, e una struttura sociale che il lavoro in solitudine non offre. Lavorare in un team ha un ritmo e un'energia che il lavoro indie non riesce a replicare.

I prodotti personali danno autonomia, la soddisfazione di possedere quello che costruisci, e la libertà di sbagliare a modo mio senza conseguenze per altri. È un tipo di lavoro che non smetterei di fare anche se non fosse necessario economicamente.

Sono due cose diverse che si nutrono a vicenda. Finché riesco a tenerle entrambe vive senza che l'una soffochi l'altra, ha senso continuare.