Se un anno fa mi avessi detto che non sarei stato iscritto al college, lavorando in una startup di tre persone nello spazio degli strumenti per sviluppatori front-end, avrei riso.

Gli ultimi 3 mesi hanno trasformato completamente la mia mentalità. Sono entrato in questo tirocinio titubante riguardo alle startup, sapendo solo com'è una carriera in una grande azienda. Sono uscito con un progetto chiaro su come avrei avviato la mia azienda, dall'ideazione e configurazione della base di codice all'implementazione e al go-to-market.

Il team Vivid ha fatto in modo che ciò accadesse. Riflettendoci, un paio di distinzioni fondamentali tra startup in fase iniziale e Big Tech hanno fatto la differenza.

• Attenzione. Alla Vivid, c'era un'enorme enfasi sul mio apprendimento. Sono stato incoraggiato a scegliere su cosa volevo lavorare, fare domande e parlare di tutto ciò che volevo imparare. Ho detto che ero interessato a come Jorge ha configurato il monorepo, e il giorno dopo abbiamo avuto una discussione di due ore sui dettagli di Vite, Turborepo, pnpm e altro. Per quanto questa sia una testimonianza del team Vivid, l'attenzione viene naturale in un team più piccolo. Il mio lavoro era direttamente legato al successo dell'azienda, quindi aiutarmi a dare il meglio di me era nell'interesse di tutti.
• Ampiezza dell'apprendimento. In un'azienda in fase iniziale, non esiste una base di codice consolidata da cui partire. Ero così abituato a dare per scontate cose come script di distribuzione e stringhe di connessione al database, ma all'improvviso mi sono ritrovato a dover essere io a configurare queste cose. Penso che nelle aziende più grandi esplori un argomento molto a fondo, ma in una startup sei costretto ad avere un piede nella porta per ogni parte del tuo prodotto.
• Qualità del codice. Sebbene le startup di solito abbiano una reputazione per la cattiva qualità del codice, questo non era certamente il caso di Vivid. Ho imparato così tanto sulle migliori pratiche di codice, avendo i miei PR rimandati indietro per le correzioni troppe volte per poterli contare. Sebbene all'epoca fosse doloroso, ora sono sicuramente un ingegnere migliore e capisco l'importanza di un'accurata revisione del codice.
• Divertimento! Ultimo ma certamente non meno importante, il tirocinio presso Vivid è stato il lavoro più divertente che abbia mai avuto. Aryaman, Jorge e Alberto hanno creato un ambiente così accomodante dalla prima settimana, e ora mi sento come se stessi lavorando a un progetto di hackathon con i miei grandi amici. In altri lavori, non vedevo l'ora di uscire dal lavoro alle 17:00, ma qui mi trovo felice di restare e lavorare fino a quando.

Mentre scrivo questo post, a poche ore dalla nostra seconda festa di lancio in assoluto sullo stesso tetto di WeWork, ho incontrato Aryaman, Jorge e Alberto, vorrei quasi che anch'io avessi un'offerta Big Tech da rinnegare e unirmi a Vivid. Invece, sto tornando alla Columbia per il mio ultimo anno di college, portando con me quattro nuovi amici e la voglia di costruire qualcosa con quello che ho imparato.

Entra Vivido

Ho incontrato Aryaman, Jorge e Alberto di persona per la prima volta quando hanno rinnegato le loro offerte di lavoro Big Tech a una festa WeWork sul tetto. Avendo avuto solo una breve chiacchierata con Aryaman la settimana prima, ho pensato che fosse così piacevole vedere l'entusiasmo che avevano tutti e tre per quello su cui stavano lavorando.

Ero appena uscito dal mio tirocinio in Microsoft e avevo fatto uno stage con Meta l'estate prima. Mi sentivo come se avessi una buona idea di come sarebbe stata la vita in Big Tech e, sebbene non lo odiassi, gran parte di me si chiedeva anche come sarebbe stato lavorare in una startup. Guardare il team Vivid gioire quando hanno rinunciato alle offerte da sogno del mio io da matricola è stato un campanello d'allarme: dovevo vedere cosa mi stavo perdendo.

Non è stata una sorpresa che un mese dopo stavo firmando una lettera di offerta per unirmi come primo stagista in assoluto di Vivid per la primavera del 2023.

Il Perno

Ho iniziato il mio primo giorno di lavoro in Vivid senza sapere cosa aspettarmi.

Il primo giorno, sono stato colpito dalla più grande sorpresa: Vivid non stava più costruendo lo Styler, il loro prodotto di punta che mi hanno mostrato su quel tetto solo un paio di mesi fa. Mi sono reso conto che stavo entrando a far parte dell'azienda in un momento incredibilmente unico: sperimentare in prima persona cosa significa costruire un'azienda da zero.

Sono stato immediatamente coinvolto in sessioni di brainstorming mentre il team ideava nuove direzioni per l'azienda. Mi sono rapidamente aggiornato sulle idee che venivano lanciate e ho assorbito i dettagli di ciò che rende un'idea migliore di un'altra.

Un paio di punti chiave delle nostre sessioni di brainstorming:

• È importante realizzare un prodotto di cui le persone hanno davvero bisogno . Non importa se il tuo strumento aumenta la produttività di ogni persona del team del 10%: nessuno è disposto a interrompere il proprio flusso di lavoro attuale per un piccolo miglioramento. Piuttosto, se ci sono due o tre ingegneri che sperimentano un aumento della produttività del 200%, il tuo strumento sarà molto più appiccicoso.
• I concorrenti non squalificano un'idea. Pensavo che se qualche altra azienda, non importa quanto piccola, avesse iniziato a lavorare su un'idea simile alla mia, non avrei dovuto portarla avanti. Ma ora vedo che queste aziende esistono come prova che c'è un vero problema che deve essere risolto.
• La visione a lungo termine è importante. Così è lasciare andare una cattiva idea. Sono rimasto sorpreso quando ho sentito che Vivid stava mettendo da parte lo Styler. Come utente, ho pensato che fosse un prodotto ben eseguito con un solido caso d'uso. Ora capisco che non c'era un obiettivo prevedibile a lungo termine con lo Styler e il pivot era essenziale per la crescita dell'azienda. Essere in grado di allontanarsi da un'idea senza un chiaro percorso in avanti, indipendentemente dall'errore dei costi irrecuperabili, è necessario affinché le startup si muovano rapidamente.

Di seguito un'immagine del mio primissimo contributo in codice al team Vivid!

Alla fine delle prime due settimane in Vivid, sono passato dal non sapere come scrivere una singola riga di React all'essere fiducioso di poter costruire una pagina da zero: più apprendimento di quanto avessi ottenuto in 12 settimane di tirocini precedenti.

Sincronizzazione vivida

La seconda parte del mio tirocinio è stata definita da Vivid Sync. Sapevamo già che c'era un notevole attrito nel trasferimento dagli sviluppatori ai designer. Ma durante una telefonata con un cliente, un responsabile tecnico ha condiviso un'intuizione chiave: questo attrito aveva un'unica causa principale. Nel corso del tempo, le librerie Figma iniziano a divergere dai repository di codice, il che causa consistenti problemi di comunicazione tra progettisti e sviluppatori.

Entro una settimana dalla prima idea, ci siamo assicurati un partner di progettazione e abbiamo iniziato a costruire il prodotto, che essenzialmente era un sistema di gestione delle attività che collegava i componenti Figma a una base di codice tramite Github Issues.

Mi è stato affidato il compito di creare l'interfaccia utente Web, che assomigliava a questa:

Ma ancora una volta, per quanto pensassi che l'idea e il prodotto fossero fantastici, solo una settimana dopo aver consegnato il prodotto al nostro partner di progettazione, siamo tornati nella sala riunioni ricominciando dal punto di partenza.

Brainstorming pt. 2

Vivid Sync aveva un difetto fatale: non risolveva il problema del cliente. L'utente finale è stato motivato dalla promessa di limitare il tempo di progettazione sprecato. A differenza dello Styler, Vivid Sync aveva una chiara visione a lungo termine, che era quella di creare una sincronizzazione end-to-end tra Figma e Code, ma il prodotto come consegnato non ha fatto risparmiare tempo agli ingegneri: in realtà ha aggiunto alla quantità totale di lavorare creando attività per lavori di manutenzione.

Il team era impegnato a costruire qualcosa il più velocemente possibile per il nostro partner di progettazione, ma in retrospettiva, ci sono stati chiari avvertimenti fin dall'inizio che il valore aggiunto immediato di Sync potrebbe non essere abbastanza alto.

Questa volta, ero preparato per quello che sarebbe successo. Mi sono prefissato l'obiettivo di partecipare attivamente alle discussioni sull'ideazione. Ho imparato a scrivere fogli di ipotesi, condurre ricerche competitive e gestire il flusso e il riflusso del pensiero divergente ristretto a un'idea specifica. Soprattutto, ho imparato quanto impatto può avere la mia opinione in un piccolo team.

Figma al codice

La cronologia dei commit di GitHub ha chiarito esattamente quanto tempo abbiamo impiegato a ideare: 3 settimane. Abbiamo deciso di tuffarci direttamente nella direzione del massimo valore per i clienti, convertendo i design Figma in codice frontend utilizzabile. C'era una chiara visione a lungo termine, stavamo affrontando direttamente il punto dolente dell'utente finale e avevamo tutti livelli di convinzione molto più alti.

Quando si è trattato di costruire, ho assunto la responsabilità dell'onboarding di nuovi utenti. L'obiettivo dell'onboarding era consentire a Vivid di generare codice utilizzando componenti già presenti nella base di codice dell'utente.

La sfida tecnica chiave era ottenere i componenti del codice dell'utente e collegarli alle risorse Figma corrispondenti, quindi ogni volta che veniva utilizzata la risorsa Figma, potevamo chiamare il componente corretto nel codice. Anche le proprietà dei componenti dovevano essere abbinate in modo che il nostro strumento potesse chiamare questi componenti senza errori.

La funzione di onboarding aveva un paio di pezzi diversi:

1. Applicazione Github . L'app Github si connette a un repository e restituisce tutti i file .tsx all'interno del repository connesso tramite un'API REST
2. Microservizio Python . Il microservizio Python, creato con Flask, utilizza un algoritmo di corrispondenza NLP per abbinare semanticamente i componenti del codice ai componenti Figma.
3. Pacchetto di attraversamento del codice . Il pacchetto di attraversamento del codice mi ha permesso di collegare insieme l'app Github e il microservizio Python. Ha ottenuto i file .tsx dall'app Github e ha restituito i componenti corrispondenti dal microservizio Python.
4. Piattaforma di onboarding Match. Infine, l'interfaccia utente ha consentito di creare corrispondenze e di inviarle a un database nel back-end.

Foto divertenti!