Gdybyś rok temu powiedział mi, że zostanę wypisany z college'u i będę pracował w trzyosobowym startupie w obszarze narzędzi dla programistów front-end, roześmiałbym się.

Ostatnie 3 miesiące całkowicie zmieniły moją mentalność. Przyszedłem na ten staż z wahaniem co do startupów, wiedząc tylko, jak wygląda kariera w dużej firmie. Wyszedłem z jasnym planem, w jaki sposób chciałbym założyć własną firmę, od pomysłu i konfiguracji bazy kodu po wdrożenie i wejście na rynek.

Zespół Vivid sprawił, że tak się stało. Po zastanowieniu okazało się, że kilka kluczowych różnic między start-upami na wczesnym etapie a Big Tech zrobiło różnicę.

• Uwaga. W firmie Vivid kładziono ogromny nacisk na moją naukę. Zachęcano mnie do wybrania tego, nad czym chcę pracować, zadawania pytań i mówienia o wszystkim, czego chcę się nauczyć. Wspomniałem, że jestem zainteresowany tym, jak Jorge skonfigurował monorepo, a następnego dnia odbyliśmy dwugodzinną dyskusję na temat tajników Vite, Turborepo, pnpm i innych. O ile jest to świadectwo zespołu Vivid, uwaga przychodzi naturalnie w mniejszym zespole. Moja praca była bezpośrednio związana z sukcesem firmy, więc pomaganie mi osiągać najlepsze wyniki leżało w najlepszym interesie wszystkich.
• Zakres nauki. W firmie na wczesnym etapie nie ma ustalonej bazy kodu, na której można by budować. Byłem tak przyzwyczajony do przyjmowania takich rzeczy jak skrypty wdrażania i ciągi połączeń z bazą danych za coś oczywistego, ale nagle okazało się, że to ja muszę konfigurować te rzeczy. Myślę, że w większych firmach bardzo głęboko zgłębiasz jeden temat, ale w startupie jesteś zmuszony postawić stopę w drzwiach dla każdego elementu swojego produktu.
• Jakość kodu. Chociaż startupy zwykle mają reputację złej jakości kodu, z pewnością tak nie było w przypadku Vivid. Nauczyłem się tak wiele o najlepszych praktykach związanych z kodem, że moje PR-y odsyłane były zbyt wiele razy, by je zliczyć. Chociaż wtedy było to bolesne, teraz z pewnością jestem lepszym inżynierem i rozumiem znaczenie dokładnego przeglądu kodu.
• Zabawa! Wreszcie, co nie mniej ważne, staż w firmie Vivid był najlepszą zabawą, jaką kiedykolwiek miałem w pracy. Aryaman, Jorge i Alberto stworzyli takie swobodne środowisko od pierwszego tygodnia, a teraz czuję się, jakbym po prostu pracował nad projektem hackathonu z moimi naprawdę wspaniałymi przyjaciółmi. W innych miejscach pracy miałbym ochotę wyjść z pracy o 17:00, ale tutaj cieszę się, że mogę zostać i pracować do kiedy tylko zechcesz.

Pisząc ten post zaledwie kilka godzin przed naszą drugą imprezą inauguracyjną na tym samym dachu WeWork, na którym spotkałem Aryamana, Jorge i Alberto, prawie żałuję, że ja również nie otrzymałem oferty Big Tech, z której mógłbym zrezygnować i dołączyć do Vivid. Zamiast tego wracam do Columbii na ostatni rok studiów, zabierając ze sobą czterech nowych przyjaciół i chęć zbudowania czegoś na podstawie tego, czego się nauczyłem.

Wprowadź Żywy

Po raz pierwszy spotkałem osobiście Aryamana, Jorge i Alberto, kiedy odrzucili swoje oferty pracy w Big Tech na imprezie WeWork na dachu. Tydzień wcześniej odbyłem tylko krótką pogawędkę przy kawie z Aryamanem, więc pomyślałem, że to bardzo odświeżające, gdy zobaczyłem podekscytowanie całej trójki związane z tym, nad czym pracują.

Byłem świeżo po stażu w Microsofcie, a poprzedniego lata odbyłem staż w Meta. Czułem, że mam dobre wyczucie tego, jak będzie wyglądało życie w Big Tech i chociaż nie nienawidziłem tego, duża część mnie zastanawiała się również, jak by to było pracować w startupie. Obserwowanie, jak zespół Vivid raduje się, gdy rezygnują z wymarzonych ofert mojego pierwszego roku, było dzwonkiem alarmowym — musiałem zobaczyć, co tracę.

Nie było niespodzianką, że miesiąc później podpisywałem list z ofertą dołączenia jako pierwszy stażysta Vivid na wiosnę 2023 roku.

Oś obrotu

Pierwszy dzień pracy w Vivid rozpocząłem nie wiedząc, czego się spodziewać.

Pierwszego dnia spotkała mnie największa niespodzianka: firma Vivid nie tworzyła już Stylera — swojego flagowego produktu, który zademonstrowali mi na tym dachu zaledwie kilka miesięcy temu. Zdałem sobie sprawę, że dołączam do firmy w niezwykle wyjątkowym momencie — doświadczając z pierwszej ręki, co to znaczy budować firmę od podstaw.

Natychmiast zostałem wrzucony do sesji burzy mózgów, podczas gdy zespół zastanawiał się nad nowymi kierunkami dla firmy. Szybko zapoznałem się z pojawiającymi się pomysłami i chłonąłem tajniki tego, co sprawia, że ​​jeden pomysł jest lepszy od drugiego.

Kilka kluczowych wniosków z naszych sesji burzy mózgów:

• Ważne jest, aby stworzyć produkt, którego ludzie naprawdę potrzebują . Nie ma znaczenia, czy Twoje narzędzie zwiększa produktywność każdej osoby w zespole o 10% — nikt nie chce zakłócać bieżącego przepływu pracy w celu drobnego usprawnienia. Przeciwnie, jeśli jest dwóch lub trzech inżynierów, którzy doświadczą wzrostu wydajności o 200%, twoje narzędzie będzie znacznie bardziej lepkie.
• Konkurenci nie dyskwalifikują pomysłu. Kiedyś myślałem, że gdyby jakakolwiek inna firma, nieważne jak mała, zaczęła pracować nad pomysłem podobnym do mojego, nie powinienem go realizować. Ale teraz widzę, że te firmy istnieją jako dowód na to, że istnieje prawdziwy problem, który należy rozwiązać.
• Ważna jest wizja długoterminowa. Tak samo jak porzucenie złego pomysłu. Byłem zaskoczony, gdy usłyszałem, że Vivid odrzuca Styler. Jako użytkownik myślałem, że to dobrze wykonany produkt z solidnym przypadkiem użycia. Teraz rozumiem, że w przypadku Stylera nie było żadnego przewidywalnego długoterminowego celu, a zmiana była niezbędna dla rozwoju firmy. Możliwość odejścia od pomysłu bez jasnej ścieżki rozwoju, niezależnie od błędu utopionego kosztu, jest niezbędna, aby startupy mogły szybko działać.

Poniżej znajduje się obraz mojego pierwszego wkładu w kod do zespołu Vivid!

Pod koniec pierwszych dwóch tygodni w Vivid przeszedłem od niewiedzy, jak napisać jedną linijkę Reacta, do pewności, że mogę zbudować stronę od podstaw — więcej się nauczyłem niż w ciągu 12 tygodni poprzednich staży.

Żywa synchronizacja

Drugi element mojego stażu został zdefiniowany przez Vivid Sync. Wiedzieliśmy już, że w przekazywaniu pracy między programistami a projektantami występują znaczne tarcia. Jednak podczas rozmowy telefonicznej z klientem lider ds. inżynierii podzielił się kluczowym spostrzeżeniem — to tarcie miało jedną podstawową przyczynę. Z biegiem czasu biblioteki Figma zaczynają odbiegać od repozytoriów kodu, co powoduje ciągłe nieporozumienia między projektantami i programistami.

W ciągu tygodnia od pierwszego pomysłu, pozyskaliśmy partnera projektowego i zaczęliśmy budować produkt, który zasadniczo był systemem zarządzania zadaniami łączącym komponenty Figmy z bazą kodów za pośrednictwem Github Issues.

Otrzymałem zadanie zbudowania internetowego interfejsu użytkownika, który wyglądał tak:

Ale znowu, choć uważałem, że pomysł i produkt były świetne, zaledwie tydzień po dostarczeniu produktu naszemu partnerowi projektowemu ponownie znaleźliśmy się w sali konferencyjnej, zaczynając od początku.

Burza mózgów cz. 2

Vivid Sync miał fatalną wadę — nie rozwiązał problemu klienta. Użytkownika końcowego motywowała obietnica ograniczenia zmarnowanego czasu inżynieryjnego. W przeciwieństwie do Stylera, Vivid Sync miał jasną, długoterminową wizję, która polegała na stworzeniu kompleksowej synchronizacji między Figma i Code, ale dostarczony produkt nie zaoszczędził czasu inżynierów — w rzeczywistości zwiększył całkowitą ilość pracy poprzez tworzenie zadań do prac konserwacyjnych.

Zespół był zajęty tworzeniem czegoś tak szybko, jak to możliwe dla naszego partnera projektowego, ale z perspektywy czasu od samego początku istniały wyraźne ostrzeżenia, że ​​natychmiastowa wartość dodana Sync może nie być wystarczająco wysoka.

Tym razem byłem przygotowany na to, co miało nadejść. Postawiłem sobie za cel aktywny udział w dyskusjach na temat idei. Nauczyłem się, jak pisać arkusze hipotez, przeprowadzać konkurencyjne badania i zarządzać przypływami i odpływami rozbieżnego myślenia, które jest zawężane do konkretnego pomysłu. Przede wszystkim nauczyłem się, jak duży wpływ może mieć moja opinia w małym zespole.

Figma do kodu

Moja historia zatwierdzeń na GitHubie wyjaśniła dokładnie, ile czasu spędziliśmy na tworzeniu pomysłów — 3 tygodnie. Postanowiliśmy zanurkować od razu w kierunku najwyższej wartości dla klientów — przekształcenia projektów Figma w użyteczny kod frontendowy. Istniała wyraźna długoterminowa wizja, bezpośrednio odnosiliśmy się do problemu użytkownika końcowego i wszyscy mieliśmy znacznie wyższy poziom przekonania.

Kiedy przyszło do budowania, przejąłem odpowiedzialność za wprowadzanie nowych użytkowników. Celem wdrożenia było umożliwienie Vivid generowania kodu przy użyciu komponentów znajdujących się już w bazie kodu użytkownika.

Kluczowym wyzwaniem technicznym było pobranie komponentów kodu użytkownika i powiązanie ich z odpowiadającymi im zasobami Figma, tak aby za każdym razem, gdy ten zasób Figma był używany, mogliśmy wywołać właściwy komponent w kodzie. Właściwości komponentów również musiały być dopasowane, aby nasze narzędzie mogło wywoływać te komponenty bez żadnych błędów.

Funkcja dołączania składała się z kilku różnych elementów:

1. Aplikacja Github . Aplikacja Github łączy się z repozytorium i zwraca wszystkie pliki .tsx w połączonym repozytorium za pośrednictwem interfejsu API REST
2. Mikroserwis Pythona . Mikrousługa Python — zbudowana za pomocą Flask — wykorzystuje algorytm dopasowywania NLP do semantycznego dopasowywania komponentów kodu do komponentów Figma.
3. Pakiet przechodzenia kodu . Pakiet code traversal pozwolił mi połączyć aplikację Github i Python Microservice. Pobrał pliki .tsx z aplikacji Github i zwrócił dopasowane komponenty z mikroserwisu Pythona.
4. Wprowadzająca platforma meczowa. Wreszcie interfejs użytkownika umożliwiał dopasowywanie i przesyłanie do bazy danych w zapleczu.

Zabawne zdjęcia!