4 obelgi, dzięki którym stałem się silniejszy (jako programista)

Do 2020 roku byłem typem programisty, który:

1. napisał wszystkie backendy w Pythonie 2.8 i Flasku oraz wdrożył je na Google Cloud Platform, niezależnie od przypadku użycia
   
   
2. polegał na Google Cloud Datastore dla wszystkich potrzeb związanych z bazami danych
   
   
3. nigdy nie używał deklaracji zmiennych let lub const w JavaScripcie, ponieważ znał tylko ES5 (czyli JS z 2009 roku)
   
   
4. używał AJAX i document.getElementById za każdym razem, gdy chciał zaktualizować interfejs użytkownika na froncie, ponieważ zakładał, że to jedyny sposób.
   
   

Z radością podchodziłem do tego sposobu robienia rzeczy, oferując swoje usługi jako „programista” na Upwork i otrzymując wynagrodzenie w wysokości od 0,06 USD za projekt (ten zajął kilka godzin i obejmował stworzenie niestandardowej aplikacji komputerowej dla systemu Windows dla faceta, który chciał masowo tłumaczyć za pomocą interfejsu API Tłumacza Google) do około 12,50 USD za godzinę — to było za wprowadzenie firmy, która używała Arkuszy Google jako bazy danych i Power BI jako frontendu, do nowoczesnego świata (nowoczesnego świata 2009 roku, to znaczy z tysiącami linii ES5 mojego waniliowego JS).

Więc tak, byłem programistą, ale nie do końca — jak osoba, która mówi, że zajmuje się „budową wieżowców”, ale wszystko, co robi, to układanie domów z prefabrykatów jeden na drugim w gigantyczny stos. Opracowałem systemy i wdrożyłem je w chmurze, ale mój repertuar był bardzo skromny, a wszystkie moje rozwiązania były bardzo szablonowe i powtarzalne.

Następnie (przy wielu okazjach w ciągu około roku) zostałem zwyzywany za brak podstawowych umiejętności i wiedzy jako programista, przez ludzi od CEO startupu po faceta, którego nigdy nie spotkałem. Komentarze, które padały, początkowo mnie obrażały i złościły, ale w dłuższej perspektywie miały wpływ na mój rozwój osobisty i sukces. W rzeczywistości jestem niezmiernie wdzięczny za każdą z otrzymanych obelg i zniewag, więc chciałbym je tutaj opisać, wraz z powodami, dla których były śmieszne (z perspektywy czasu) i pozytywnym wpływem, jaki na mnie wywarły.

#1: „Po prostu nie widzę cię jako... programistę. Musimy sprowadzić tu kogoś, kto robił to już wcześniej i wie, co robi”

Jeśli o moim obecnym sukcesie można myśleć jak o wieży, to ten komentarz jest zarówno fundamentem, który ją podpiera, jak i firmą budowlaną, która przeniosła ją z projektu do rzeczywistości. Nigdy wcześniej nie powiedziano mi tak wprost, że mój wizerunek („programisty”) nie pasuje do tego, co widzą inni. Bardziej niż jakakolwiek inna obelga, ta jedna popchnęła mnie do przodu we wczesnych latach 2020-tych, motywując do nauki, aby stać się „prawdziwym” programistą i właśnie tak być postrzeganym.

Ironia: Zadanie (w czasie, gdy otrzymałem tą uwagę) polegało na rozpoznawaniu i numerowaniu obrazów przy użyciu widzenia komputerowego, a wszystko, co mieliśmy jako dane wejściowe, to duże obrazy *.jpeg o bardzo niskiej jakości (zarówno pod względem rozdzielczości, jak i oświetlenia), zawierające tylko 3 pasma widmowe (RGB), wykonane z dronów. Wiedząc to, co wiem teraz o wizji komputerowej, mogę z całą pewnością stwierdzić, że zadanie było w rzeczywistości niemożliwe do wykonania, nawet gdyby mieli kogoś, kto „robił to wcześniej” i „wie, co robi”. Aby zrobić to poprawnie, potrzebowalibyśmy przynajmniej pewnych informacji radiometrycznych (z niewidzialnego widma) lub obrazów o wyższej rozdzielczości.

Efekt: Nie potrafię wskazać jednej konkretnej rzeczy, do której skłonił mnie ten komentarz. Jest to raczej siła napędowa dosłownie całego mojego rozwoju jako programisty od 2020 roku. Dziękuję, panie CEO od startupu z nikczemnymi powiązaniami z branżą konopi rekreacyjnych!

#2: „Brak wiedzy technicznej”

Taki był podany „Powód:” w wiadomości e-mail, którą otrzymałem, informując mnie, że zostałem pominięty przy rekrutacji na stanowisko programowania w JavaScripcie. Dlaczego dokładnie uważali, że brakuje mi wiedzy technicznej? Podczas rozmowy kwalifikacyjnej zapytali mnie o kilka nowoczesnych słów kluczowych i koncepcji JavaScriptu, a ja nie poradziłem sobie zbyt dobrze z ich wyjaśnieniem (ponieważ większość mojego programowania do tego momentu robiłem w JavaScript ES5, który został wydany w 2009 roku). Ponadto w zadaniu programowania na żywo użyłem pętli for do iteracji przez tablicę, a następnie poproszono mnie o wymyślenie alternatywy dla pętli „for”, czego nie potrafiłem zrobić.

Ironia: Krótko po tej nieudanej rozmowie zarejestrowałem się w TekSystems (globalnej firmie rekrutacyjnej IT) i zostałem poproszony o wzięcie udziału w godzinnym teście oceniającym JavaScript. Okazało się, że jestem w 93. percentylu, pomimo mojego „braku wiedzy technicznej”. Wygląda na to, że jestem kiepski w wyjaśnianiu koncepcji kodowania werbalnie podczas rozmowy kwalifikacyjnej, ale całkiem dobry w faktycznym kodowaniu.

Efekt: To doświadczenie skłoniło mnie do ukończenia kursu JavaScript Free Code Camp, co było jak wejście do wehikułu czasu, który przeniósł mnie z 2009 roku do wspaniałej teraźniejszości JS. Sprawiło to również, że zacząłem interesować się programowaniem funkcyjnym (dzięki temu, jak źle została przyjęta pętla „for”, którą wymyśliłem), w wyniku czego naprawdę rozwinąłem się jako programista, szczególnie w zakresie umiejętności czytania i rozumienia kodu napisanego przez innych ludzi.

#3: Drwiący chichot (he he he)

To doświadczenie sprawiło, że poczułem się najgorzej i najbardziej źle ze wszystkich. Historia jest taka, że była to spontaniczna „rozmowa kwalifikacyjna” przez Skype'a, do której dołączyłem około 23:00, stojąc boso w ciemnym hotelowym lobby na wsi w Japonii, tak blisko hotelowego routera WiFi, jak tylko mogłem. Facet (w innej strefie czasowej niż ja) szukał „programisty front-endu (html i js), ze znajomością Pythona i Flaska” zgodnie z opisem stanowiska. W tamtym momencie mojego życia używałem tylko Pythona i Flaska — w szerokim zakresie — i napisałem dosłownie dziesiątki tysięcy linii skryptów js i html. Pomyślałem, że idealnie nadawałbym się do tej pracy, dlatego nie spałem do 23:00, aby mieć szansę na rozmowę kwalifikacyjną.

Pierwsze pytanie, jakie mi zadał, brzmiało: „Jaka jest różnica między złączeniem wewnętrznym i zewnętrznym w SQL?” Będąc przygotowanym na pytania front-endowe/JavaScriptowe/Pythonowe, nie mogłem od razu odpowiedzieć na pytanie, więc zacząłem mówić jakieś losowe rzeczy o tabelach SQL (jednocześnie naśladując małe ręczne tabele SQL rękami — jakbym trzymał dwa smartfony — składając je i rozbierając), gdy nagle facet faktycznie przerwał mi w połowie zdania, mówiąc „He he he. Przepraszam, myślę, że potrzebujemy kogoś, kto wie nieco więcej o danych.” 10 sekund później (po pustym zakończeniu typu „dziękuję za poświęcony czas”) połączenie zostało zakończone.

Ironia: „He he he. Przepraszam, myślę, że ty potrzebujesz kogoś, kto wie więcej o pisaniu odpowiednich opisów stanowisk, zanim zaczniesz marnować czas ludzi w środku nocy.” Oczywiście to właśnie chciałem mu powiedzieć. Rozmowa kwalifikacyjna osoby na stanowisko związane z front-endem, a następnie odrzucenie go, ponieważ nie potrafi odpowiedzieć na pytanie SQL, jest absolutnie absurdalne.

Efekt: Dzięki temu doświadczeniu z pewnością zainteresowałem się bardziej SQL, a w szczególności różnicą między złączeniem wewnętrznym i zewnętrznym. Następnie aktywnie uczyłem się PostgreSQL, a nawet wdrożyłem kilka baz danych na Google Cloud Platform. Aha, a teraz mój rzeczywisty tytuł zawodowy to „Data Scientist”, więc myślę, że nie jestem tak nieświadomy danych, jak myślałem.

#4: „Po prostu nie sądzimy, że będziesz w stanie od razu zacząć działać”

Wahałem się, czy zamieścić to zdanie, ponieważ tak naprawdę nie jest to obelga. Przyznam też, że jest w tym trochę prawdy. Ta uwaga została wypowiedziana (po mojej drugiej rozmowie technicznej) przez duży startup zajmujący się logistyką magazynową i robotyką. Chwalili jakość mojego kodu i metodologię po tym, jak zgłosiłem się do wyzwania kodowania, które mi dali, ale dwa tygodnie później otrzymałem e-mailem oświadczenie, że „nie jestem w stanie zacząć działać”.

Ironia: Myślę, że nawet ewentualne przybycie do miejsca pracy już by było czymkolwiek, gdybym został zatrudniony przez ten startup, ponieważ — patrząc na ich stronę internetową — wygląda na to, że wciąż są w fazie „rozruchu i zatrudniania”, nie budując jeszcze niczego (około 6 miesięcy później, w momencie pisania tego tekstu).

Efekt: Kiedy o tym pomyślałem, zacząłem dostrzegać prawdę w tym stwierdzeniu. Prawdopodobnie nie byłbym w stanie od razu działać, zwłaszcza jeśli byłby to szybko rozwijający się projekt z dziesiątkami lub setkami innych programistów. Ostatecznie to stwierdzenie pomogło mi zrozumieć, że jako programista potrzebowałem doświadczenia w pracy w dużym zespole, nad dużym projektem, aby zyskać wiarygodność.

Alchemia jest prawdziwa: Gniew przeradza się w motywację

Patrząc wstecz, jestem teraz z pewnością lepszym programistą niż w 2020 roku. W końcu przestałem używać Google Cloud Platform do wszystkiego (teraz jestem w dokładnie takim samym niezdrowym związku z AWS Amplify!), nauczyłem się pisać nowoczesny JavaScript i zdałem sobie sprawę, że aktualizowanie interfejsu użytkownika za pomocą AJAX i document.getElementById jest trochę jak używanie gołębi pocztowych i Roomby do zdalnego budowania domu z klocków LEGO (hej, po prostu użyj Reacta). Cały rozwój, który udało mi się osiągać, zawdzięczam komentarzom, które opisałem powyżej, oraz gniewowi i motywacji, które te komentarze zainspirowały.

Oryginał tekstu w języku angielskim przeczytasz tutaj