Jakiś czas temu miałem okazję przemyśleć kilka najważniejszych lekcji, jakie wyniosłem upgradując przez ostatnie kilka lat swoją rolę w IT - z juniora na doradcę technicznego.
Znajomy z Brainhuba, w którym pracowałem, przesłał mi listę fajnych pytań, które wyciągnęły ze mnie przemyślenia, o których zawsze chciałem napisać.
Możesz przeczytać ładniejszą wersję tych przemyśleń w języku angielskim, która jest jednak opatrzona wieloma zdjęciami mojej facjaty.
W tym wpisie zamieszczam oryginalną wersję w postaci braindumpu.
TL;DR: Nigdy nie decydowałem, kim chcę zostać
Od samego początku kierowałem się w IT tym, czego chcę się nauczyć, a nie tym, kim chcę zostać.
Wiedziałem, że chcę programować i że chcę być w tym dobry, więc zacząłem szukać miejsc i osób, od których mogę się uczyć. Tak się złożyło, że wielu najlepszych programistów, których spotkałem to doradcy techniczni lub osoby, które mogłyby pełnić tę funkcję.
Zacząłem rozkładać ich na części pierwsze, patrzeć co umieją, jakie wyrobili sobie nawyki i modele mentalne, a potem aplikowałem to wszystko u siebie.
Po kilku latach ktoś uznał, że można mi pozwolić odgrywać rolę doradcy technicznego i tak już zostało.
First Principles Thinking
Według mnie poza umiejętnościami technicznymi, które odgrywają mniejszą rolę w IT, niż się może wydawać, kluczowe jest zdobycie odpowiednich umiejętności miękkich (w których nie ma nic miękkiego).
Nie jest to nic odkrywczego, jednak tych umiejętności jest mnóstwo i zastanawiam się czasem, która z tych umiejętności jest najważniejsza. Mógłbym pewnie co miesiąc udzielać innej odpowiedzi na to pytanie.
Jednak coraz częściej wydaje mi się, że najważniejsza jest umiejętność patrzenia na rzeczy takimi, jakimi są, rozkładania ich na części pierwsze i niedopisywania sobie do tego romantycznych historii.
To jest tzw. reasoning from first principles (myślenie przy pomocy podstawowych zasad?).
Moim ulubionym przykładem takiego myślenia jest Elon Musk, który m.in. postanowił zbudować swoją własną rakietę, bo kupno okazało się za drogie:
"If you say, what is a rocket made of? It’s made of aluminum, titanium, copper, carbon fiber. And you can break it down and say, what is the raw material cost of all these components? And if you have them stacked on the floor and could wave a magic wand so that the cost of rearranging the atoms was zero, then what would the cost of the rocket be? And I was like, wow, okay, it’s really small—it’s like 2% of what a rocket costs."
https://waitbutwhy.com/2015/11/the-cook-and-the-chef-musks-secret-sauce.html
Elon rozłożył budowę rakiety na części pierwsze i złożył na nowo, po swojemu, bardziej opłacalnie niż inni.
Ja rozłożyłem na części pierwsze programistów, których szanuję i poskładałem po swojemu zestaw rzeczy, których muszę się nauczyć. A potem zaaplikowałem to, co miało dla mnie sens, czyli wybrane nawyki, umiejętności, sposoby zdobywania wiedzy, modele zachowań itd.
Chodzi tutaj o to, żeby zejść na niższy poziom ze wszystkim, co robimy, zadać sobie wiele razy pytanie "dlaczego tak?", zrozumieć to wszystko i poskładać na nowo biorąc pod uwagę swój własny kontekst.
Takie myślenie pozwoliło mi m.in. przestać wierzyć w talent najlepszych programistów. Przestałem snuć w głowie romantyczne historie (czyli wymówki) na temat tego, jak zdobyli te umiejętności i okazało się, że ja też tak mogę. Przeważnie sprowadzało się to do konsekwentnego robienia prostych rzeczy i ciężkiej (lub też nie) pracy.
Pozwoliło mi też krytycznie spojrzeć na frameworki, czy biblioteki, których używam, na opinie o tym, jak powinno pisać się soft oraz wyeliminować bezcelowe jaranie się technologiami i Cargo Cult Programming.
Gdy rozumiem, dlaczego coś zostało napisane w taki, a nie inny sposób, do czego zostało stworzone i jakimi pobudkami kierowali się twórcy, to łatwiej jest mi ocenić, co jest przydatne w danym kontekście, a co nie. Łatwiej jest mi dobierać narzędzia do problemu albo naginać do rozwiązania problemu te narzędzia, które się mniej nadają, ale których koniecznie muszę lub chcę używać. Łatwiej jest mi powiedzieć, czy jakaś biblioteka to dobry wybór - czy przestrzega podstawowych zasad tworzenia dobrego softu, czy też nie.
Tim Urban z bloga waitbutwhy.com mówi, że myśląc w ten sposób, przestajesz być kucharzem, który używa gotowych przepisów i zaczynasz być szefem kuchni, który te przepisy tworzy.
Wyzwania ścisłej pracy z klientem i wejścia w role liderskie
Znalazłem dwie rzeczy, które okazały się najtrudniejsze w momencie wejścia na wyższy poziom, gdzie musiałem zacząć trochę więcej gadać, a trochę mniej programować.
1. W kontaktach z klientem najtrudniejsze było zrozumienie, że mogę powiedzieć "nie wiem, ale się dowiem i wrócę z odpowiedzią" albo "jesteś w błędzie, to nie zadziała", a potem nauczenie się jak największej ilości kulturalnych wariacji tych zdań, które pozwalają mi wybrnąć z dosłownie każdej, nawet najtrudniejszej dyskusji.
Jest to trudne, bo początkowo mamy błędne przekonanie, że w rozmowie z klientem musimy wszystko wiedzieć albo że klient nasz pan, więc nie można mu podskakiwać. A przecież nie można wiedzieć wszystkiego (za to można się wszystkiego dowiedzieć), a klient płaci nam za to, żeby mu powiedzieć, co zadziała, a co nie (chyba że jesteś małpką do kodzenia, bo wtedy nie ma problemu).
To dotyczy nie tylko klienta, ale wszystkich osób, z którymi mamy styczność w projekcie.
2. W pracy z innymi najtrudniejsze było znalezienie balansu między gadaniem i robieniem. Miałem takie dni, że spędzałem cały dzień na Slacku, spotkaniach i rozmowach. Im więcej masz doświadczenia, tym więcej okazji do spotkań, gadania, mentorowania, poprawiania.
Nauczyłem się, że kluczem do znalezienia balansu jest odpuszczanie, ustalenie swoich zasad pracy i trzymanie się nich. Po czasie ludzie się w końcu przyzwyczajają do twojego nowego trybu pracy. W moim przypadku trzymanie się swoich własnych zasad jest zawsze najtrudniejsze.
Nauczyłem się też, że gadanie, to też często zakamuflowane robienie i budowanie. Wiele razy spotkałem się z czymś takim, że ktoś traktował swój dzień jak zmarnowany, bo nie spushował niczego do repozytorium. Jednak w tym czasie pomógł mniej doświadczonemu programiście naprawić bugi, zaplanował pracę na dwa tygodnie i zrobił design kluczowego mechanizmu w aplikacji. Dla mnie to nie jest powód do nazywania dnia zmarnowanym i przykład, że gadanie może być wartościowe.
Jak się odblokowałem w rozmowach z biznesem
Programiści często są ukazywani w popkulturze jako introwertyczne nerdy, które nie potrafią porozumiewać się z innymi ludźmi. Jest to mocno przesadzony obraz, ale wielu dobrych programistów faktycznie potrafi gadać z kodem, a w kontaktach z interesariuszami coś ich blokuje i dukają na spotkaniach jak pięcioletnie dziecko.
Been there, done that.
Dla mnie powodem, że coś kogoś blokuje, jest jedna z dwóch rzeczy:
- Nie wierzymy w siebie, bo nie znaleźliśmy jeszcze wystarczających dowodów na to, że możemy sobie zaufać.
- Albo po prostu czegoś nie umiemy.
W pierwszym przypadku wystarczy, że spróbuję coś zrobić i wtedy widzę, że sobie radzę, a moja blokada nie miała sensu. W drugim przypadku wystarczy, że po prostu uzupełnię braki wiedzy 🤷♂️.
Zauważyłem, że w rozmowach z biznesem ludziom najczęściej brakuje płynności w rozmowie. Mnie pomogło nauczenie się kilku prostych zdań-wytrychów/łączników, które pozwalają rozmowie płynąć i dzięki nim radzę sobie praktycznie w każdej sytuacji. Nawet jak nie mam zielonego pojęcia, o czym rozmawiamy, albo gdy zapomnę jakiegoś słówka, lub konstrukcji zdania.
Są to zdania typu "przepraszam, ale chyba nie zrozumiałem", "pozwól, że powiem to w inny sposób", albo "nie wiem, czy dobrze rozumiem, chodzi ci o (...)". To są banały, ale działają, bo zawsze się znajdzie ktoś, kto mnie poprawi lub sparafrazuje swoją odpowiedź, żeby była prostsza.
Przydaje się to wszystko głównie dlatego, że eliminuje olbrzymie źródło stresu w pracy.
Gdy zaczynałem w IT, to zawsze się cykałem, że ktoś mnie o coś zapyta, a ja nie będę wiedział, co odpowiedzieć oraz że narobię siary zespołowi i firmie. Ciągnęło się to miesiącami na każdym demo, review, czy nawet rozmowie na Slacku z klientem, aż do momentu, gdy zdecydowałem, że nauczę się, jak sobie z tym radzić. Okazało się to prostsze, niż myślałem, jak z większością tego typu rzeczy.
Nadal jestem przekonany, że znam tylko te 20%, które daje 80% wyników, ale te 20% jest na tyle przydatne, że pozwala np. przekonać klienta do refactoru, na który wcześniej nie chciał się zgodzić itp.
Inna duża korzyść, jest taka, że przestajesz być zespołowym bobasem, któremu ciągle trzeba zmieniać pampersa. Przestajesz być programistą, który potrafi tylko programować, a gdy trzeba przeprowadzić bardziej zaawansowaną rozmowę, to chowa się za monitor.
Nie chodzi tutaj o to, żeby być człowiekiem orkiestrą, który robi robotę za project managera, czy analityka biznesowego, tylko żeby sobie radzić, gdy takich osób braknie i żeby jakość pracy nie spadła.
Nadal jest mało takich osób i przez to jest to jeden z najłatwiejszych sposobów na to, żeby zespół i pracodawca nie chcieli się z Tobą rozstawać. A to oznacza, że masz pewien rodzaj kapitału, który możesz wymienić na lepsze warunki zatrudnienia, cokolwiek to dla ciebie w danej chwili oznacza.
Rola doradcy technicznego nie jest w żaden sposób wyjątkowa
W moich oczach doradca techniczny, to po prostu programista, który rozwija wszystkie umiejętności, a nie tylko techniczne, który zebrał doświadczenie z wielu projektów i którego wyciągnęli z jednego zespołu, żeby wsadzić do kilku.
Zmieniają się głównie soczewki, przez które taki programista patrzy na tworzenie produktu i przez to potrafi doradzić z rzeczami, a na które inni nie zwracają uwagi lub nie mają czasu zwrócić uwagi.
To, że ma najczęściej więcej doświadczenia niż inni i szeroki zakres umiejętności jest naturalne. Zwłaszcza jeśli świadomie rozwija się jako "T-Shape" (inaczej "generalizing specialist") oraz zbiera doświadczenie z różnych zadań i projektów.
Zbyt mała lub zbyt duża pewność siebie
Obserwując nowe osoby przychodzące do zespołu, często widzę dwie rzeczy: zbyt małą lub zbyt dużą pewność siebie.
Zbyt mała pewność siebie objawia się tym, że wycofujesz się z projektu i nie angażujesz się w jego życie tak, jak osoby, które już tam są jakiś czas. To jest najczęściej przypadłość juniorów.
Zespół na tym traci, bo "świeża" osoba często dostrzega niedopatrzenia albo wręcz głupoty, do których reszta zespołu może być już przyzwyczajona.
Staram się zawsze zachęcać nowe osoby, żeby się odzywały, gdy widzą, że robimy coś głupiego, póki jeszcze nie wsiąknęły za bardzo w projekt.
Jednocześnie, nie angażując się w projekt, sami tracimy możliwość szybkiego rozwoju i wykazania się. Sam początkowo hamowałem swój rozwój, bo zbyt bezpiecznie podchodziłem do nowego projektu. Przez długi czas robiłem praktycznie ciągle to samo, brałem najprostsze zadania na tym samym poziomie skomplikowania i bałem się wskoczyć na głęboką wodę. Wmawiałem sobie, że robię rozeznanie i wdrażam się w projekt.
Problem jest taki, że nie można takiego podejścia nazwać rozwojem. Rozwijamy się wtedy, gdy robimy zadania na granicy swoich możliwości i przeplatamy je łatwiejszymi zadaniami, żeby trochę odsapnąć. Biorąc na siebie najprostsze zadania, nie ma szans, żeby się wykazać.
Z dużą pewnością siebie jest podobnie - traci zespół oraz my sami.
Tutaj najczęściej chodzi o utrzymanie jakiegoś statusu (lub złudzenia statusu) wobec siebie lub innych osób.
Sprowadza się to do tego, że osoby zbyt pewne siebie prawią kazania jak coś "powinno" lub "nie powinno" wyglądać (nie powinniśmy używać Postgresa, tylko Mongo itp.), nie znając nawet projektu i wszystkich decyzji podjętych w przeszłości.
Z drugiej strony, nie proszą o pomoc, gdy sobie z czymś nie radzą i opóźniają przez to prace.
Z takimi osobami ciężko się pracuje, jednak najczęściej jesteśmy w stanie oduczyć ich takich zachowań, a wtedy często okazuje się, że mamy do czynienia z naprawdę fajnymi ludźmi.
Gdy porzucamy chęć utrzymania statusu, to odblokowuje się olbrzymia część energii mentalnej, którą można przeznaczyć na szybszy rozwój.
Co ciekawe, można by pomyśleć, że taka chęć utrzymania statusu dotyczy raczej doświadczonych osób, ale bardzo często widzę to też u początkujących programistów.
Niektórzy myślą, że jak przeczytali cztery książki do programowania od deski do deski, napisali ze znajomym pet-projekt, który wrzucili na GitHuba i robili jakiś freelancing na boku, to już naprawdę ogarniają. Z własnego doświadczenia wiem, że lepiej szybko sobie wybić takie myślenie z głowy, bo mocno hamuje rozwój.
Nie spiesz się tak
Jeśli miałbym sobie udzielić jednej rady na początku mojej drogi w IT, to brzmiałaby ona mniej więcej tak:
Zwolnij, dokumentuj swoją drogę w trwały sposób w internecie i zadaj sobie czasem pytanie: "Will I love the process of getting better at this?".
Te trzy rzeczy są ze sobą mocno powiązane.
Ja drogę rozwoju zawsze wyobrażam sobie jak etap w grze. Gdy wykonasz główny cel jakiegoś etapu, to masz opcję przejścia do następnego, albo zostania w obecnym i odkrywania opcjonalnych rzeczy na mapie. I trochę za późno nauczyłem się, że te opcjonalne rzeczy są bardzo wartościowe. Gdybym odpowiadał sobie na pytanie "will I love the process (...)", to odpowiedź bardzo często wskazywałaby właśnie na te opcjonalne rzeczy.
Najlepiej pokazać to na dwóch przykładach:
Moja ścieżka rozwoju to speedrun - działałem szybko, żeby dostać awans na seniora i związane z tym benefity, szybko przechodziłem kolejne etapy, pomijałem opcjonalne rzeczy takie jak dokumentowanie swojej drogi, czy zgłębianie się w jakąś technologię dla samej przyjemności, robiłem rzeczy, których nie chciałem za bardzo robić i przez to miałem momenty, kiedy odechciewało mi się wszystkiego.
Osiągnąłem praktycznie wszystkie swoje cele (to na plus), ale przez to za bardzo nie wiem, co ze sobą zrobić. Chciałbym wrócić do tych opcjonalnych rzeczy, ale albo nie mam takiej możliwości, albo po prostu mi się nie chce, bo tematy z przeszłości przestały mnie interesować.
Skontrastujmy to z przykładem osób, które działają na odwrót - rozwijają się powoli, nie kierują się awansem, tylko przyjemnością z pracy, minimalizują robienie rzeczy, których nie lubią (to nie znaczy, że nie umieją ich robić), dokumentują swoją drogę, dużo odpoczywają.
Takie osoby też osiągną swoje cele i najprawdopodobniej nie wylądują w miejscu, w którym nie wiedzą, co ze sobą zrobić, albo bardzo ten moment opóźnią.
A powolny rozwój i zgłębianie tych opcjonalnych rzeczy spowoduje, że jeszcze utrwalą sobie wiedzę, przez dokumentowanie udowodnią, że się na czymś znają i dzięki temu zwiększają prawdopodobieństwo spieniężenia swojej wiedzy i umiejętności. Znam początkujących programistów, którzy mimo mniejszego doświadczenia, stworzyli własne produkty na temat rzeczy, których się niedawno nauczyli, zamiast za wszelką cenę walczyć o kolejny awans.
Robienie takich rzeczy po fakcie jest trudniejsze, bo człowiek już nie jest tak zajarany, jak był kiedyś.
Optymalna droga leży pewnie gdzieś pośrodku, ale jestem przekonany, że w tym drugim przypadku, ogólny koszt, poza poświęconym czasem, jest mniejszy.
Na taką drogę poświęcamy więcej czasu, jednak czas wyczerpuje się wolniej niż zapał do pracy, co mnie ostatnio bardzo zaskakuje.