Pierwszy miesiąc w startupie zostawia trwały ślad. Nie ma powolnego wdrażania ani tygodnia oglądania filmów instruktażowych w oczekiwaniu, aż dział IT przygotuje laptopa. Już pierwszego dnia oczekuje się od Ciebie budowania, psucia i naprawiania rzeczy, z których realni ludzie będą faktycznie korzystać. Nauczyłem się tego szybko po dołączeniu do Treevah, firmy tworzącej narzędzia pomagające poszukującym pracy w organizowaniu ich aplikacji. Trzydzieści dni w środowisku wczesnej fazy rozwoju nauczyło mnie o tworzeniu oprogramowania więcej, niż mogłyby to zrobić jakiekolwiek zajęcia czy konkursy.
Rytm jest nieubłagany
W Treevah praca nie czeka, aż się zadomowisz. Zespół naciska, aby przenieść produkt z fazy alfa do bety, a ostatecznie na produkcję, co oznacza, że każde zadanie ma znaczenie. Nie ma miejsca na prace tymczasowe czy zadania, które lądują w skrzynce odbiorczej profesora. Gdy wdrażasz nową funkcję, trafia ona bezpośrednio do użytkowników, którzy próbują śledzić terminy, rozmowy kwalifikacyjne i follow-upy podczas poszukiwania kolejnego zajęcia.
Tempo jest wyczerpujące. Każdego dnia poruszasz się bardzo szybko, a obciążenie rośnie szybciej, niż się spodziewasz. Terminy nie są abstrakcyjne; są powiązane z kamieniami milowymi, które decydują o tym, czy firma będzie mogła obsłużyć więcej osób szukających pracy, czy naprawić braki w obecnym doświadczeniu użytkownika. Ten ciężar daje się odczuć. Tworzy on jednak jasność, którą trudno znaleźć w większych organizacjach. Gdy kończę zadanie, widzę bezpośrednią linię między tym, co zbudowałem, a osobą, która ma teraz łatwiejsze zarządzanie procesem poszukiwania pracy. To poczucie odpowiedzialności jest rzadkie i sprawia, że zmęczenie wydaje się tego warte.
Umiejętności rozwijają się szybciej na produkcji
Przed tym latem większość mojej energii poświęcałem na wystąpienia publiczne i hackathony. Oba te doświadczenia nauczyły mnie szybkiego myślenia i prezentowania pomysłów pod presją. Hackathony szczególnie trenują w błyskawicznym składaniu działających dem. Istnieje jednak różnica między projektem weekendowym, który imponuje sędziom, a kodem produkcyjnym, który musi przetrwać kontakt z setkami realnych użytkowników.
Spędzenie miesiąca skupionego na web developmencie w Treevah pozwoliło mi wypełnić tę lukę. W szkole projekty mają swoje bezpieczniki. Zakres jest ustalony, wymagania podawane na tacy, a jeśli Twój schemat bazy danych się sypie, możesz to wyjaśnić na slajdzie prezentacji. W startupie Twój schemat musi być solidny, ponieważ realni poszukujący pracy przechowują w nim realne dane o swoich aplikacjach. Pętla informacji zwrotnej jest natychmiastowa i bezlitosna. Gdy strona ładuje się wolno lub formularz nie chce zapisać danych, nikogo nie obchodzi Twoja ocena; obchodzi ich to, czy właśnie stracili szansę na pracę.
Ta presja wymusza rozwój. Uczysz się pisać czystszy kod nie dlatego, że wymaga tego kryterium oceniania, ale dlatego, że to Ty będziesz go debugować o północy. Uczysz się zadawać trafniejsze pytania podczas code review, ponieważ wdrożenie wadliwego buildu oznacza, że realni użytkownicy natrafią na ścianę. Możliwości w tym miejscu uderzają mocniej niż projekty szkolne. Błędy kosztują więcej, więc lekcje zostają w pamięci na dłużej.
Pokorna rzeczywistość błędów
Jeśli istnieje jeden mit, który chciałbym obalić, to przekonanie, że każdy błąd w oprogramowaniu jest dramatyczną awarią logiczną. Niektóre takie są, oczywiście. Ale wiele błędów, na jakie natknąłem się w Treevah, było irytująco małych. Ukrywały się na widoku i marnowały godziny mojego życia.
Ciągle pojawiały się dwa wzorce. Pierwszym były duplikujące się reguły CSS. Gdy wielu programistów pracuje nad tym samym komponentem przez kilka sprintów, arkusze stylów puchną. Jedna osoba dodaje klasę pomocniczą marginesu, podczas gdy inna wpisuje wartość na sztywno w pliku komponentu. Żadne z nich nie jest błędne w izolacji. Jednak razem tworzą przesunięcia układu lub wojny o specyficzność, przez co przycisk wygląda dobrze w Chrome, a jest zepsuty w Safari. Wykrycie tego wymaga otwarcia narzędzi deweloperskich przeglądarki i analizowania wyliczonych stylów linijka po linijce, zamiast czytania eleganckiej logiki algorytmicznej.
Drugim wzorcem było definiowanie elementów poza ich nadrzędnymi divami. Wyzwalacz okna modalnego lub lista rozwijana mogą zostać dołączone do niewłaściwego węzła w DOM. Ekran wygląda prawie poprawnie, więc zakładasz, że struktura jest dobra. Nagle pojawia się konflikt z-index lub zdarzenie kliknięcia propaguje się do niewłaściwego obsługującego i nagle użytkownik nie może zamknąć wyskakującego okienka, które zasłania jego formularz aplikacji. To nie są zagadki z zakresu informatyki teoretycznej. To błędy przestrzenne i strukturalne, które kumulują się, gdy działasz w szybkim tempie.
Niektóre z tych błędów wymagały tygodni, aby je znaleźć. Wpatrywałem się w kod, przekonywałem samego siebie, że logika jest bez zarzutu, i błądziłem po ślepych zaułkach, które prowadziły donikąd. Frustracja jest autentyczna. Masz wrażenie, że umyka ci coś oczywistego, i rzeczywiście tak jest. Ale satysfakcja z ostatecznego dostrzeżenia duplikującej się reguły lub niewłaściwie umieszczonego znacznika zamykającego jest zaskakująco