Jak przejść na wyższy poziom w programowaniu?

Krzysztof Kempiński
Apr 27 · 18 min read

W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Przemkiem Smyrdkiem o tym jak przejść na wyższy poziom w programowaniu.

Posłuchaj naszej rozmowy w wersji audio 🎧 👇

Cześć! Mój dzisiejszy gość to programista z ponad siedmioletnim doświadczeniem. Głównie z obszarów frontendu, lider zespołów, mentor, osoba prowadząca warsztaty. Dzieli się wiedza na blogu, czy kanale na YouTube. Współtwórca Przeprogramowanych, twórca kursów Opanuj JavaScript i LevelUp. Przedstawia się, jako osoba, która pomaga programistom rozwijać kompetencję techniczne i umiejętności miękkie.

Moim i waszym gościem jest Przemek Smyrdek.

Cześć Przemku! Miło mi Cię gościć w podcaście.

Cześć! Witaj serdecznie i dzięki za zaproszenie.

Przyjemność po mojej stronie. Właśnie, trochę na canvie tego Twojego kursu, o którym tutaj wspomniałem, chciałem porozmawiać z Tobą o tym, co programista może zrobić, żeby sobie na kolejny poziom w swoim rozwoju. Dzisiaj mam nadzieję, poruszymy tematy i techniczne i miękkie, jak to sobie życie poukładać. Cieszę się bardzo na tą rozmowę.

Na początku standardowo chciałbym Cię zapytać, czy słuchasz podcastu oprócz tego, że tworzysz, jeśli tak, to może jakieś swoje ulubione masz?

Tak, słucham podcastów. Powiem Ci, że jest to chyba jedna z najbardziej wartościowych odkryć, jeśli chodzi o różne źródła zdobywania wiedzy wszelakiej. W moim przypadku ostatnio to się ogranicza do dwóch, trzech podcastów. Najwięcej teraz słucham podcastu Lexa Friedmana. To jest osoba, która jest rosyjskim emigrantem, wywodzi się ze środowisk naukowych. Jest to osoba, która wykładała na uczelni tematykę związaną z AM, z robotyką. Teraz prowadzi swój własny podcast, zaprasza tam osoby nie tylko z dziedziny nauki informatyki, ale również szeroko rozumianego rozwoju. Lex to jest taki gość, który mi imponuje, jeśli chodzi o podejście do rozwoju, ale też poszerzanie poglądów.

Kolejną taką osobą jest Joe Rogan. Jak na autora największego podcastu na świecie przystało, dość łatwo trafić na Joe Rogana. U Joe akurat najbardziej podoba mi się też ta różnorodność. Znaczy, nigdy nie wiem na kogo trafię. Mam też taką lekkość w tym, żeby powiedzmy wyłączyć odcinek po 40 minutach i wrócić sobie do niego za kilka dni.

Trzecia z takich osób to jest Tim Ferriss, chociaż Tima Ferrissa słucham troszkę mniej, ale Tim Ferriess to jest również dobra osoba do tego, żeby posłuchać na przykład co nieco o świecie związanym z inwestycjami, ze zdrowiem, z finansami. To jest osoba, która wydała kilka znanych książek jak chociażby 4-godzinny tydzień w pracy i związany z własnym rozwojem, więc te trzy podcasty to jest, powiedzmy takie 90% mojego czasu i pomiędzy tym oczywiście trafia się jakieś mniejsze kanały, ale głównie to się sprowadza do tych trzech.

Pewnie, bardzo fajna rekomendacja. Też biorąc pod uwagę to, że tam przeważnie odcinek trwa godzinę, dwie, to też wypełnia trochę czasu.

Tak, zdecydowanie.

Pewnie.

Jakiś czas temu nagrywałem podcast o Senior Developerze, o tym, kim ta rola powiedzmy, jest. Tam dużo było o rozwoju umiejętności technicznych, wiadomo, to jest niezbędny element rozwoju, będąc deweloperem, chcąc swoją ścieżkę kariery gdzieś tam bardziej jeszcze kierować może architekta, może kogoś więcej, bo tutaj wiadomo, że tych ról może być odpowiednio więcej.

Natomiast umiejętności techniczne to niezbędna rzecz. tutaj właśnie chciałem Ciebie podpytać, jak ty interpretujesz wchodzenie na kolejny poziom, w programowaniu skupmy się na tej branży, obszarze IT. Czy też uważasz, że umiejętności twarde są niezbędne? Myślę sobie, że to jest takie trochę gonienie króliczka. W sensie nigdy nie będziemy w 100% na bieżąco, nigdy nie będziemy w 100% wszystkiego wiedzieć, ciągle musimy z tym nurtem gdzieś tam podążać. Czy więc takie bycie ninja full stackiem, który zna każdy element stosu technologicznego, to jest takie dążenie, które powinno nam przyświecać, czy też może wejście na wyższy poziom w programowaniu oznacza trochę wyjście poza ten schemat. Jak sądzisz?

Powiem Ci, że osobiście nie jestem przekonany do tej idei, że im bardziej ninja jesteś, tym bardziej to Twoje seniority wzrasta. Po prostu jesteś bardziej ninja, ale ninja seniority nie zawsze muszą iść w parze. Niedawno czytałem sobie o takiej ciekawej metaforze, czy też analogii związanej z tym, co to jest właśnie być kimś, kto osiąga takie 10 na 10, będąc ocenianym z zewnątrz. To była analogia do gimnastyki. W gimnastyce jest rzekomo tak, że większość osób jest w stanie wykonywać te same akrobacje, ale te same akrobacje dają Ci powiedzmy, maksymalnie 9 na 10.

Teraz masz kolejne takie kroki, które sprawiają, że walczysz o te 10 pozostałych procent. jeden z takich kroków, to jest na przykład ekspresyjność, energetyczność tego Twojego całego procesu, to jak po prostu bardzo się wyróżniasz, pomimo powielania tych samych kroków i robienia tych samych figur, co wszystkie inne osoby. Jednak przez swoją osobowość, tą właśnie wybuchowość, ten styl, który dokładasz, możesz zyskać kolejne z tych 10%.

Tam również było te ostatnie konkretnie trzy dziesiąte o podejmowaniu ryzyka. To znaczy, jeśli każdy gimnastyk, każda gimnastyczka jest w stanie wykonywać większość tych samych figur, to tak naprawdę co, czy ten sport się zatrzymał? Musielibyśmy przestać rywalizować, przestać organizować konkursy, bo wszystko sprowadzałoby się do tego, czy potrafisz wykonać daną figurę. Więc tam musi być coś więcej. Ja tak widzę troszkę to programowanie, to znaczy bycie tym ninja, to jest dobijanie do tego 9 na 10, ale dalej są pewne takie szlaki, które niektórzy się nie zapuszczają, bo się boją. Są takie drogi, które nie każdemu pasują, ale tam właśnie widzę taki kolejny poziom.

Jasne. Mogę tak trochę odnieść tę analogię do tego, jak się mówi o programowaniu, czy to jest rzemiosło, czy to jest sztuka. Może jakieś tam powiedzmy elementy, pierwiastki sztuki być może się tam dopatrywać, ale mimo wszystko na co dzień większość programistów wykonuje tam jakieś tam rzemiosło.

Tutaj właśnie dobrze to oddaje to, o czym mówiłeś, nawet jeśli mamy to rzemiosło super opanowane, a tak de facto powinno być, że mamy jakąś znajomość tych narzędzi gdzieś tam w miarę ogarniętą. Musimy się też czymś wyróżniać, musimy jakoś chcąc, iść dalej, wychodzi poza tylko te standardowe, podstawowe umiejętności, takie rzemieślnicze i wyróżniać się czymś więcej. O tym między innymi będę chciał dzisiaj z Tobą szerzej i głębiej porozmawiać.

To jest też tak, że patrzymy sobie na takiego super senior uber dewelopera, który gdzieś tam już ma ileś tych lat doświadczenia projektów za sobą. Nie widzimy tej drogi. To jest standardowy pajac, który też wpadamy, że widzimy kto, gdzie obecnie jest. Zastanawiając się, ile musiał włożyć energii i poświęceń w całe to dążenie.

Takie ulepszanie siebie, jako programista to też jest droga. To taka niekończąca się droga. Jakie rady byś dał komuś, kto by chciał sobie tę drogę zaplanować, od czego może zacząć?

Ja przede wszystkim zacząłbym od pogodzenia się z tym faktem, że technologia to jest właśnie to 90%, natomiast ciężko zostawać przy samej technologii i uzyskać te pozostałe 10. teraz pytanie, jak o te pozostałe 10% powalczyć. Prawdopodobnie tę walkę zacząłbym od tego, żeby lepiej poznać siebie i zadać sobie pytanie, w która stronę tak naprawdę chce iść. Bo jak mówisz o drodze, to dróg mamy mnóstwo i każdy pewnie będzie sobie wybierał inną drogę, trochę inny kierunek, ale warto byłoby być na takiej drodze, która będzie lekko niekomfortowa, ale też jakby dopasowana do tego, w co wierzymy, z jakimiś przekonaniami idziemy przez życie, czy też po prostu możliwa do wykonania, bo często jest tak, że stawiamy przed sobą jakieś absurdalne cele, one nie są możliwe do wykonania i zamiast rozwoju pojawia się jakaś frustracja.

Jak ja na przykład powiedziałbym sobie, że chce być astronauta, albo inżynierem SpaceX to jasne, jedna i druga ścieżka jest możliwa, ale pewnie mieszkając w Polsce, będzie trudniejsze niż na przykład wyznaczanie sobie takich samych celów, jak mieszkasz gdzieś w okolicach przylądka Canaveral, czy jednego z biur SpaceX.

Jak sobie wyznaczać ten kierunek? Ja na przykład użyję tutaj bardzo niebezpiecznego słowa jak coaching, które wielu programistom będzie się od razu kojarzyć z jakimiś dziwnymi, podejrzanymi aktywnościami. Niestety coaching bardzo ucierpiał przez kilku magików, którzy zszargali reputację całej tej branży, bo coaching jest takim narzędziem, jak chodzenie do psychologa, albo robienie brain stormingów. To jest pewna określona aktywność, gdzie spotykamy się z osobą, która jest w stanie z nas coś wyciągnąć, zadaje nam odpowiednie pytania, przez które uzyskujemy lepsze zrozumienie samego siebie. Jak już przejdziemy sobie przez kilka sesji coachingowych, to nagle zaczynamy rozumieć, że w zasadzie wygląda na to, że chodzi mi o to i o to. Czyli właśnie to zadawanie sobie właściwych pytań, takie narzędzia, jak na przykład coaching, mogą Ci pomóc określić ten kierunek.

Kolejna sprawa to jest też rozmowa z lepszymi od Ciebie. Oczywiście też dla programistów introwertyków nie jest to tak oczywiste, że spotykamy się z innymi i rozmawiamy. Ja na przykład sam nie jestem wielkim fanem jakiegoś bardzo intensywnego networkingu, na przykład na konferencjach, nigdy nie byłem bardzo mocny w tym, ale teraz mamy czasy pracy zdalnej i pewnego takiego defaultowego dystansu pomiędzy nami i myślę, że to jest troszkę mniej niekomfortowe, żeby napisać do kogoś na LinkedIn z pytaniem o coś związanego z rozwojem, na przykład z karierą i umówić się na trzydzieści minut na Meet’cie i porozmawiać, że słuchaj, jesteś na przykład na wysokim stanowisku w dobrej firmie — jak tam doszedłeś? Jakby jak wygląda ta Twoja droga, jakie wyrzeczenia były po drodze, jaki był ten koszt. Tak naprawdę na tej podstawie zaczynasz sobie budować takie wyobrażenie. Tutaj zachęcałbym do tego, żeby nie podejmować decyzji przedwcześnie, ale żeby sobie wybadać teren, żeby zrozumieć, jakie są opcje, jakie są stanowiska, jeśli na przykład pracowałeś w określonym typie firmy, to jakie są może inne firmy, jakie są inne wyzwania, dlaczego jest warto, zainteresować się innymi firmami, czy też wyzwaniami no wtedy zacząć sobie rysować jakiś plan.

Tutaj może być bardzo pomocna rozmowa z managerem. Jeśli jesteśmy w firmie, gdzie regularnie spotykamy się z naszym managerem, to jednym z celów takiego managera będzie to, żeby wpływać pozytywnie na nasz rozwój, i również możemy o tym porozmawiać. To znaczy, posłuchajmy jednego, czy drugiego podcastu, programiści mówią o tym, że się rozwijają i pytanie mój drogi managerze — co ja mogę zrobić w tej firmie bez podejmowania jakichś radykalnych kroków, żeby iść gdzieś dalej. To wszystko na zasadzie procesu i ścieżki ich wypracowywania niż dawanie jakichś tutaj złotych porad. Warto sobie po prostu, tak jak czasami mówi się, że jest to macierz tych knows i unknows. Warto sobie po prostu zdefiniować co już wiem, czego nie wiem, że nie wiem i zyskać świadomość. Jak zyskamy świadomość, to możemy zacząć z tym pracować w taki bardzo praktyczny sposób, który dodatkowo będzie pasował do nas. Bo myślę, że to jest tutaj kluczowe.

Powiedziałeś o coachingu, o tej takiej trochę zniesławionej opinii, jaką ma coaching w Polsce nie właściwie, to jest jakby nie efekt samego coachingu, tylko osób, które się parają, powiedzmy, czy też parały tym coachingiem. No ale tak jak sobie myślę o coachingu, to pierwsze co mi przychodzi do głowy, to strefa komfortu, to magiczne wychodzenie ze strefy komfortu i to faktycznie, możemy się z tego śmiać, natomiast jest w tym jakieś tam ziarenko prawdy i faktycznie można powiedzieć, że każdy rozwój, niezależnie czy branży IT, czy nawet jak spojrzymy na rozwój dziecka, to jest wychodzenie trochę spoza strefy, gdzie jest nam dobrze, gdzie wiemy, gdzie się poruszamy i wchodzenie w coś, co jest dla nas zupełnie nieznane, niezbadane. To jest też taka jedna z cenniejszych też rad, jaką w ogóle można komuś dać, żeby próbował rzeczy, których jeszcze nie próbował.

Skupmy się może na IT, na programowaniu jako pragmatycznej dziedzinie. To wychodzenie ze strefy komfortu tak zwane w IT, czy też programowaniu, to na jakie konkretne działania byś przełożył. Co konkretnie taka osoba by mogła robić, by trochę ta swoją strefę komfortu poszerzać?

Pierwsze, co przychodzi mi do głowy, to jest spędzanie czasu z osobami z działów innych niż inżyniering, dział programistyczny, bo to da Ci ogromną dawkę wiedzy, jakie są prawdziwe problemy w firmie, jakie są prawdziwe problemy osób na innych stanowiskach, czemu relacje pomiędzy poszczególnymi działami wyglądają tak, jak wyglądają. Tutaj bardzo często programiści będą musieli walczyć z takimi swoimi błędnymi przekonaniami, na przykład praca w supporcie kojarzy nam się z pracą na słuchawce, bo mamy wyobrażenie pana w firmie X, który kiedyś po prostu zachowywał się źle w naszym stosunku, jeśli chcieliśmy coś załatwić w banku.

Czasami dzwonimy do banku, okazuje się, że ktoś na słuchawce ma zły dzień i zaczynamy sobie budować jakieś wyobrażenia. Okazuje się, że osoby pracujące w supporcie w naszej firmie mają czasami podobne dni, ale jednak są w stanie nam wytłumaczyć przy kawie, z czego to się bierze. Również od tego samego supportu, na przykład na programie zaczną nam przychodzić jakieś tickety, albo bagi, support zacznie mieć problemy, kiedy wypuścimy nową funkcjonalność i tych zgłoszeń od klienta związanych z tym, że coś nie działa, zacznie być więcej. To jest z jednej strony takie budowanie relacji, ale z drugiej strony też po prostu empatia, czyli rozumienie problemów osób w innych działach i zastanawianie się jak ja mogę im pomóc tak naprawdę.

Jest taki słynny post w tym naszym półświatku programistycznym o programistach, którzy mogą być w takich dwóch wiaderkach. To znaczy może być w cost centre albo w profit centre. Jeśli jesteś zainteresowany technologia i totalnie nie interesuje Cię jak pomóc innym, to niestety sam się piszesz na ten cost centre. Jeśli chcesz niego wyjść i chcesz się znaleźć w tym profit centre, to teraz trzeba szukać okazji, żeby ten profit firmie dawać. To jest albo na przykład ze sprzedawcami, albo rozmowa z supportem, albo rozmowa z osobami, które wdrażają nasz system. Po prostu skracanie tej drogi do klienta. Myślę, że to jest taka bardzo praktyczna porada, która w oczach pracodawcy sprawi, że będziesz bardziej wartościowy, ale też u Ciebie myślę, że spowoduje kilak ciekawych reakcji wewnątrz, które po prostu pozwolą Ci inaczej patrzeć na osoby, z którymi współpracujesz, z którymi się kontaktujesz codziennie.

Więc tak jak wcześniej powiedziałeś, coaching to jest jedna z takich aktywności, warto się przełamać, ale po drugie, nawet jeżeli nie chcemy brać udziału w takich aktywnościach jak coaching, to biznes i interesowanie się tym, co jest poza programowaniem. Bo ta firma w jakiś sposób robi pieniądze. To nie jest tak, że z każdą linijką kodu, te pieniądze w firmie się pojawiają, więc cały ten proces od napisania kodu, do otrzymania zapłaty jest czymś, co na pewno warto rozpoznać.

Czy takie zaprzestanie myślenia wąskotorowego, takiego zamkniętego właśnie w technologii, próba zrozumienia, w jakim kontekście ten rozwój programowania się znajduje, na co on wpływa, jak wpływają pieniądze, na co wpływają? Myślę, że to to też otwiera, tak jak powiedziałeś, różne rzeczy.

Tak, wiesz, myślę, że to jest wciąż taka aktywności, która nie jest standardem. Wydawałoby się, że powiedzmy czy ja, czy Ty, osoby, które działają, w kręgu dzielenia się wiedzą, albo przynajmniej starają się poszerzać te horyzonty, no to to jest ten bias, o którym też powiedziałeś. Można mieć wrażenie, że wszyscy w naszej branży pracują w ten sposób, że naturalnie nie interesujesz się tym, co dzieje się w innych działach, ale wydaje mi się, że tak nie jest, że to cały czas jest aktywność, która po prostu warto promować.

Myślę, że na przykład uczelnie techniczne często Ci nie powiedzą o takiej aktywności, bo ich zadaniem jest przygotowanie Cię do takiego bardzo ogólnego zawodu programisty, poznanie języków.

U mnie to było pół roku z C++, pół roku z C Sharpem, pół roku z JS no i gdzie tutaj jest tak naprawdę miejsce na taką realną praktyczna prace i przenoszenie wartości? Warto o tym pamiętać i promować takie zachowania.

Tak, powiedziałeś właśnie o tym dzieleniu się wiedzą, o znajdowaniu materiałów w internecie, z których możemy się uczyć, jest tego mnóstwo tak naprawdę, można powiedzieć, że ta wiedza leży, wystarczy ją podnieść, w praktyce nie jest to takie, może proste, bo może się okazać, że tej wiedzy jest za dużo i nie wiadomo co wybrać, ale to trochę inny temat.

Natomiast chciałem Cię zapytać o to właśnie, gdzie szukać tych materiałów, jakie może typy materiałów bym w ogóle polecił w temacie poszerzania horyzontów w IT? Może, z czego Ty sam korzystasz?

Kiedyś postanowiłem tak bardziej precyzyjnie wyglądać z całym tym zdobywaniem wiedzy u mnie, bo są różne typy osób i są różne modele zdobywania wiedzy. W moim przypadku zobaczyłem, że przez te moje działania rysuje się taki warstwowy model zdobywania wiedzy. Ja to rozumiem tak, że mamy takie dwie osie. Po pierwsze oś związana z tym, jak szeroko podchodzimy do zdobywania wiedzy i tutaj bardzo przydają się agregatory typu Twitter albo na przykład Y Combinator, czyli miejsca, gdzie po prostu społeczność wrzuca linki, które możesz poczytać. Pod tymi linkami jest dyskusja. Czasami wartościowa, czasem nie. Ogromnym plusem tego typu narzędzi, czyli agregatów, jest to, że tej wiedzy jest tam po prostu cała masa.

Natomiast przez to, że tej wiedzy jest tam cała masa, płacimy jakąś cenę. Znaczy, nie możemy wejść głęboko w te tematy. Po prostu fizycznie nie byłoby na to czasu. W pewnym momencie musimy zacząć te kierunki precyzować. Ja ten model dlatego nazywam warstwowym, bo u mnie to się zaczyna od agregatorów właśnie od na przykład Y Combinatora, albo Twittera, a następnie poprzez osoby, które się tam pojawiają, schodzimy niżej. Kolejny taki poziom, to są na przykład blogi. Tych blogów jest kilka. Ostatnim takim blogiem, na którego natrafiłem i którego czytam dość często to jest blog The Pragmatic Engineer. To jest blog między innymi managera Ubera i Microsoftu Gergely Orosza, Węgra o ile kojarzę. To jest osoba, która bardzo dużo pisze o tym życiu na styku świata managementu, świata biznesu, produktu i tez świata software development, bo to jest osoba, która wyszła z takiego mocnego technicznego backgroundu.

Oczywiście jak zejdziemy z poziomu agregatów na poziom blogów, to tutaj pojawia się jakaś większa inwestycja czasowa, bo musimy wytrzymać trochę więcej, te pozycje są dłuższe, pojawiają się rzadziej, ale też często ta wiedza będzie tam bardziej precyzyjna.

Jeśli zejdziemy kolejny poziom niżej, czyli zaczniemy inwestować coraz więcej czasu i zaczniemy tak się bardziej sprecyzować, to tutaj pomocne też są blogi firmowe, które pasują nam na przykład do takiego typu, które tworzą produkt, który nas po prostu interesuje albo blogi firmowe, których struktura po prostu nam pasuje. Blogi firmowe takie jak, chociażby blog Zalando, blog Netflixa, Facebooka. Na tym ostatnim takich konkretnych, bardzo konkretnych blogów, postów technicznych nie ma zbyt wiele, ale na przykład i na Zalando i na Netflixie tych postów znajdziemy sporo i te same firmy produktowe również wypuszczają mnóstwo prelekcji, które znajdziemy na YouTube. To już są takie inwestycje czasowe rzędu godziny, półtorej godziny, ale ta wiedza tam jest naprawdę ciekawa i wartościowa.

Myślę, że też od ostatniego kwartału, może dwóch wracam do takich dwóch postaci jak Uncle Bob i Martin Fowler i do ich blogów. Tut też był w pewnym sensie powrót do przeszłości. Na studiach były to osoby bardzo często wspominane przez wykładowców, przynajmniej przez tych, którzy wiedzieli, na czym ta branża polega. Oczywiście zadziałał jakiś tam baja związany z tym, że wiem już wszystko, nie muszę czytać, sorry, że to powiem, starych dziadków, którzy pracowali pięćdziesiąt lat temu, tymczasem się okaże, że im więcej pracuję, tym te materiały i Uncle Boba i Martina Fowlera bardziej do mnie przemawiają, bo widzę, jak bardzo uniwersalna wiedza to jest.

To nie są może blog posty na niesamowicie wyglądających stronach. To nie są błyszczące blog posty, ale to jest mega mocne mięso. Wzorce projektowe, praktyki, dobre i złe strony Agile, to wszystko tam się znajduje, więc zdecydowanie polecam. Oczywiście książki, jeżeli chodzi o takie stricte techniczne, najbardziej uniwersalne, to tutaj bym chyba polecił Pragmatycznego Programistę, bo to jest taka książka, która daje dość szeroki, kiedyś przyszło mi do głowy, że to jest taki programistyczny YouTube w formie jednej książki. Wszystko, co mówimy na YouTube, to ktoś to kiedyś kilka lat temu opisał i po prostu nie ma sensu już nic tworzyć, bo to tam wszystko jest. Pragmatyczny programista. Od czeladnika do mistrza — to jest takie miejsce, które też polecam.

Co ciekawe, jakiś czas temu ponownie sobie przeczytałem tę książkę i wiadomo, są tam jakieś rozdziały, czy podrozdziały, które są powiedzmy, z racji nazwy technologii nieaktualne, ale tak naprawdę, zaryzykuje, że z dziewięćdziesiąt parę procent tego wszystkiego jest ciągle aktualne, to się nie dezaktualizuje. Ta wiedza, takie podstawy to zostaje, warto w to inwestować czas, bo niezależnie od tego, czy dzisiaj pracujesz na front endzie, czy jutro na back endzie, a pojutrze jeszcze w chmurze, to i tak najprawdopodobniej te wszystkie podstawy gdzieś tam użyjesz i będziesz obserwował swojej pracy.

Tak, zdecydowanie. Tutaj może nie do końca mocno to podkreśliłem, ale właśnie polecałbym projektowanie całego tego procesu, zdobywania wiedzy tak właśnie dwutorowo, czyli z jednej strony poszerzamy tę bazę potencjalnych materiałów, do których wejdziemy głębiej, a z drugiej strony wybieramy sobie te naprawdę wartościowe i tam inwestujemy. Czyli ani nie polecam rezygnować z agregatorów, ani nie polecam skupiać się na opasłych, kto ma już wiedzę w postaci książek, bo to i to jest do czegoś potrzebne.

Jeśli chcemy poszerzać tę wiedzę, to Twitter jest znakomity, YouTube jest znakomity, trzeba poszukać. Jak już znajdziemy osoby, które chcemy śledzić, które mówią ciekawie, wartościowo i regularnie, no to możemy przechodzić na te bardziej kosztowne czasowo inwestycje, takie jak właśnie książki, czy dłuższe prelekcje.

Jeszcze może taki tip od siebie tutaj dam, że osobiście preferuję tę wiedzę konsumować w takich małych, ale regularnych cząstkach. Czyli na przykład codziennie starać się coś tam przeczytać, zaznajomić się z czymś, bo takie odkładanie sobie, że ok, przeczytam w roku bodajże dziesięć tych książek technicznych, to zazwyczaj kończy się tym, że albo nam się to po prostu nie udaje, albo faktycznie poświęcamy jednorazowo całkiem dużo czasu, żeby tę książkę przeczytać, potem musimy sobie odpocząć, ta wiedza tak naprawdę nieużywana najczęściej gdzieś tam ginie, więc najlepiej sprawdza się codzienne, regularne podejście w kawałeczkach.

Zdecydowanie tak. Jak to mówiłeś, to mi tutaj też przyszła do głowy taka myśl, że bardzo często nawet nie jestem w stanie podawać nawet tych źródeł, z których korzystam, bo po prostu przy takim regularnym podejściu, to cały ten proces wygląda tak, że patrzysz na nagłówek. Jeśli nagłówek Cię zainteresuje, to czytasz treść, notujesz i zamykasz. To nie jest tak, że musisz się koniecznie skupiać na tym, że na stronie x, wiadomo, że na medium jest mnóstwo postów technicznych, czy na blogach, które można prowadzić na medium, ale myślę, że i łatwo to znaleźć i tez nie jest kluczowe, żeby to pamiętać. Bardziej chodzi o ten proces, chodzi o to, żeby na przykład na Twitterze zebrać grupkę ludzi, których po prostu warto śledzić, osoby z większym doświadczeniem od nas, które pracują w ciekawych formach i na tej podstawie budować sobie taki proces, o którym Ty powiedziałeś.

To też nie jest takie bingo, gdzie musimy odkreślić dziesięć blog postów i piętnaście podcastów. Raczej warto być po prostu podpiętym do tego wszystkiego.

Właśnie. To ma takie dwa, według mnie plusy nawet dodatnie. Po pierwsze, jeśli ileś tam razy usłyszysz o jakimś koncepcie technologii, to to Ci się gdzieś utrwali. Po drugie, jeśli masz ten dopływ wiedzy z różnych stron, to jesteś w stanie wiązać sobie pewne rzeczy i to też po prostu łatwiej zapamiętywać, łatwiej utrwalać pewne rzeczy, jeśli faktycznie jesteśmy w stanie to skojarzyć, czy mieć jakąś analogię do czegoś, jakiegoś konceptu, który wcześniej poznaliśmy, zapamiętaliśmy.

Jasne, dokładnie tak.

Tak sobie myślę, że lubimy o sobie mówić jak o software engineer. Tam jest ten inżynier w nazwie tego zawodu. Jak sobie myślę o inżynierze, to przychodzi mi na myśl, że to jest taka osoba, która jest pragmatyczna, skuteczna i Ty właśnie o tych dwóch filarach takiego podejścia inżynieryjnego mówisz w swoim kursie Level Up. Mówisz, że to są takie dwie składowe skutecznego pracownika umysłowego.

Chciałbym Cię podpytać, jak tutaj te rzeczy, czy też skupienie się na tych dwóch właśnie rzeczach może spowodować, że wchodzimy na wyższy poziom programowania?

Myślę, że to wszystko sprowadza się do świadomości. Zaraz powiem konkretnie, o jakie dwa filary chodzi, ale cały czas będziemy tak naprawdę krążyć wokół tego tematu świadomości. To znaczy, im więcej tych obszarów potencjalnych do odkrycia odkryjesz, tym większa pula możliwości, jeśli chodzi o Twój rozwój, kierowanie kariera i tak dalej.

Istnieje taki mit, na który gdzieś tam się łapiemy, że świat programowania to jest wiedza techniczna i zostawanie tym ninja. Natomiast są badania, które jednoznacznie pokazują, że badani software engineerowie to są dość standardowi pracownicy umysłowi, których wiedza i rozwój opiera się o filar task performance’u, czyli takiej wydajności zadaniowej. Tej wydajności, która pasuje do naszego opisu stanowiska pracy, ale też filaru o nazwie contextual performance, o którym bardzo często zapominamy.

To jest taki filar, który dotyczy wszystkiego tego, czego nie znajdziemy w ogłoszeniu o pracę, a jednak się tego od nas wymaga. To jest taka ciekawa sprawa. Nikt w ogłoszeniu nie napisze, że powinieneś pomagać innym w code review, albo zazwyczaj nie napisze, albo będzie to gdzieś tam w domyśle traktowane, ale jednak będzie ten proces code review i nie wyobrażam sobie, że programista stanąłby okoniem i stwierdził, że nie interesuje go taka aktywność, albo na przykład w ogłoszeniu o pracę może być napisane, że szukamy front end developera, natomiast jak dołączysz na to stanowisko, to okazuje się, że w firmie są regularne prezentacje i talki i w pewnym sensie oczekuje się od Ciebie, żebyś na takim wydarzeniu wystąpił, przygotowując swoją prezentację, co oczywiście od razu pociąga za sobą wymóg na przykład opanowania public speakingu, jakiejś umiejętności skutecznego przemawiania, gromadzenia myśli i przekazywania tej wiedzy innym.

Te badania na temat tego, czym jest tak naprawdę praca umysłów, a nie ma tam bardzo mocnych definicji, bo też trzeba stwierdzić, że mamy tu po prostu problem tego, że nie mówimy o pracy w fabryce, nie mówimy o czymś, co jest bardzo łatwo zmierzyć i też na pewno zgodzisz się, że wydajnością programisty nie zmierzymy liczbą dowiedzionych tasków, ale jednak powoli to wszystko zaczyna się precyzować. Czyli te dwa filary to jest to, o czym powinniśmy myśleć. Z jednej strony solidne fundamenty techniczne, od tego nie da się uciec, ale z drugiej contextual performance, bo pracujemy w zespołach, mamy wokół siebie innych ludzi, a ludzie, jak to ludzie, w przeciwieństwie do komputerów, są dość nieprzewidywalni, mają emocje, mają swoje humory, lepsze gorsze dni. Niektórzy lubią dane podejście do rozwiązania problemu i daną technologię, niektórzy nie lubią. Jedni są konfliktowi, drudzy są mniej konfliktowi. W tym wszystkim musimy się poruszać.

Oczywiście przez sam fakt osiągania jakichś rezultatów w pracy, pojawia się też presja. Ta presja i radzenie sobie z presją, z organizacją zadań, to też jest coś takiego niejawnego, o czym nie napisze żaden pracodawca w ogłoszeniu o pracę takim rozsądnym, bo ja nie mówię o tych banałach, w stylu młody, dynamiczny zespół i poradzisz sobie pod presją czasu, bo wszędzie ta presja jest. Więc w zasadzie, po co to pisać, a tak naprawdę fajnie, jakbyś sobie radził. To są wszystkie takie ukryte umiejętności, które zostały przebadane, chociażby na podstawie obserwacji stanowiska kontrolerów lotów, bo to też jest praca, która wydawałaby się, jest twarda, ale ludzie siedzą ze sobą, jest bardzo duża presja, muszą wchodzić w interakcje. Tam wyszło wprost, że po prostu osoby pracujące na tym stanowisku nie są oceniane jedynie pod względem tego, jak dobrze zarządzasz samolotami, ale również tego, jak dobre relacje zbudujesz sobie w grupie, jak się zachowujesz w momencie popełnienia błędu, czy jesteś w stanie poprosić kogoś o pomoc, bo czasami jakaś sytuacja może Cię, po prostu, mówiąc brzydko, dojechać, czyli nie poradzisz sobie z jakąś sytuacją. Na tej podstawie taki wniosek zbudowano.

Mamy te dwa filary, ten contextual performance, który jest często pomijany, a tak naprawdę, jak wejdziemy w ten świat, to pojawia się przed nami cała pula możliwości okazji do poszerzenia wiedzy i pojawia się taka niejawna ścieżka wchodzenia na kolejny poziom.

👉 Czytaj dalej na: https://porozmawiajmyoit.pl/poit-112-jak-przejsc-na-kolejny-poziom-w-programowaniu/

kkempin’s dev blog

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store