POIT #112: Jak przejść na kolejny poziom w programowaniu?

Witam w sto dwunastym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest to jak przejść na kolejny poziom w programowaniu.

Dziś moim gościem jest Przemek Smyrdek – programista z ponad 7 letnim doświadczeniem głównie z obszaru frontendu. Lider zespołów, mentor, osoba prowadząca warsztaty. Dzieli się wiedzą na blogu czy kanale na YouTube. Współtwórca Przeprogramowanych. Twórca kursów “Opanuj JavaScript” i “LevelUp”. Przedstawia siebie jako osobę która pomagam programistom rozwijać kompetencje techniczne i umiejętności miękkie.

W tym odcinku rozmawiamy o:

  • czym jest kolejny poziom w programowaniu?
  • radach dla osób, które chcą zaplanować swój rozwój
  • czy wychodzenie ze strefy komfortu jest niezbędne?
  • jakie darmowe materiały można polecić by poszerzać swoje horyzonty w IT?
  • skuteczności i pragmatyczności
  • czy ścieżka managerska to zawsze najlepszy wybór?
  • czego oprócz umiejętności technicznych jeszcze potrzeba?
  • na ile trzeba zrozumieć biznes i sprzedaż?
  • czy dzielenie się wiedzą jest ważne?
  • czy zdrowie, samopoczucie, sen, dieta i ruch to obszary o których również należy pamiętać?
  • czy wiedza domenowa popłaca?
  • od czego zacząć przechodzenie na wyższy poziom w programowaniu?

Subskrypcja podcastu:

Linki:

Wsparcie na Patronite:

Wierzę, że dobro wraca i że zawsze znajdą się osoby w bliższym lub dalszym gronie, którym przydaje się to co robię i które zechcą mnie wesprzeć w misji poszerzania horyzontów ludzi z branży IT.

Patronite to tak platforma, na której możesz wspierać twórców internetowych w ich działalności. Mnie możesz wesprzeć kwotą już od 5 zł miesięcznie. Chciałbym oddelegować kilka rzeczy, które wykonuję przy każdym podcaście a zaoszczędzony czas wykorzystać na przygotowanie jeszcze lepszych treści dla Ciebie. Sam jestem patronem kilku twórców internetowych i widzę, że taka pomoc daje dużą satysfakcję obu stronom.

👉Mój profil znajdziesz pod adresem: patronite.pl/porozmawiajmyoit

Pozostańmy w kontakcie:

 

Muzyka użyta w podcaście: „Endless Inspiration” Alex Stoner (posłuchaj)

Transkrypcja podcastu

To jest 112. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o tym, jak przejść na kolejny poziom w programowaniu.

Przypominam, że w poprzednim odcinku rozmawiałem o .NET.

Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/112.

Ocena lub recenzja podcastu w Twojej aplikacji jest bardzo cenna, więc nie zapomnij poświęcić na to kilka minut.

Sponsorem dzisiejszego odcinka jest platforma rekrutacyjna Solid Jobs. Jeśli szukasz pracy w IT, koniecznie odwiedź adres SOLID.Jobs. Znajdziesz tam nie tylko oferty z widełkami wynagrodzeń. Jeśli aktualnie nie myślisz o znalezieniu nowej pracy, to koniecznie zapisz się na Job Alert. Otrzymasz regularne wiadomości e-mail z zestawieniem ofert, które mogą Cię zainteresować. Jeśli w swojej pracy nadal korzystasz z SVN-a, to koniecznie odwiedź Solid Jobs.

Nazywam się Krzysztof Kempiński a moją misją jest poszerzanie horyzontów ludzi w branży IT. Środkiem do tego jest między innymi ten podcast.

Zostając patronem na platformie Patronite możesz mi w tym pomóc już dziś.

Wejdź na porozmawiajmyoit.pl/wspieram i sprawdź szczegóły.

Jednocześnie bardzo dziękuję moim obecnym patronom.

Teraz życzę Ci już miłego słuchania.

Odpalamy!

 

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. 

 

Teraz weźmy taki trochę inny, kolejny poziom. Czyli wybraliśmy sobie taką osobę, która powiedzmy, rozpoczyna karierę, poświęca średnio sześć, pięć lat zgłębiając te techniki i różne technologie twarde i dochodzi do pozycji senior developera, dajmy na to. Niestety zderza się wówczas bardzo często z sufitem. To też jest często problem dla pracodawcy, który ma osobę, która tak naprawdę jest u szczytu awansu, możemy mówić jakimś tak principale developerze, architekcie, ale powiedzmy, że ten senior developer wyznacza nam jakichś tak sufit. No więc, co robi ten biedny pracodawca, myśli sobie, że chce utrzymać, dać rozwój temu programiście, więc zrobi z niego managera. Bardzo często, można dyskutować, czy właściwe podejście. 

Chcę Cię zapytać, czy uważasz, że to jest dobry kolejny poziom, czy to jest dobry kolejny poziom, czy to jest w ogóle alternatywa?

 

Po pierwsze pozwoliłbym sobie na delikatne niezgodzenie się z Tobą. To znaczy, wydaje mi się, że pomiędzy stanowiskami seniorskimi, a principale software engeenierami jest jednak spora różnica. Wydaje mi się, że ten sufit technologiczny często kończy się na seniorze, ale wszystkie te stanowiska, o których mowa dalej, czyli jakieś lead engineer, principale software engineer, to już są stanowiska, które wymagają od Ciebie czegoś więcej. 

Patrząc po naprawdę dużych fabrykach i przedsiębiorstwach, takich, chociażby, jak Microsoft, niewielu jest programistów w te miejsca, ale również dość jasno można stwierdzić, że to nie są miejsca jednoznacznie kojarzące się z byciem managerem. To znaczy dalej jesteś na ścieżce technicznej, masz skille nie techniczne, zaczynasz być jakimś mentorem, osobą, która promuje framework, albo jakąś technologię, albo jesteś jakimś dev advocate, czy dev avocado, jak to czasami się również nazywa, ale to jest właśnie ta ścieżka techniczna. Co ja mógłbym tu powiedzieć? Myślę, że ważne jest zadanie sobie znowu takiego pytania, o którym powiedzieliśmy wcześniej, czyli co do Ciebie pasuje i jak cię ocenia środowisko. Jeśli w moim przypadku, w pierwszej firmie tak się okazało, że zupełnie nie przychodziło mi to do głowy, żeby prowadzić zespół, a w pewnym sensie mi to zaproponowano, to okazało się, że przez to moje zachowanie gdzieś tam reprezentuję te postawy, które w pewnym sensie mogą do mnie pasować, nawet jeśli nie jestem tego świadomy. 

Więc jeśli środowisko widzi w Tobie managera, to może coś w tym jest i na pewno jako programista nie odrzucałbym tej ścieżki, bo ona jest ciężka, trudna, ale jest kolejnym krokiem. Może nie jest to, myślę, że do końca fair powiedzieć, że jest to kolejny krok, ale na pewno znajdziesz tam sytuacje, które będą od Ciebie wymagać, chociażby opanowania swojego czasu, opanowania emocji, podniesienia swoich umiejętności pracy w grupie, budowania relacji, czasami wpływania na innych stety, niestety. 

Jest to jakiś kolejny taki krok. Ale na przykład powiedzmy, że nie masz takiej sytuacji, bo może się tak zdarzyć, że w firmie pracujesz dobrze, manager już jest, po prostu nie ma budżetu na kolejne stanowisko, to wtedy nie zrezygnowałbym na siłę i nie robiłbym z siebie takiego managera na siłę, pamiętał po prostu o tym, że są firmy większe, no i to jest trochę tak, że w tej układance dwie strony muszą do siebie pasować. Jeśli w danej firmie nie ma miejsca poza stanowiskiem seniorskim, a Ty nie widzisz siebie na ścieżce managerskiej, to myślę, że jest sporo korporacji, które jakiegoś tam właśnie, kogoś w kierunku principale, albo senior software engeeniera dwa, będą chciały z Ciebie zrobić. Może nie od razu, ale myślę, że jest to możliwe. 

Widać to po tych organizacjach w dolinie krzemowej, programista z bardzo mocną wiedzą techniczną, który dodatkowo potrafi się wypowiadać, potrafi rozmawiać z innymi, jest otaczany bardzo dużym szacunkiem i to jest coś, co wydaje mi się, nie jest aż tak popularne u nas, bo u nas jest takie podejście, o którym trochę powiedziałeś, że ten manager gdzieś tam czeka, a jak nie czeka, to masz problem. Jednak te osoby, o których wspominaliśmy wcześniej, czy chociaż Uncle Bob, Martin Fauler, to są konsultanci biznesmeni, ale to są też osoby, które po prostu przyznają się do bycia programistami w wieku tam x lat. Więc na pewno ta ścieżka jest, warto porozmawiać z pracodawcą, warto rozpoznać sytuacje w innych firmach, no i dopiero wtedy podejmować decyzje, wtedy się decydować na jakiś kierunek.

Trudno mi powiedzieć, czy któraś ścieżka jest lepsza, czy gorsza, najgorsze jest chyba robienie czegoś przypadkowo. Zupełnie nie zadałeś sobie wysiłku sprawdzenia o co mi tak naprawdę w pracy chodzi, zupełnie nie porozmawiałeś z managerem, ze swoim kierownikiem, więc zaczynasz podejmować jakieś decyzje, bo to jest wtedy no pewnie szybko przynoszące negatywne rezultaty. po prostu ta Twoja kariera zaczyna wyglądać przypadkowo, zaczynasz się frustrować, bo pojawiają się jakieś sytuacje, o których nie pomyślałeś. Znowu ta świadomość, ten motyw przewodni tej naszej rozmowy, im więcej tej świadomości, tym będzie Ci lepiej.

 

Tak, myślę, że ta świadomość jest istotna. Istotna też jest taka praca nad tymi umiejętnościami, bo nikt nie rodzi się managerem sam z siebie. Być może ma jakieś predyspozycje, wcześniejsze uwarunkowania, ale ciągle jest to cały czas praca nad całym szeregiem tych dodatkowych umiejętności. 

Tu chciałbym Cię zapytać o te dodatkowe rzeczy, dodatkowe umiejętności spoza tego parasola technologicznego, które według Ciebie mogą być ważne, potrzebne w takiej codziennej pracy, niekoniecznie nawet będąc managerem dużego zespołu, ale w ogóle rozwijając się technologicznie, wchodząc na ten kolejny poziom. Co jeszcze oprócz frameworka, języka może nam się przydać?

 

Ja tutaj zawsze lubię sobie przywołać taką sytuację, gdzie zaczyna się projekt i przez ten projekt przechodzimy jako programiści, bo niezależnie od tego, w jakiej firmie pracujesz, to dotyczy 100% osób, które tego podcastu będą słuchać i są programistami. Na każdego z nas jakiś projekt czeka. Ten projekt jest o tyle ciekawy, że projekt nas uczy, jeśli będziemy zachowywać pozycję otwartą. 

Czego może nas nauczyć projekt? Powiedzmy, że pojawia się jakiś projekt na horyzoncie, my jesteśmy dobrze rozeznani we frameworku x, powiedzmy angular, natomiast gdzieś zewnątrz zaczynają się pojawiać sygnały, że warto byłoby tutaj poeksperymentować z Reactem. Albo w ogóle nasz kolega jest bardzo mocnym zwolennikiem reacta i co zrobisz? To nie jest problem, który rozwiążemy na takiej płaszczyźnie czysto technicznej, bo trzeba ze sobą niestety pogadać i trzeba w taki sposób pogadać, żeby móc na siebie patrzeć w kolejnych dniach, jak ten projekt będziemy realizować. 

Czyli od razu pojawia się, chociażby potrzeba argumentowania, potrzeba negocjowania i też potrzeba zachowywania takiej otwartości względem innych. Może się okazać, że programista, z którym rozmawiamy, spędził ostatnie dwa, trzy tygodnie na bardzo mocnej analizie konkurencyjnego frameworka i jeśli my teraz utniemy te dyskusje w taki bardzo ostry sposób, to wykazujemy się brakiem szacunku. Pogarsza się nastroje w zespole, nie doceniliśmy tego wysiłku, który ta druga osoba włożyła, żeby tę inną technologię wprowadzić i atmosfera się pogarsza. Więc na pewno takie kwestie jak negocjowanie i sytuacje, w których mamy przeciwne zdanie, to czeka na każdego programistę. 

Tutaj Linus Torvalds mówi „Show me the code. Stop talking, show me the code.”. Może faktycznie to tak jest, że nie ma co dyskutować, ale nawet to „Show me the code”, wiele razy spotkałem się z sytuacją, gdzie nawet ten sam fragment kodu był oceniany w bardzo różny sposób. Jedna osoba robiła pod requesta, nawet nie skomentowała jakiegoś fragmentu, bo po prostu nie widziała tam nic złego i myślę, że to dotyczy większości z nas. Pojawiła się jakaś osoba z zewnątrz, robiła review i zgłaszała dwadzieścia komentarzy. To nie mówię komentarzy na zasadzie takiej, że tu nie ma średnika, tylko że to jest fundamentalnie złe i co wtedy. 

Na pewno sam początek projektu, to, kiedy zaczynamy planować, jeśli przechodzimy do realizacji, to też teraz można powiedzieć, że w projekcie pojawiają się jakieś role project managerów, osób, które są odpowiedzialne za dowiezienie tego projektu, ale na przykład w wielu firmach w dolinie krzemowej nie ma takiej roli i to na programistach ciąży odpowiedzialność, żeby ten projekt dowieść. Programistach we współpracy z na przykład product ownerem, product managerem. Więc tutaj pojawia się na przykład potrzeba na przykład komunikowania ryzyka i takiego zarządzenia w górę, to znaczy, sprawiania, żeby nasz manager spał spokojnie, żeby nie musiał codziennie pytać, jaki jest status projektu i żeby zachować taką transparentność. Więc na takim poziomie egzekucji, tutaj również jako programiści mamy ogromną płaszczyznę, w której możemy się szkolić. Zabawne jest to, że jak powiem jeszcze o kilku takich płaszczyznach, to prawdopodobnie opiszemy jakiegoś przyszłego managera, ale de facto tak to często wygląda, że jeżeli dbamy o te wszystkie płaszczyzny, to naturalnie zaczynamy w takie kierunki leadershipowe iść. 

Co dalej? Myślę, że ogromnym plusem dla programisty byłoby zbliżenie się do biznesu, zrozumienie języka biznesu, zrozumienie metryk, zrozumienie tego, czym są KPI i czym KPI różnią się od OKR, zrozumienia problemów biznesu i niereagowanie na takiej zasadzie, że klient chce nam zrobić krzywdę, tylko razem z klientem chcemy wypracować jakieś rozwiązania za które nam zapłaci.

Znowu, jeśli mamy szczęście i na przykład na takie biznesowe podejście trafimy stosunkowo wcześnie, na przykład na uczelni ktoś nam o tym powie, to ok, ale mogę sobie wyobrazić software house, gdzie ten biznes jest po prostu ukryty i jest daleko od programistów, bo programiści są od tego, żeby pisać kod. Wtedy mamy problem, więc myślę, że to bycie blisko biznesu, albo walka o to, żeby być blisko biznesu. To jest bardzo ważna rzecz.

Jeszcze jedna sprawa, która mi również przychodzi do głowy, to jest takie poczucie odpowiedzialności za to, co robimy. Taki Extreme ownership, zgodnie z książką Jacko Willinga, czyli takie poczucie tego, że projekt się nie dziej nam, tylko, że my po prostu jesteśmy szefami tego projektu, my się znamy, my mamy ten skill techniczny i to od nas zależy, jak zostanie dowiedziony, jak rozwiązujemy konflikty. Już powiedziałem wcześniej, jak komunikujemy poszczególne ryzyka, czyli cały taki zestaw umiejętności wykonawczych, taki executive programmer, myślę, że to jest taka suma postaw, taki zestaw postaw, o które warto walczyć, bo tak jak powiedziałem, ludzie wokół nas sprawiają, że cała ta gra staje się trochę bardziej skomplikowana i trzeba się na to przygotować. 

Oczywiście są osoby, które gdzieś tam do końca swojej kariery trzymają się te ścieżki technicznej i takich ról, które nie wymagają od nich takich postaw i spoko, każdy ma inne priorytety. Ale wydaje mi się, że w całej tej fali firm produktowych i biznesów, które będą szukać product engineerów, no to się robi powoli takie niezbędne. To jest taki zestaw umiejętności, od których coraz trudniej będzie uciec po prostu.

 

Tak, zgadzam się absolutnie. Powiedzieliśmy o rozwoju kompetencji twardych, technicznych, powiedzieliśmy o angażowaniu się w różne aspekty, powiedzmy projektu, biznesu wokół projektu też w zespół, w pełnej odpowiedzialności za ten zespół. Jest jeszcze coś, co według mnie jest ważne i też Ty dużo o tym mówisz w swoim kursie i w social mediach. mianowicie jest to temat dzielenia się wiedzą. Temat mi szczególnie bliski, bo ostatnio zaczynam się wypowiadać na temat marki osobistej. To się też wiąże, powiedzmy. Moje pytanie do Ciebie – dlaczego według Ciebie warto dzielić się wiedza, angażowaćć się? Często propublico bonów takie różne inicjatywy jak to nam może pomóc w wejściu na ten wyższy poziom w programowaniu?

 

Dla mnie to całe dzielenie się wiedzą, to jest takie praktyczne przełożenie tego powiedzmy extreme owner shipu, na tą naszą pracę. Pytanie, czy kariera i rozwój ma się dziać przypadkowo Tobie, ma gdzieś przychodzić z zewnątrz, ma zależeć od tego, jaki rekruter akurat będzie skłonny zaprosić Cię dalej, czy jednak chcesz wskoczyć na to siedzenie kierowcy i chcesz tym sam pokierować. Wiem, że to może brzmieć strasznie i tam każdy z nas dokłada do tego powiedzmy różne wartości, idee, ja po prostu też lubię dzielić się wiedzą ot, tak, dla samego faktu dzielenia się wiedza, gdzieś taka rola nauczyciela, nawet w szkole nauczyciela była czymś, w czym się widziałem. Myślę, że na końcu to wszystko się sprowadza do takiego brania odpowiedzialności za to, gdzie się jest, jakie się ma możliwości przed sobą. 

Dlaczego tak jest? No bo praktycznie przez każdy aspekt tego całego procesu dzielenia się wiedzą, coś zyskujemy. Przede wszystkim jak chcemy się podzielić wiedzą, to musimy tę wiedzę mieć. A jak tę wiedzę mieć? No musimy się czegoś nauczyć. Tutaj mamy pierwszy taki side effectu. Po drugie, jeśli już się czegoś nauczymy, to pewnie też zgodzisz się ze mną, nie wystarczy tylko mieć wiedzę w głowie, ale też trzeba umieć ją sprzedać, umieć ją przekazać, poukładać. Więc znowu dzieląc się wiedzą, uczymy się całego takiego procesu komunikowania się z innymi w taki sposób, żeby ten nasz komunikat był zrozumiały. 

Mamy, powiedzmy, projekt, z którego wyciągnęliśmy jakieś wnioski i w tym projekcie było pewnie dwadzieścia sytuacji, o których warto napisać, ale musimy to skontrolować. Musimy zredukować te wszystkie potencjalne tematy, które przychodzą nam do głowy i musimy wybrać sobie jeden. 

Czyli przez sam taki proces tego ograniczania, o czym chcemy mówić, znowu uczymy się bycia bardziej precyzyjnymi, wyrażania się w jaśniejszy sposób. Znowu wpływa to pozytywnie na nasz rozwój. 

Jeśli teraz mamy możliwość na działania związane z narrow sharingiem w takim kontekście firmowym, to jest też jeszcze ciekawsza sytuacja, po pomagamy nie tylko sobie, ale też firmie, w której pracujemy, a przez to znowu pomagamy sobie. To jest jakby taki paradoks, ostatnio usłyszałem, że to jest jedyna aktywność powiedzmy, w programowaniu, która polega na tym, żeby zaspokajać swoje ego i jakby taką potrzebę promowania się czasami, wychodzenia przed szereg, która jakby przynosi bardzo pozytywne, obiektywne korzyści. Nie jest odbierana negatywnie. 

Jak pobierasz jQuery za darmo, to Twojego posta też przeczyta ktoś za darmo, ale zyskujesz na tym, że budujesz rozpoznawalność, zyskuje osoba, która to czyta, więc kolektywnie branża idzie do przodu i to ego jest zaspokojone, bo często chodzi o to, że fajnie jest, jak to nazwisko pojawi się na jakimś znanym blogu dla inżynierów, jeśli jakiś rekruter wspomni, że widział to, co robiłeś. Czyli to jest taki bardzo ciekawy proces, który zaczyna się często od czegoś niepozornego, tak jak w moim przypadku kiedyś to była po prostu chęć nauki, a koniec końców sprowadza się do tego, że i musisz popracować nad regularnym publikowaniem treści, nad układaniem swoich myśli, na tym, żeby nauczyć się zarządzać czasem i wziąć tę swoją karierę pod kontrolę. To znaczy nie czekać na to, że coś się wydarzy przypadkowo, ale mieć w pewnym sensie kontrolę. 

Oczywiście ta kontrola nie jest absolutna i obiektywna, tylko to jest takie poczucie tego, że mamy trochę tej kontroli więcej, ale na pewno mamy jej więcej. Idziemy na rozmowę, chociażby przez ta działalność na przeprogramowanych już kilkukrotnie zauważyłem, że idę na rozmowę i rekruter mówi, że czytał taki post, taki post i widział portfolio i taki film. Wydaje mi się, mówiąc tak bardzo egoistycznie, już tamte pięć punktów w tym procesie zdobywam. Rozmowa się nie zaczęła, ale te pięć punktów już zdobyłem. 

To jest taki bardzo ciekawy proces, który się spłaca na bardzo wielu płaszczyznach, który jest też angażujący, ale uważam, że warto. W pewnym sensie to jest taka aktywność, która jest bardzo mocno skrojona z tym naszym zawodem programisty i też tak wygląda naturalnie. Wydaje mi się, że troszkę to też wynika z tego, że ludzie też mają taką naturalną tendencję do opowiadania różnych historii i dzielenia się wiedzą w taki sposób, więc jak to podepniemy pod ten nasz zawód programisty, to trafiamy w jakieś nasze pierwotne instynkty, że ludzie jednak pisali te książki, rysowali te malowidła na ścianach, a teraz tworzą te blogi techniczne i chcą się nawzajem uczyć. 

Myślę, że to jest bardzo wartościowa aktywność.

 

Tak, zdecydowanie. Myślę, że tutaj fajnie to ująłeś, że prócz takich altruistycznych pobudek, bo takie dzielenie się wiedzą często za darmo, jakby nie było, wiemy obydwoje, ile to wymaga czasu, zaangażowania i tez zebrania tego w odpowiedni sposób, to też jest jak gdyby kwintesencja, żeby tę wiedzę w spójny fajny sposób zebrać, zanim się przekaże dalej.

Myślę sobie, że prócz tych altruistycznych pobudek dużo zyskujemy, chcąc, albo nie chcąc w przeróżny sposób. Tak jak powiedziałeś albo na rozmowie rekrutacyjnej, albo dostając jakąś fajną wiadomość nawet gdzieś na social mediach, że to się komuś przydało. To też nadaje sens temu, co robimy, a dwa, czasem może być odskocznią, czy taką próbą uchronienia się przed wypaleniem, przed taką szarością dnia codziennego w na przykład kodowaniu, robimy coś jeszcze, co nam głowę w innym kierunku przekieruje. 

Mnóstwo tych plusów faktycznie jest. Dodałbym jeszcze od siebie, bo często jestem o to pytany, czy trzeba być już super ekspertem, żeby się tą wiedzą zaczynać dzielić. Ja absolutnie uważam, że nie, jeśli jestem tylko o krok do przodu przed kimś, to nawet to, w jaki sposób ja mówię o danym problemie, czy rozwiązaniu, może być bardziej przystępne dla tej osoby, niż takie trochę Ex Cathedra z piętnastoletnim doświadczeniem wyjaśniając.

 

No właśnie to jest, powiedzmy to, o wynosimy bardzo często z uczelni, czyli cały ten set up, gdzie stajemy przed komisją, przed kimś, kto jest większy rangą, większy statusem i całe to dzielenie się wiedzą, kojarzy się jednoznacznie z presją, z egzaminami ustnymi, z ciśnieniem, czymś, co robimy wbrew własnej woli. Zazwyczaj znajdzie się ktoś, powiedzmy w tym kontekście rzeczywistym, kto po prostu wie mniej od nas, mówiąc już tutaj konkretnie o programistach i po prostu doceni każdą cząstkę wiedzy, która podzielimy się za darmo. 

Ja może tak troszkę poszedłem pod prąd, mówiąc o takich pobudkach egoistycznych, ale jakby myślę, że mówimy o takich pobudkach altruistycznych, to tych materiałów jest dość w internecie, bo o tym naprawdę sporo osób mówi, ale jeszcze warto tutaj podkreślić czysto osobiste pobudki, związane z tym, że po prostu robiąc dobrze innym, dzieląc się tą wiedzą, robisz sobie dobrze na koniec końców, powiem tak brzydko. To nie jest tak, że pisząc merytoryczny post i zyskując coś, Ty tak naprawdę robisz jakiś fejk i tak naprawdę oszukujesz. Często się nie da podważać tego, że materia jest merytoryczny, więc jeśli podzielisz się tym obiektywnie merytorycznym materiałem, to Ty zyskujesz, zyskuje Twoje otoczenie, Twoja branża. 

Myślę, że to jest też często coś, o czym na przykład firmy zapominają. Są firmy, które zatrudniają dziesiątki seniorów. Ten potencjał jest naprawdę ogromny, a jednak w takie aktywności się nie zapędzają. Myślę, że ten potencjał to też jest coś takiego, co po prostu zacznie wybuchać w pewnym sensie, bo firmy sobie uświadomią, że to nie jest tylko tak, że ja się ścigam z moją konkurencją o to, kto wytworzy na rynku lepszy produkt w bardzo wąskim zakresie, w bardzo wąskim wertykale, ale również chodzi o to po prostu, jak dobrych programistów zatrudniam i jak dobrych programistów mogę z innej firmy podebrać, bo to się często do tego sprowadza. Więc pchajmy ten wózek razem, zarówno prywatnie, jak i firmowo i myślę, że wszyscy będziemy na tym zyskiwać. 

 

Myślę sobie, że dużo tutaj mówimy o takim rozwoju generalnie umysłowym, nazwałbym to w ten sposób, ale wiadomo, że póki co, ten umysł w oderwaniu od ciała nie działa. Czy taki holistyczny rozwój, taki równomierny rozwój dla Ciebie, to również jest zaopiekowanie się takimi rzeczami, jakiś sen, zdrowie, sport, dobrostan cyfrowy, czy tutaj siły pokładane, czy te wkładane właśnie w te obszary dla Ciebie, to też jest wychodzenie na kolejny poziom w programowaniu?

 

Zdecydowanie tak. Pierwsze, co tutaj mi przychodzi do głowy, to jest chyba coraz większe docenianie odpoczynku i tego, co robi z nami nic nierobienie. Może to wyszło naturalnie, może nie, kilka lat temu, myślę, że czasu przy komputerze spędzałem znacznie więcej i myślę, że ten okres nauki był dużo bardziej intensywny niż teraz, ale w pewnym sensie teraz czuje, że jest taki okres przechodzenia w takie smart activities, a nie po prostu tylko intense activities. Bo po prostu widać, co z człowiekiem robi dobre wyspanie się, odpoczęcie, przerwa od komputera. 

To się może nam kojarzyć z takimi poradami od naszych rodziców, czy dziadków, żeby wyłączyć ten komputer, ale no wyłącz ten komputer. Brzmi to banalnie i często ja też się frustrowałem nieraz jak słyszałem gdzieś od rodziców, że znowu grasz w te gry. Wiadomo, o co chodzi, że to jest jakieś tam może nie do końca zrozumienie, na samym początku szczególnie, jak zaczynamy na przykład wchodzić na świat programowania, ale na końcu są takie znowu uniwersalne rady, tak jak wcześniej powiedzieliśmy o tym Uncle Bobie, który już trzydzieści lat temu pisał o czymś, co znowu branża odkrywa. 

Czyli w 100% się tutaj zgadzam, kiedyś też słyszałem taką fajną analogię, związaną z tym, że powinniśmy być jak sportowcy. Sportowcy również nie są podłączeni pod sport dwadzieścia cztery na dobę, mają te swoje okresy konkursów, wystąpień, meczów, czy czegokolwiek. Mamy to, w których ten top performance się musi pojawiać, ale tak poza tym, to masz obóz treningowy, masz plan treningowy, masz dietę, musisz się wyspać, fajnie jakbyś ograniczył na przykład używki. Oczywiście tutaj z tym jest różnie, na pewno będzie inaczej, jak pojedziemy do Włoch, gdzie alkohol jest czymś bardziej naturalnym niż w innych krajach, ale o takie rzeczy warto dbać. 

Może nie jestem bardzo tutaj roll modelem tutaj w całym tym temacie, ale mam jakieś takie małe zasady, którymi staram się podążać, począwszy od, chociażby zapewnienia sobie nawadniania w trakcie dnia i rozpoczynania dnia od szklanki wody, przez ograniczenie kontaktu z elektroniką, co mi przyznaje, czasem po prostu nie wychodzi, ale o tym myślę. Sport w różnej formie. Nie jestem na przykład freakiem siłowni, ale zeszły rok spędziłem na deskorolce. Rok poprzedni to był rok biegania i w tym roku znowu tego biegania jest więcej, więc sport w jakiejkolwiek formie, bo też to jest tak, że po prostu widać te efekty. 

Ja na przykład nie otaczam się aż tyloma badaniami, bo po prostu, dopóki to widzę na sobie, to wiem, że to działa. Jak wiesz, że się wyśpisz i powinieneś się wyspać, bo masz ważne spotkanie, albo ważny brainstorming następnego dnia w pracy, to po prostu powinieneś to robić. To są takie małe składowe, które łącznie odpowiadają na to, czy jak przyjdzie ten moment sprawdzenia się, to czy dasz radę, czy głowa będzie ci gdzieś uciekać, będziesz się rozpraszał i tak dalej.

Myślę, że to jest ważne, myślę, że też bardzo fajną zmianą jest to, że coraz większa ilość producentów oprogramowania zaczyna to zauważać i te wszystkie funkcjonalności jak właśnie ten digital well being, ten cyfrowy dobrostan po prostu staje się takim wbudowanym natywnym ficzerem  wielu platform. Im więcej będziemy o tym rozmawiać, tym bardziej z tego, może czasami niesłusznie, takiego elitarnego wyobrażenia o programowaniu przejdziemy do tego, że jesteśmy po prostu pracownikami umysłowymi, którzy muszą i się wyspać i zrobić sobie przerwę i iść na dobry film, czasami odpalić sobie konsolę, a czasami po prostu przysiąść i przeczytać mocno techniczną książkę. To wszystko pomaga. Ja w to wierzę.

 

Ja, to co powiedziałeś, odczytuję jako takie świadome wybory, świadome decydowanie, na co poświęcam czas, jeśli wybieram coś, to nie wybieram czegoś innego i konsekwencje będą takie, a nie inne. To jest oczywiście mega ważne, co powiedziałeś.

Myślę sobie, że też innym, świadomym wyborem, albo przynajmniej, który chciałem, żebyśmy podejmowali świadomie, to jest wybór miejsca pracy zwyczajnie. Bo wiadomo, nie pracujemy jako jednostki najczęściej, może tak to jest widziane gdzieś tam z zewnątrz, ale mimo wszystko pracujemy w zespołach. Pracujemy w pewnych kulturach organizacyjnych, pewnych firmach. To wszystko na nas wpływa, co by nie było. Te osiem plus godzin, które poświęcamy na pracę, to jest jednak znacząca część naszej doby. 

W związku z tym chcę Cię zapytać, na co zwrócić uwagę, jak wybierać to miejsce pracy, żeby to zwyczajnie przyczyniało się do wchodzenia na kolejny poziom w rozwoju naszej kariery, programowaniu?

 

Myślę, że zacząłbym od takiego najbardziej podstawowego kryterium związanego z typem firmy, do której idziesz. Okazuje się, że nie każda firma zatrudniająca programistów musi działać w ten sam sposób. Co więcej, spośród tych wszystkich firm można wyróżnić kolka typowych modeli takiego przedsiębiorstwa, czy też organizacji. Małe startupy będą bardzo różne od dużych korporacji, firmy produktowe będą bardzo różne od software housu masowo produkujących oprogramowanie. A to wszystko będzie sprawiać, że dzień pracy programisty może wyglądać inaczej. 

Tak jak blisko jesteś tych innych działów, o których wspominaliśmy wcześniej, może wyglądać inaczej. To, czym dla Ciebie jest technologia, może wyglądać inaczej. Ja tutaj bym był ogromnym fanem tego, żeby kierować się w stronę firm produktowych, bo one dają Ci możliwość takiego realnego kontaktu z klientem, poczucia tego kontaktu z klientem i zrozumienia, po co my właściwie w tej branży jesteśmy. Nie jesteśmy po to, żeby testować kolejny framework i nie jesteśmy w tej branży po to, żeby po prostu bawiąc się z tą technologią. Chociaż w tym jest dużo zabawy i to jest super. Klocki Lego, bawimy się, coś z niczego. To jest piękne, że odpalam konsolę i mogę sobie napisać skrypt, który mi zautomatyzuje coś, co mi zajmowało piętnaście minut, ale jednak koniec końców, powiedzmy, tę wypłatę dostajemy za coś. Często ja dostajemy za rozwiązywanie problemów klientów.

Tutaj firmy produktowe są bardzo korzystnym rozwiązaniem, bo w firmach produktowych ta technologia jest moim zdaniem na właściwym miejscu. To jest tak, że technologia jest ważna, ale nie jest najważniejsza i też programiści są w pewnym sensie zmuszani do tego, żeby poszerzać swoje spojrzenie na ten zawód. Produkować, ale świadomie rozmawiać z klientem, nie traktować klienta jako zło konieczne, tylko kogoś, kto nam zapłaci za ten miesiąc pracy. Typ firm, na to na pewno warto zwrócić uwagę z małą gwiazdką, że akurat Przemek Smyrdek poleca firmy produktowe. 

Kolejna sprawa to są ludzie w środku, bo jeśli już się zdecydujemy na te firmy produktowe, to na pewno trafimy na firmy, o których na przykład swego czasu głośno się pisało, bez podawania oczywiście nazw, ale głośno pisało w tym negatywnym kontekście niestety. To znaczy mamy jakieś nadgodziny w liczbie na przykład piętnaście dziennie. Oczywiście godzin pracy, nie nadgodzin. Albo mamy bardzo zdrowe warunki, co jest na przykład potwierdzane przez opinie na różnych portalach związanych z prasą.

Zastanowiłbym się, jaka jest kadra. Kto jest szefem. Czy ten szef założył wcześniej jakieś firmy, o których jest potoczna opinia, że to są dobre i zdrowe firmy? Czy w tych firmach stawia się na rozwój? Czy masz okazję do tego, żeby regularnie ze swoim managerem rozmawiać na one on one’ach na przykład, o tym, co Ci się podoba co ci się nie podoba? Więc to jest kolejna sprawa. Tutaj myślę, że też powiedzmy, idąc taki krok dalej, czyli od organizacji, przez ludzi, do takiego standardowego tygodnia pracy no to warto zrobić taki research, wywiad związany z tym, co się będzie działo, jak już się dostanę. To znaczy jak na przykład wygląda on boarding, czy dostaje jakiegoś buddiego, który może mnie tutaj przeprowadzić przez te pierwsze tygodnie i jak te tygodnie właściwie wyglądają. Czy to jest tak, że jestem pozostawiony sam sobie, czy nie jestem pozostawiony sam sobie.

Uważam, że szczególnie teraz w tych warunkach pracy zdalnej, całe to wdrażanie nowych pracowników jest trzykrotnie trudniejsze. To już było trudne, a jest jeszcze trudniejsze. Wiadomo, jakby cały kontakt ogranicza się do tego, jak ktoś coś od kogoś chce, to znaczy jakby ktoś zupełnie został pozbawiony takiego ludzkiego aspektu rozmawiania ze sobą. Więc warto o to zapytać. Przychodzę do firmy, już wie, kto tam pracuje, wiem, jaki to jest typ organizacji i co się dzieje. Czy po prostu jesteśmy w jakimś sprincie, jesteśmy wrzuceni w jakiś projekt, jaki jest w ogóle firmowy rytm. Co się dzieje, jak ktoś na przykład popełniam błąd. Jaka jest kultura firmy związana z tym, że może mi coś nie wyjść, mogę coś zepsuć, czy są jakieś na przykład procedury, jakieś blame’y, post mortemy, czy na przykład nie wiem, będzie mi to potrącone z pensji.

Taka sytuacja, którą tutaj trudno sobie tutaj wyobrazić, ale na pewno są takie firmy i to się dzieje, więc ja chcę powiedzieć, że są też firmy, gdzie się to też nie dzieje i warto o tym wiedzieć.

Myślę, że taka rzecz, na którą bardzo, w zasadzie takie dwie rzeczy, na które na początku drogi nie zwracamy uwagi, to po pierwsze firmowe wartości, czyli to, co firma komunikuje, jakby na zewnątrz. Oczywiście tutaj trzeba to wziąć lekko z dystansem, bo wiadomo, że te wartości na zewnątrz publikowane nie zawsze są tym, co zobaczymy w środku, ale przynajmniej wiemy, o co tym ludziom chodzi. Te firmowe wartości będą prawdopodobnie przekładać się na wszystkie te płaszczyzny, o których powiedziałem, to znaczy, jak się cieszymy, jak realizujemy projekty, jak podchodzimy do krytykowania siebie nawzajem, albo do popełniania błędów, albo do uczenia się. Czyli, o czym ta firma na zewnątrz tak naprawdę mówi.

Jeszcze jeden taki bardzo ważny aspekt, który też od niedawna jest dla mnie szczególnie ważny. To jest taki kontekst tego, gdzie ta firma jest. W całym cyklu życia byciem firmą, czy przychodzimy do startupu, który walczy o życie, któremu na przykład kończy się paliwo i szuka inwestora i wtedy wiadomo, że tej pracy będzie prawdopodobnie tona i to będzie praca często szalona i pewnie nadgodziny tam będą niestety normą. Czy na przykład przychodzimy do środowiska, gdzie ten produkt jest już ustabilizowany, budżet jest w miarę bezpieczny, tam również będą wyglądać takie aktywności, jak chociażby dzielenie się wiedzą tak, te wspomniane już nadgodziny? Myślę, że jest to po prostu ważne. Czyli wszystko to, ten match związany z tym, że firma X poszukuje specjalisty w technologii Y, to jest taka prosta sprawa.

Wiemy jednak, że sporo firm potrzebuje JS Developera albo React Developera, albo Ruby Developera, albo PHP Developera. Jaki to nam obraz daje tego, jaka to jest firma? No żaden, bo to znaczy, że te wszystkie dwadzieścia firm, które szukają PHP Developera, są identyczne? No oczywiście nie są identyczne. Trzeba takie śledztwo przeprowadzić i troszkę pogrzebać.

Jest taka ankieta z tego Welfare Developer Survey, taka coroczna ankieta. Pewnie sporo osób, które będą tego słuchać, ją zna. Związana z tym, żeby zrozumieć cały taki przekrój taki branży IT. W tym roku wyszło, że te całe company media, czyli wszystko to, co firma mówi na swój temat, to jest tak naprawdę najważniejszy czynnik związany z podejmowaniem decyzji, czyli jeżeli firma jest cicha, to pewnie powinna nam się zaświecić jakaś lampka ostrzegawcza, czemu tych materiałów nie ma. Jeśli to jest sektor rządowy, to pewnie wiadomo czemu, ale jeśli to jest, wydawałoby się, taka zwykła branża i dalej nie możemy się niczego odczytać na temat tej firmy i dalej nie widzimy nikogo na konferencjach z tej firmy, opinie są jeszcze negatywne, co gorsza, no to tutaj już jakiś tam obraz się pojawia.

 

Wiadomo. Nieraz ciężko jest w takim job adzie po prostu przekazać te rzeczy, ale po to mamy LinkedIna zwłaszcza, portale społecznościowe, portale z tymi opiniami, by się tego dowiedzieć, plus mamy rozmowę rekrutacyjną. To nie bez przyczyny nazywa się rozmową, a nie monologiem. Tam też powinniśmy spróbować dowiedzieć się jak wygląda ta kultura pracy i jak na co dzień powiedzmy podchodzi się do poszczególnych etapów wytwarzania oprogramowania, jak ludzie współpracują ze sobą. To jest jak gdyby dwie strony mają tutaj okazję, żeby się wybadać, żeby sprawdzić, czy ten match jest. Więc ciężko byłoby mi uwierzyć, że ktoś nie jest w stanie się dowiedzieć niczego. Myślę, że to już nie te czasy.

 

Tutaj à propos tego tematu rozmów rekrutacyjnych, może taki szybki tip związany z wyciąganiem informacji. W książce Chrisa Voss’a o negocjowaniu Never split the difference zobaczyłem kiedyś taką fajną poradę związaną z wyciąganiem informacji od ludzi i ta technika nazywa się pytaniami skalibrowanymi. W bardzo dużym skrócie chodzi o to, żeby nie pytać swojego rozmówcy tak, jak na przykład rekrutera, czy w tej firmie mogę popełniać błędy, bo oczywiście w każdej firmie możesz i każda firma ci powie, że to jest na pierwszym miejscu i to jest mile widziane, tylko żeby zadawać takie pytania pośrednie, skalibrowane na przykład, co dzieje się, jeżeli usunę ważny record z bazy danych. 

Drogi rekruterze albo managerze oprogramowania, opowiedz mi, co by się wtedy stało z moim stanowiskiem, wyciągamy tę samą informację, ale w zupełnie inny sposób do tego dochodzimy. Jakby unikamy takich banałów. To można zastosować zarówno w dyskusjach o pieniądzach, jak i w dyskusjach o tym, jak trudno będzie się nam pracować, jak łatwo się nam będzie pracować. Pytania skalibrowane, to znowu jest coś tam, co znalazłem w książce do negocjowania, ale też to pokazuje, że nawet w pracy programisty, która wydawałoby się, polega na siedzeniu przy komputerze i pisaniu kodu, może być to bardzo fajna i użyteczna technika. 

 

Fajny tip. Skoro jesteśmy tutaj przy rynku pracy, powiedzmy, to chciałbym cię zapytać o coś takiego. Często obserwuję, że ludzie często narzekają na ten rynek pracy, pomimo tego, że wygląda on dobrze. I tutaj oczywiście mam na myśli pozycję juniorów, która jest obecnie, powiedzmy skomplikowana, nazwijmy to może w ten sposób. 

Sam też rekrutuje i wiem, że pracodawcy najczęściej, czy najchętniej chcieliby mieć, powiedzmy, doświadczone osoby, żeby nie inwestować zbytnio we wprowadzenie takiej osoby w technologię. Wiadomo, że taka osoba może łatwo zmienić pracę, może szybko z niej wylecieć, wówczas ta inwestycja po prostu się nie zwróci. To inny temat. Natomiast spotykam się też z tym że pracodawcy coraz bardziej doceniają doświadczenie takie techniczne, technologiczne związane na przykład z danym językiem programowania i pewną wiedzę domenową, czyli powiedzmy ktoś, kto nie wiem, programuje w PHP i e-commercem, dajmy na to. Teraz chciałbym Cię zapytać, czy według Ciebie to będzie taki rozwijający się kierunek, że będziemy się specjalizować nie tylko, jak gdyby w danych technologiach, ale jeszcze w domenach.

 

Tutaj jeszcze wrócę do książki, o której powiedzieliśmy wcześniej, czyli do Pragmatycznego programisty, to jest książka z ’99 roku; sprawdziłem sobie teraz szybko. W tym ’99 roku pojawił się już ten koncept, to znaczy koncept, związany, z tym że wiedza domenowa jest ważna. Ona została przedstawiony w dość ciekawy sposób i dlatego o tym mówię. To znaczy, tam w tej książce pojawia się taki koncept jak właśnie portfolio wiedzy, czyli sposób na to, jak podchodzić do właśnie swojego rozwoju.

Jeśli mamy na przykład portfolio, jesteśmy funduszem inwestycyjnym i na przykład inwestujemy w przedsiębiorstwa, to wiemy, że raz kupione przedsiębiorstwo to nie jest klucz do tego, żeby długo na rynku pozostać. Znaczy mamy portfolio, którym zarządzamy, jesteśmy proaktywni, wchodzimy w interakcje i mamy po prostu taki ogródek, o który zaczynamy dbać. No i w tym Pragmatycznym programiście, tam jest również coś takiego napisane, że programista powinien myśleć o swoim rozwoju, jak o swoim portfolio, a częścią tego portfolio jest wiedza domenowa.

Co ciekawe to nie jest jedyna składowa. Bo tamtych składowych jest trzy, to znaczy skill techniczny, wiedza domenowa i doświadczenie. W moim, takim bardzo subiektywnym spojrzeniu myślę, że to jest o tyle fajne, że po prostu tych konfiguracji, na które możesz trafić, jest tak dużo, że ciężko mi tutaj o taką jednoznaczną odpowiedź, że wiesz, ciężko mi tutaj o taką jednoznaczną odpowiedź, że wiesz, wiedza domenowa jest tym, co się akurat liczy. To się na pewno bardzo liczy i też się spotkałem z programistami, którzy wręcz przedstawiają się jako programiści od E-commersa, tak jak Ty powiedziałeś, albo na przykład programiści od branży lotniczej. Po prostu przechodzą sobie do podobnych firm i te firmy wiedzą, że jak przyjmiesz taką osobę, to nie musisz na przykład przechodzić z nim przez słowniczek pojęć w danej branży, bo ona już to po prostu wie. Więc na pewno jest to ogromny plus, jednakże ja bym sobie bardziej cenił taką zwinność na tym rynku pracy.

To znaczy, wiedza domenowa jest ok, ale to, jak te domeny się zmienią i to czy ty będziesz w stanie się do tego przystosować, no to jeszcze chyba bije na głowę tą wspomnianą rzecz. Więc w moim przypadku taka zwinność, takie portfolio, czyli regularna praca, bardziej nawyki niż, jakaś taka konkretna reguła. Oczywiście, na pewno się zgodzimy, że jest mnóstwo programistów, którzy będą pracować od początku do końca w jednej branży i jest im dobrze, ale pewnie tyle samo programistów będzie tę branżę zmieniać, więc myślę, że ciężko tu o jednoznaczną odpowiedź.

Do mnie przemawia ten model portfolio, czyli mamy sobie ten ogródek, zarządzamy nim regularnie, musimy go powiększać, regularnie musimy o czymś zapominać, żeby robić miejsce na nowe praktyki. To też jest również bardzo ważne. I chyba to, bo jednak całe to tempo zmian i to, co się dzieje z tą naszą branżą, bardziej mnie skłania do tego, żeby jednak bardziej doceniać tę branżę agility słynne niż tę wiedzę domenową.  Aczkolwiek, pewnie, gdybyśmy porozmawiali z prezesem banku, który szuka programistów, to dla niego byłoby to obojętne, jaki to framework, ważne, żeby był Fintech w portfolio albo banki.

 

Tak. Tutaj to faktycznie powiedziałbym, że zależy. Chyba najlepsza odpowiedź, ale warto to brać do siebie. Bo niektórzy faktycznie, tak jak powiedziałeś, wolą pracę na przykład software house i tam się dużo zmienia. Po prostu doceniają tę zmienność, a niektórzy idealnie odnajdują się w korporacjach, gdzie to środowisko jest powiedzmy jest mniej zmienne.

Przemku, powoli zbliżamy się do końca naszej rozmowy. Powiedzieliśmy tutaj o wielu drogach, technikach rozwoju, różnych narzędziach i tak dalej. Myślę, że ktoś, kto tego słucha, kto nie miał wcześniej styku z tego typu rzeczami, może być teraz trochę zaniepokojony, albo przynajmniej gdzieś tam się pogubić w tym wszystkim.

Dlatego chcę Cię zapytać jeszcze na koniec, jaką taką jedną, może dwie rzeczy, byś polecił osobie, która chce wejść na wyższy poziom programowania. Od czego zacząć. Zgodzisz się, że próba zaopiekowania wszystkich tych tematów jest niewłaściwa.

 

To znowu jest o tyle niebezpieczne pytanie, na które można by odpowiedzieć „To zależy”  tak jak w poprzednim przypadku. Tutaj mam taką jedną poradę, czy taką wskazówkę i ona polegałaby na tym, żeby starać się podnosić nos zza klawiatury. Wydaje mi się, że cała ta intensywność naszej pracy powoduje, że po prostu zapominamy o świecie wokół nas. Ja również na to cierpiałem i Ty może też na to czasami cierpisz. Jak czasami pojawia się jakiś back albo jakiś algorytm nie chce działać, albo jakiś unit test nie chce przejść, to nasze całe pole widzenia programistyczne zwęża się po prostu do jednego ticketa na Jirze.

Jeśli pytasz mnie o taką jedną poradę, no to ta porada polegałaby na tym, żeby pamiętać, że na tym tickecie prawdopodobnie nie kończy się świat. Warto zrozumieć, skąd ten ticked przyszedł, czy są jakieś tickety podobne, czy przy okazji, że coś robię, coś mnie bardzo zaangażowało, mogę na przykład dopisać jakąś dokumentację, pomóc komuś z innego działu, czy mogę kogoś wdrożyć, kto dopiero przyszedł do firmy i nie miał jeszcze okazji pracować w tym obszarze. Więc bycie proaktywnym i też zachowywanie takiego w pewnym sensie dystansu. Ja sam się tego uczę, ale takie w pewnym sensie pobawienie się trochę tym programowaniem. To znaczy jasne, za to nam płacą jesteśmy programistami, ale tak naprawdę płacą nam za rozwiązanie problemów, a nie rozwiązywanie problemów związanych ze wpisywaniem kodu. Czyli to kodowanie to jest jedna z wielu opcji. Właśnie o tym myślę, że warto by było pamiętać.

Kiedyś jasne, były przekonania związane z tym, że programista to jest jakiś no-life, koszula i tak dalej, ale to już dawno nie są te czasy. Już przeszliśmy, teraz myślę, że taki kolejny level to jest właśnie to, że programowanie to nie jest tylko programowanie. To jest właśnie product engeenering i myślę, że tego coraz więcej będziemy widzieć u nas, a patrząc na mapie w lewo, to tego widzimy już bardzo dużo. 

 

Dokładnie. Czyli można powiedzieć na końcu, że jest taka świadomość tego, gdzie jesteśmy, co robimy. Może taka luksusowa jak na te czasy, możliwość zatrzymania się chwilę, zastanowienia. 

 

Jasne, że tak

 

To nam może pomóc.

 

Przy całej tej puli wiedzy, która też jest dostępna, to tak naprawdę chodzi o te same postawy, które mamy w obszarach technicznych. To znaczy, musimy być otwarci na to, żeby czytać, musimy być otwarci na to, żeby pozyskiwać wiedzę i być gdzieś tam w kontakcie z osobami, z którymi normalnie nie bylibyśmy w kontakcie. I jeśli uświadomimy sobie, że to są tak naprawdę te same postawy, które robimy, czy prezentujmy w stosunku do frameworków i teraz nagle trzeba je zacząć prezentować w stosunku, do nie wiem, biznesu albo klienta, no to to może nie będzie takie trudne.

Ja też myślę, że część z tych tematów, o których tutaj dzisiaj porozmawialiśmy, będzie, powiedzmy, trudna do przełknięcia, ale myślę, że i pewnie też się z tym zgodzisz, tutaj mówimy o takim przedłużaniu sobie daty ważności w tym zawodzie. To jest na tyle ciekawy zawód, że warto sobie tę datę ważności przedłużać i nie warto się kampować z jedną konkretną technologią, moim zdaniem, tylko zrozumieć cały ten taki szerszy kontekst, po co to robimy. Chyba o to chodzi.

 

Dokładnie, dokładnie. Zgadzam się w całej rozciągłości.

Dzięki, Przemku za tę godzinę plus. 

 

Dzięki również!

 

Fajne rozmowy. Myślę, że to naprawdę wartościowe będzie, i jest, podcast dla słuchaczy. Także z mojej strony wielkie dzięki.

Powiedz, proszę jeszcze na końcu, gdzie Cię znaleźć w internecie, jak się z tobą skontaktować najlepiej?

 

Ja tutaj polecę dwa miejsca. Przede wszystkim mój statek matkę, czyli przeprogramowanie.pl. Lubię to nazywać platformą dla ambitnych programistów, zarówno na naszym kanale na YouTube przeprogramowanie.pl, ale też na stronie. Mała ukryta reklama, nie tak ukryta, niebawem startuje czwarta edycja Opanuj JavaScript. Więc jeśli szukacie okazji, żeby rozwinąć się w kierunku JavaScript, to Opanuj JavaScript, będzie odpowiednim kierunkiem dla Was. 

Drugim takim miejscem, gdzie można mnie znaleźć, takie bardziej personalne, to jest strona smyrdek.com. To jest miejsce, gdzie dzielę się takimi, bardziej prywatnymi przemyśleniami, związanymi z programowaniem i rozwojem, ale też miejsce, gdzie znajdziecie więcej informacji o moim kursie LevelUp. Tam więcej informacji o tym, jak ten kurs wygląda dla jego absolwentów, dlaczego zdecydowałem się na stworzenie takiego materiału, czemu wierzę, że programistom jest potrzebny po prostu taki materiał, więc przeprogramowani.pl i smyrdek.com.

 

Dokładnie, tak się składa, że jestem, że tak powiem, absolwentem Twojego kursu LevelUp, także też polecam, bardzo wartościowe treści. Myślę, że świetne uzupełnienie i rozszerzenie tego, o czym dziś rozmawialiśmy. Także, jak najbardziej polecam, oczywiście wszystkie linki standardowo w notatce do odcinka się znajdą.

Z mojej strony, Przemek, jeszcze raz, wielkie dzięki!

Do usłyszenia, cześć!

 

Dzięki serdeczne!

 

I to na tyle, z tego, co przygotowałem dla Ciebie na dzisiaj.

Mam nadzieję, że po przesłuchaniu tej rozmowy, rozumiesz już, że wyższy poziom w programowaniu, to nie tylko kolejne języki czy frameworki, ale także umiejętności miękkie, zrozumienie biznesu, dzielenie się wiedzą i wychodzenie poza przysłowiową, strefę komfortu.

Jeśli ten odcinek był dla Ciebie interesujący i przydatny, odwdzięcz się, proszę recenzją, oceną lub komentarzem w social mediach.

Jeśli masz jakieś pytania, pisz śmiało na krzysztof@porozmawiajajmyoit.pl.

Zapraszam też do moich mediów społecznościowych.

Ja się nazywam Krzysztof Kępiński, a to był odcinek podcastu Porozmawiajmy o IT o tym, jak przejść na kolejny poziom w programowaniu.

Zapraszam do kolejnego odcinka już za tydzień.

Cześć!

 

+ Pokaż całą transkrypcję
– Schowaj transkrypcję
mm
Krzysztof Kempiński
krzysztof@porozmawiajmyoit.pl

Jestem ekspertem w branży IT, w której działam od 2005 roku. Zawodowo zajmuję się web-developmentem i zarządzaniem działami IT. Dodatkowo prowadzę podcast, kanał na YouTube i blog programistyczny. Moją misją jest inspirowanie ludzi do poszerzania swoich horyzontów poprzez publikowanie wywiadów o trendach, technologiach i zjawiskach występujących w IT.