Il tuo primo mese in una startup lascia il segno. Non c'è un lento inserimento, né una settimana passata a guardare video di orientamento in attesa che l'IT ti fornisca un laptop. Dal primo giorno, ci si aspetta che tu costruisca, rompa e ripari cose che le persone reali useranno davvero. L'ho imparato rapidamente dopo essermi unito a Treevah, un'azienda che sviluppa strumenti per aiutare i cercatori di lavoro a organizzare le proprie candidature. Trenta giorni in un ambiente in fase iniziale mi hanno insegnato più sullo sviluppo software di quanto qualsiasi aula o competizione avrebbe mai potuto fare.
Il ritmo è implacabile
In Treevah, il lavoro non aspetta che tu ti sia ambientato. Il team sta spingendo per far passare il prodotto dalla fase alpha alla beta e infine alla produzione, il che significa che ogni task ha un peso. Non c'è spazio per lavori provvisori o compiti che finiscono dimenticati nella casella email di un professore. Quando rilasci una funzionalità, questa va direttamente agli utenti che stanno cercando di monitorare scadenze, colloqui e follow-up mentre cercano la loro prossima occupazione.
Il ritmo è estenuante. Ti muovi velocemente ogni singolo giorno e il carico di lavoro si accumula più velocemente di quanto ti aspetti. Le scadenze non sono astratte; sono legate a traguardi che determinano se l'azienda può servire più cercatori di lavoro o correggere le lacune nell'esperienza attuale. Quella pesantezza ti logora. Ma crea anche una chiarezza difficile da trovare nelle grandi organizzazioni. Quando finisco un compito, posso tracciare una linea retta tra ciò che ho costruito e una persona che ora ha più facilità a gestire la propria ricerca di lavoro. Quel senso di responsabilità è raro e rende la fatica degna di essere vissuta.
Le competenze crescono più velocemente in produzione
Prima di questa estate, gran parte della mia energia era dedicata al public speaking e agli hackathon. Entrambi mi hanno insegnato a ragionare rapidamente e a presentare idee sotto pressione. Gli hackathon, in particolare, ti addestrano a mettere insieme demo funzionanti in poche ore. Ma c'è una differenza tra un progetto di un fine settimana che impressiona i giudici e il codice di produzione che deve sopravvivere al contatto con centinaia di utenti reali.
Trascorrere un mese concentrato sullo sviluppo web in Treevah ha colmato quel divario. A scuola, i progetti hanno dei binari. L'ambito è definito, i requisiti vengono serviti su un piatto d'argento e, se lo schema del database crolla, puoi giustificarti con una slide di una presentazione. In una startup, il tuo schema deve reggere perché i veri cercatori di lavoro vi stanno salvando dati reali sulle candidature. Il ciclo di feedback è immediato e spietato. Quando una pagina carica lentamente o un modulo non riesce a salvare, a nessuno importa del tuo voto; importa se hanno appena perso un'opportunità.
Quella pressione spinge alla crescita. Impari a scrivere codice più pulito non perché lo richieda una rubrica di valutazione, ma perché sarai tu a dover fare il debugging a mezzanotte. Impari a porre domande più acute durante la code review perché distribuire una build interrotta significa che gli utenti reali si scontreranno con un muro. Le opportunità qui colpiscono semplicemente con più forza rispetto ai progetti scolastici. Gli errori costano di più, e quindi le lezioni rimangono impresse.
L'umiliante realtà dei bug
Se c'è un mito che vorrei distruggere, è l'idea che ogni bug software sia un drammatico fallimento logico. Alcuni lo sono, certamente. Ma molti dei bug che ho incontrato in Treevah erano irritantemente piccoli. Si nascondevano in piena vista e mi hanno fatto perdere ore di vita.
Due schemi continuavano a presentarsi. Il primo erano le regole CSS duplicate. Quando più sviluppatori toccano lo stesso componente durante diversi sprint, i fogli di stile si gonfiano. Una persona aggiunge una classe utility per il margine, mentre un'altra inserisce un valore fisso nel file del componente. Nessuna delle due soluzioni è sbagliata isolatamente. Ma insieme creano spostamenti di layout o guerre di specificità che fanno apparire un pulsante corretto su Chrome e rotto su Safari. Individuarli significa aprire i dev tools del browser e scorrere le proprietà calcolate riga per riga, invece di leggere un'elegante logica algoritmica.
Il secondo consisteva nel definire elementi al di fuori dei loro div genitori. Un trigger di una modale o un menu a discesa potrebbero essere aggiunti al nodo sbagliato nel DOM. Lo schermo sembra quasi corretto, quindi assumi che la struttura sia solida. Poi appare un conflitto di z-index, o un evento di click risale verso il gestore sbagliato, e improvvisamente un utente non riesce a chiudere un popup che copre il suo modulo di candidatura. Questi non sono enigmi di informatica. Sono errori spaziali e strutturali che si accumulano quando ci si muove velocemente.
Alcuni di questi bug hanno richiesto settimane per essere individuati. Fissavo il codice, mi convincevo che la logica fosse corretta e mi addentravo in vicoli ciechi che non portavano da nessuna parte. La frustrazione è reale. Ti senti come se ti sfuggisse qualcosa di ovvio, e in effetti è così. Ma la soddisfazione di individuare finalmente una regola duplicata o un tag di chiusura fuori posto è sorprendentemente