3 najgorsze rady dla programistów startupów

Bądź w branży technologicznej wystarczająco długo, a zapewne uda Ci się usłyszeć jakąś spektakularnie tragiczną radę. Ale... inżynierowie to dalej ludzie. A ludzie są we wszystkich kształtach i rozmiarach. Wielu z nich nie wie, która droga poprowadzi ich jeszcze wyżej w karierze. A nie jest to wcale takie trudne, zwłaszcza w branży technologicznej. Psucie i bycie nieprzygotowanym, jest naturalną sprawą w tej branży, ale nie każdy z nas może piąć się w górę i bezkarnie psuć wszystko jak Facebook. Niektórzy ludzie poruszają się szybko i psują wszystko. Właśnie stąd pochodzi najbardziej niegodziwa rada dotycząca programowania, jaką kiedykolwiek usłyszałem.

1. Nie rób tego, co wszyscy inni

Innowacyjność: Gwiazda polarna każdego inżyniera. To jest wytatuowane na Twojej szyi. Grawerowane na pierścionku zaręczynowym. Co wieczór piszesz o tym w swoim dzienniku. Nie można być programistą, nie będąc jednocześnie innowatorem. Ale co właściwie oznacza innowacja? Bądź inny. Wyróżniaj się w najbardziej możliwy sposób. Nie wpasowuj się. Zrób to wszystko w oryginalny sposób, po swojemu.

Na pierwszy rzut oka ma to sens. Zwłaszcza, gdy siedzisz w obskurnym pokoju z czterema innymi osobami, spiskując i knując nad swoim pomysłem wartym miliard dolarów. Jednak większość z nas nie zdaje sobie sprawy z pewnej rzeczy, planując rozpoczęcie pracy nad Uberem od naleśników: Potrzeba jest matką wynalazku.

Z tego, co zauważyłem, rozmawiając z ludźmi, którzy żyją na tym świecie dłużej niż ja, innowacje to ostateczność. Mam tutaj na myśli wynalazek. Stworzenie czegoś, co nigdy wcześniej nie zostało stworzone. I jest powód, dla którego nigdy wcześniej nie zostało: jest to turbo trudne. I zwykle kończy się porażką. Niesie to też spore ryzyko. Dlaczego więc miałbyś niepotrzebnie je podejmować?

Zbyt łatwo jest rozważyć korzyści płynące z innowacji, zapominając o kosztach. A kosztem tego jest porażka. Co jest w sumie prawie pewne. Tym właśnie jest definicja innowacji. Gdyby sukces był prawdopodobny, nie byłaby to innowacja. Tak więc robienie tego, co wszyscy inni, jest w rzeczywistości świetnym pomysłem. Najczęściej.

Bo jest jedna cudowna rzecz w robieniu tego, co robią wszyscy inni: dokładnie to, że wszyscy inni już to robią. Co oznacza, że to działa. Czy nie jest to coś, na czym powinno nam zależeć? Na rzeczach, które faktycznie działają? Kariera w branży technologicznej nie powinna być serią przypadkowych strzałów. Coś mi mówi, że powinniśmy budować rzeczy, które są faktycznie użyteczne, zamiast gromadzić muzeum nieudanych eksperymentów. Właśnie ta rada często sprowadzała mnie na manowce.

2. Rób to, co wszyscy inni

Jeśli udało Ci się nie pominąć poprzedniego fragmentu artykułu, to pewnie teraz drapiesz się po głowie i zastanawiasz o co tu chodzi. Tę radę najlepiej zilustruje historia: Dawno, dawno temu żył sobie zwykły startup, który miał spore szanse na zaistnienie. Solidny zespół. Zbliżali się do tzw. product-market fit. Wszystko szło bardzo dobrze. Potem usłyszeli, że firmy w każdym zakątku świata przestawiają się na mikroserwisy. Koniec historii.

Wiecie, jak kończy się ta historia? Katastrofą. Mikroserwisy są teraz w modzie. Podobnie jak w modzie były trendy, które już przeminęły. Pamiętasz, kiedy Docker zaczął zdobywać popularność? Można by pomyśleć, że znaleźli lekarstwo na raka. Albo co z boomem na widżety do przesyłania wiadomości? Czy ktoś pamięta jeszcze szum wokół Driftu? Albo tę fazę, kiedy wszystkie nowe startupy budowały swoje MVP z Rustem?

Prawda jest taka, że podążanie za stadem nie zawsze jest najlepszym pomysłem. Ponieważ stado ma tendencję do zbyt częstego błądzenia. Podejmowanie racjonalnych decyzji w oparciu o własne potrzeby jest zawsze mądrzejszym wyborem. Istnieje duże prawdopodobieństwo, że to, co najbardziej odpowiada Tobie, nie będzie odpowiadało innym.

Na przykład, jestem częścią zespołu tworzącego narzędzie do testowania wstecznego strategii handlowych. Jest to w zasadzie tylko frontend stworzony w JavaScript z kilkoma wykresami podpięty do Go REST API. Nic szalonego po stronie technicznej, ale użyteczność polega na zastosowaniu tej prostej technologii.

Testowanie strategii handlowych na danych historycznych jest zazwyczaj uciążliwe. Prościej jest zostać obywatelem USA. Dlatego ułatwiamy to i czynimy bardziej interaktywnym. Ale starczy już tej reklamy, bo produkt nie jest jeszcze gotowy. I o to mi właśnie chodzi. Na tym polega problem, panie i panowie, z robieniem tego, co robią wszyscy inni.

Powinniśmy byli zignorować powszechnie akceptowaną radę, która mówi o tym, że produkt ma być solidny przed wypuszczeniem go na rynek. Najwyraźniej handlowcy poważnie podchodzą do swojej pracy, a eksperymentalny produkt podziałałby im na nerwy. Już dawno powinniśmy byli zepchnąć MVP z gzymsu. W sumie to mogło być nawet BFP, czyli Barely functional product.

Ludziom zazwyczaj nie przeszkadza, że coś nie wygląda tak, jak powinno, a wcześniejsze informacje zwrotne, które otrzymujemy, gdy inni bawią się naszym prototypem, są bardzo cenne. Powinniśmy byli więc ich wpuścić od samego początku. Zaoszczędziłoby to miesięcy niepotrzebnego opracowywania i ulepszania.

Wszystko dlatego, że tworzenie wykresów w JavaScript nie jest jak codzienne zakładanie spodni. Nic tu nie współgra: wszystkie małe kontrolki do podłączenia logiki, cały ten bajzel do ogarnięcia, wszystkie dane do przetworzenia dla wszystkich subtelnie różnych, ale odrębnych poglądów, wszystkie obliczenia layoutu i renderowania dla wielu rozmiarów ekranu - to nie jest wcale fajne. Zwłaszcza, gdy okazuje się, że większość z nich wcale nie musiała być zrobiona.

Tak więc podążanie za innymi owcami? Podziękuj. Myśl samodzielnie. W ten sposób nie będziesz musiał wykonywać cudzej pracy.

3. Buduj tak szybko, jak to tylko możliwe

Wszyscy znamy historię sukcesu jakiegoś startupu, gdzie wyciągnęli złotego królika z kapelusza w dwie minuty. No wiecie, facetów, którzy zadzwonili do Sequoia Capital dzień po tym, jak zaczęli pracować nad swoim MVP. Facetów, którzy skończyli swoje slajdy w poczekalni przed swoim pierwszym pitchem. Następnie udało się im zdobyć 30 mln $. Dla ich serii A.

Budowanie tak szybko, jak to możliwe, jest podstawą kultury technologicznej. Czy zawsze jest to właściwe postępowanie? Chodzi mi o to, że wypchnięcie czegoś na zewnątrz w celu zebrania opinii wydaje się dobrym planem, prawda? Weryfikacja koncepcji. Upewnienie się, że nie budujesz czegoś, czego nie będziesz potrzebować. Ale jest tu haczyk - trudno jest nie budować tego, co nie jest potrzebne, jeśli buduje się w pośpiechu.

Jednak nie chodzi tylko o to. Nawet jeśli budujesz, łatwo jest coś zepsuć, jeśli nie poświęcisz wystarczająco dużo czasu na projektowaniu. Pisanie specyfikacji jest prawdopodobnie ważniejsze niż pisanie kodu. Ustalenie, co zbudować, jest ważniejsze od samego budowania. To pierwsze może pomóc Ci w zaoszczędzeniu ogromnych ilości czasu. Kto wie, być może nie trzeba będzie w ogóle optymalizować jakiegoś fragmentu kodu, ponieważ wcale nie musi istnieć.