Okiem programisty. Z porażki i zwycięstwa można wyciągnąć odpowiednią naukę. Wywiad z Piotrem Nalepą

Aby móc skutecznie szkolić innych, każdy nauczyciel powinien najpierw uczyć się na własnych błędach. Podobnie jest w przypadku programistów – przekazywanie wiedzy podczas szkoleń czy konferencji wymaga zapoznania się z daną kwestią na każdy możliwy sposób, również ten błędny. O nauczaniu programistów oraz stawaniu przed nimi wyzwań rozmawialiśmy z Piotrem Nalepą.

Jaka była Twoja ścieżka do aktualnego stanowiska? Dlaczego postanowiłeś zostać programistą?

Moja ścieżka do IT wiodła krętymi drogami. Jako dziecko, od zawsze lubiłem piłkę nożną i chciałem się w niej spełniać. Niestety, z różnych powodów musiałem porzucić tą ścieżkę (chociaż kilka razy próbowałem na nią wrócić). Potem nastąpił okres kiedy programowanie traktowałem jako ciekawostkę. Kupowałem magazyn komputerowy Komputer Świat i wówczas określiłbym się mianem bardziej sprzętowca niż programisty. Potrafiłem znajdować źródła problemów w sprzęcie komputerowym i odpowiednio je naprawiać na miarę swoich możliwości. W tymże magazynie pojawiały się czasami artykuły dotyczące programowania i uczyłem się tego z ciekawości. Zazwyczaj się kończyło na tym, że starałem się stworzyć program przedstawiony w tutorialu i to było dla mnie mega osiągnięcie. Potem nastąpiła spora miłość do gier, gdzie sporo czasu spędzałem przy nich i czasem próbowałem manipulować przy plikach gry, np. dodając nowe cywilizacje/miasta do pierwszych wersji gry Cywilizacja.

Tak naprawdę przełom nastąpił na studiach, na które poszedłem bo lubiłem komputery. Wówczas zacząłem poznawać programowanie z innej strony. Lecz jak to na studiach, niewiele było zajęć które wnosiły coś do mojej edukacji informatycznej. Co nie znaczy, że nie było żadnych. Wówczas wszedłem głębiej w świat PHP, C# i baz danych. Mając tą podstawę byłem w stanie w końcu zrealizować projekt, który chodził za mną od długiego czasu. Był to projekt związanych z drużyną piłkarską w której wówczas grałem amatorsko. Chodziło o stworzenie strony gdzie moglibyśmy zamieszczać informacje dotyczące swoich meczów, treningów, składów i rozgrywek w których braliśmy udział.

Ostatecznie, to sport był zapalnikiem który sprawił że tak naprawdę zainteresowałem się tworzeniem stron i aplikacji internetowych. Bez sportu nie byłbym tu gdzie teraz jestem.

Natomiast, jeśli chodzi o moje obecne stanowisko: Lead Software Engineer, to ścieżka do niego wiodła poprzez wiele różnych projektów w których mogłem się wykazać zdolnościami programistycznymi, umiejętnościami zarządzania projektami od strony technicznej,a także pomaganiu kolegom z zespołu w byciu lepszymi programistami. Ta kombinacja doświadczeń doprowadziła mnie do tego miejsca gdzie jestem i nie zapowiada się ,aby miał być to mój szczyt.

Dodatkowo, to co mi pomogło to zaufanie drugiej strony jeśli chodzi o moje pomysły na wdrażanie funkcjonalności i usprawnianie procesu twórczego oraz UX. W moim przypadku, osobą która mi naprawdę zaufała był Łukasz Serwatka, obecnie CTO w Ibexa. Za to będę mu zawsze wdzięczny.

Skąd pojawiła się u Ciebie potrzeba/pomysł dzielenia się wiedzą z innymi? Czy coś zainspirowało cię do stworzenia Twojego bloga?

Pomysł na bloga wziął się stąd, że w tamtym okresie (około 2008 roku) było bardzo niewiele stabilnych źródeł informacji o tym jak tworzyć strony internetowe. Dodatkowo, źródeł traktujących o programowaniu pisanych po polsku było jeszcze mniej.

To mnie zmotywowało do tego, aby to czego się nauczyłem opisywać na blogu tworząc z tego swego rodzaju ściągawkę do swojej codziennej pracy. W międzyczasie okazało się, że treści jakie tam zamieszczałem zaczęły stawać się coraz popularniejsze co budowało moją popularność w środowisku IT. Wówczas zdałem sobie sprawę z tego, że dzielenie się wiedzą w taki sposób w jaki to robiłem jest jakby oddaniem długu który zaciągnąłem od innych osób, które postanowiły się podzielić ze mną sposobami na rozwiązanie wyzwań z jakimi się wówczas zmagałem podczas tworzenia stron i aplikacji internetowych.

Momentami blog miesięcznie odwiedzało 25 tysięcy unikalnych użytkowników. Liczba ta sukcesywnie spadała wraz ze zmianami algorytmów wyszukiwania przez Google oraz wraz ze spadkiem częstotliwości publikacji tekstów na blogu.

W jaki sposób pomagasz innym programistom w ulepszeniu ich “sztuki programowania”?

Zachęcam ich na wiele różnych sposobów. Jednym z najlepszych sposobów jest wykonywanie odpowiedniego code review, gdzie nie oceniam kodu czy jest zgodny ze stylem pisania (to zostawiam automatom pokroju ESLint, Prettier i innym). Skupiam się na tym czy taki programista zrozumiał sedno problemu i czy wybrał najbardziej optymalne rozwiązanie dla danego problemu. Jeśli jednak pojawiają się kawałki kodu które wymagają poprawy to skupiam się na tym, aby nie tylko takie kawałki kodu wskazać, ale też zasugerować że są lepsze rozwiązania. Prowadzę pewnego rodzaju dyskusję na zasadzie: “Jak myślisz, czy dane rozwiązanie jest najbardziej optymalne? Czy rozważałeś jakieś inne podejścia do rozwiązania problemu? Jeśli tak, to jakie?”

Chodzi tu o to, aby pomóc takiej osobie spojrzeć inaczej na daną sytuację. By sprawić, aby zaczęła kombinować i interesować się danym zagadnieniem nieco głębiej. Gdy to natomiast nie pomaga, wówczas podsyłam linki czy to do moich wpisów na blogu czy też do innych źródeł opisujących sposoby rozwiązania danego wyzwania.

Innym sposobem który często stosuję gdy chcę pomóc innym zwiększyć swoje umiejętności jest pair-programming (czyli programowanie w parach). Ma to na celu pokazanie mojego sposobu myślenia nad danym zagadnieniem i próbie jego naśladowania przez kolegę/koleżankę z zespołu. Wymaga to bardzo dużej dyscypliny zarówno z mojej strony jak i ze strony osoby potrzebującej tej pomocy, ale jest to efektywny sposób nauki.

Dlaczego wspominam o dyscyplinie z mojej strony? Mianowicie, muszę pamiętać o tym, że to co jest dla mnie oczywiste nie zawsze jest oczywiste dla drugiej strony. Z tego powodu, zadaję pytania w stylu: “Czy to ma sens? Jakbyś inaczej rozwiązała/rozwiązał dany problem?”, itd. Trzeba pamiętać, aby wolniej rozwiązywać dany problem aby druga strona mogła go zrozumieć.

Od jakiegoś czasu nagrywam też własne, krótkie wideo na potrzeby wewnętrzne projektu gdzie opisuję sposoby kodowania. To w zasadzie jest taki asynchroniczny pair-programming. Aplikacja Loom świetnie się do tego nadaje, ponieważ można zadawać pytania do konkretnego momentu w danym filmie i na tej podstawie pomagać innym zrozumieć zagadnienie. W dobie pracy zdalnej jest to nieocenione narzędzie.

Co rozumiesz przez dawanie szans i wyzwań? Jakie są najbardziej zauważalne różnice w szkoleniu przyszłych programistów poprzez dawanie przysłowiowej wędki, a nie ryby?

Dla mnie dawanie kolegom szansy na wykazanie się jest czymś co sprawia że przyrost umiejętności jest znacznie większy, niż podczas robienia tego co się już umie i robi się bez większego wysiłku. To co zauważyłem wśród programistów z mniejszym doświadczeniem, to brak umiejętności odróżnienia tego co jest dobrym rozwiązaniem, które da się łatwo utrzymać w długim okresie czasu od rozwiązania, które co prawda działa, ale ma spory narzut długu technicznego, który długofalowo będzie działał negatywnie na cały zespół.

Dawanie szansy może mieć dwojakie znaczenie dla przyszłości programisty:

• Może sprawić, że szybko się wybije na wyższy poziom,
• Może również sprawić, że będzie musiał poznać smak niepowodzenia i tylko od danej osoby będzie zależało czy wyciągnie wnioski na przyszłość (co docelowo pomoże takiej osobie w karierze programisty) czy też uzna że woli spocząć na laurach i zostać przy tym co do tej pory osiągnął.

Z porażki i ze zwycięstwa można wyciągnąć odpowiednią naukę, która długofalowo może przynieść pozytywne skutki. Niby to jest banał, ale wielu ludzi się skupia na negatywnych aspektach niepowodzeń i nie szuka w nich kolejnej szansy na poprawę w przyszłości. Moje osobiste porażki pomogły mi się rozwinąć i sprawiły że jednak osiągnąłem ten poziom który zamierzałem osiągnąć i w dalszym ciągu widzę perspektywę rozwoju dla siebie.

Z mojej perspektywy, korzystanie z portali typu StackOverflow, to jednak dawanie programistom ryby, nie wędki. Ktoś zaproponował rozwiązanie, które jakoś działa i może iść dalej do przodu z projektem. Najczęściej jednak gotowce nie powodują efektu zdobywania wiedzy i zrozumienia sedna problemu. Nie twierdzę też, że korzystanie ze StackOverflow jest czymś złym. Trzeba jednak zachować odpowiedni balans.

Oferty pracy z

Czy możesz opowiedzieć coś więcej o konferencjach, w których bierzesz udział jako mówca? W jaki sposób udało ci się dotrzeć do bycia speakerem?

Z konferencjami wiąże się ciekawa historia. Jako student, nie znosiłem występować przed ludźmi ze swojej grupy przedstawiając jakiś projekt czy opracowanie. Wiązało się to z ogromną ilością stresu.

Natomiast, wraz ze zdobywaniem wiedzy programistycznej i coraz większym udzielaniem się na forach webmasterskich, uznałem że pora wyjść ze swojej strefy komfortu i pojawić się na konferencji jako prelegent.

Było to stresujące, ale jednocześnie motywujące. Jako bloger, przekazywałem już wiedzę, tyle że za pomocą tekstu. Jako prelegent, mogę tą samą lub powiązaną wiedzę przekazywać w formie tekstu jak i słowa mówionego wzmocnionego przekazem multimedialnym (slajdy, live-coding, itd.) to sprawia że pewne idee mogą o wiele łatwiej dotrzeć do szerszego grona osób.

Wyjście ze swojej strefy komfortu jeśli chodzi o wystąpienia publiczne a następnie spotykanie się z osobami, które mogłem przekonać do pewnych idei dzięki moim wystąpieniom. Sprawiły że miałem ochotę kontynuować tą przygodę.

To plus możliwość porozmawiania o danym zagadnieniu z osobami, które są tym tematem zainteresowane sprawia że nie tylko te osoby się uczą, ale też ja poznaję inną perspektywę w danej sprawie. Dzięki temu się rozwijam.

Dotychczas występowałem już na wielu konferencjach i meetupach: w Polsce i za granicą. W Polsce byłem na konferencjach typu JoomlaDay, InfoShare czy MeetJS. Oprócz tego występowałem również w Chorwacji, Niemczech i Anglii jak i online. Wszędzie przedstawiałem sposoby rozwiązywania problemów programistycznych jak i sposoby zarządzania projektem IT.

Kto najczęściej zgłasza się do Ciebie po pomoc i wsparcie? Osoby, które chcą się przebranżowić, czy takie, które zaczęły już przygodę z programowaniem i nie wiedzą, w którym kierunku pójść?

Przed prawdziwym boomem na zostanie programistą (czyli tak mniej więcej przed 2017 rokiem), zgłaszały się do mnie najczęściej osoby szukające pomocy w rozwoju swojego warsztatu tak, aby móc uzyskać lepszą pozycję w firmach w których te osoby pracowały.

Po 2017 roku, coraz więcej osób spoza branży IT zaczęło się do mnie odzywać w poszukiwaniu odpowiedzi jak na pytanie: “Jak zacząć? Czego się uczyć? Jak to pogodzić z obecną pracą i życiem?” Ten zestaw pytań nigdy nie będzie miał jednej odpowiedzi, ale to co zawsze mówię to: “Wymyśl swój projekt: stronę internetową, aplikację której lubisz używać. Następnie spróbuj ją odtworzyć własnymi siłami.”

To co jest ważne następnie, to wytrwałość i umiejętność mówienia NIE swojemu własnemu leniowi. Nauka programowania wymaga poświęceń i wymaga zmiany sposobu myślenia na temat rozwiązywania problemów. To nie przychodzi łatwo, ale krok po kroku w końcu zaczyna procentować i przynosić coraz więcej frajdy.

Jakbym miał opisać to uczucie, to opisałbym je jako granie w Wiedźmina 3 (nie znając historii z książek), gdy na początku nie wiadomo co i jak i gra może się się strasznie dłużyć. Z biegiem czasu, gdy nasza postać staje się coraz mocniejsza, to ta gra zaczyna być coraz ciekawsza i kusi do odkrywania sekretów poza główną fabułą.

W przypadku nauki programowania, główną fabułą jest początkowy projekt który chcemy zrealizować, a sekretami do odkrywania są wszystkie dodatkowe informacje, które mogą lecz nie muszą nam pomóc w osiągnięciu naszego celu (np. nauka chmury AWS czy też poznanie dodatkowego języka programowania albo poznanie baz danych).

JS, CSS i UX – tym pasjonujesz się najbardziej. Dlaczego?

Swoją karierę jako webmaster, zaczynałem od poznania HTML, CSS, PHP, MySQL i jQuery. Przez okres 2 lat to PHP i MySQL mnie najbardziej interesowały. Lecz w momencie, gdy w 2012 roku zmieniłem miejsce pracy, to uznałem ostatecznie że więcej frajdy daje mi tworzenie interfejsów użytkownika i tego co widać na stronach internetowych. Backend, to na dłuższą metę pisanie non stop tego samego (endpointy, zarządzanie danymi, integracje z zewnętrznymi dostawcami danych). Żartowałem, tego jest więcej, ale większości z nich zwykły użytkownik nie zobaczy nigdy na oczy.

Natomiast z JS i CSS zabawna jest o tyle fajna, że można zrobić wiele zaskakujących rzeczy, typu niestandardowy wygląd strony czy aplikacji,  jakieś dodatkowe smaczki a koniec końców to właśnie przy pomocy JS, CSS jak i HTML sprawiamy że wygoda korzystania z rozwiązań które tworzymy jest znacznie większa. To daje nam pełen fokus na użytkownika i jego potrzeby. Dzięki tym narzędziom możemy sprawić, że użytkownik może szybciej osiągnąć swój cel, a to na koniec może skutkować biznesem, który przynosi zysk, a dla mnie osobiście – większe pieniądze, jako programista.

Jakie było największe wyzwanie zawodowe, którego się podjąłeś?

Wyzwań zawodowych miałem wiele w swoim życiu, ale 2 takie “naj” to:

• Zbudowanie interfejsu do tworzenia stron i aplikacji internetowych z podglądem na żywo. To co odróżniało to rozwiązanie od innych to fakt, że można było edytować dowolną stronę internetową po niewielkich modyfikacjach. Zachowując jednocześnie całą jej funkcjonalność. To było nie lada wyzwanie.
• Kolejny projekt, który mi bardzo dużo dał, to przygotowanie wraz z zespołem planu migracji największego portalu nieruchomości w Polsce do najnowszych technologii. Udało się nam osiągnąć coś przy czym kilka poprzednich zespołów poległo i tym samym sprawiliśmy że można było dalej rozwijać już nie-młodą platformę internetową o nowe ficzery.

Obydwa te wyzwania sprawiły, że poznałem moc odpowiednio przygotowanej dokumentacji technicznej. Dzięki temu można było uniknąć problemu “wiedzy plemiennej”, czyli wiedzy przekazywanej ustnie między członkami zespołu, która łatwo mogła zaginąć w momencie, gdy członkowie zespołu zmieniali pracę. Opowiadałem o tym, na jednej z konferencji gdzie dzieliłem się wiedzą, jak utrzymać wiedzę projektową w firmie, tak aby każdy nowy członek zespołu mógł z niej czerpać garściami i mieć jak najmniej problemów podczas pracy nad projektem.

W jaki sposób przygotowujesz się do szkoleń i uczestnictwa w konferencjach jako speaker?

Szkolenia i konferencje to dwie różne rzeczy. Do każdej z nich przygotowuję się inaczej. To co jest ważne w prezentowaniu danego tematu to zasadzić ziarenko ciekawości w słuchaczach. Sprawić że to co zostanie zaprezentowane, przykładowe rozwiązania problemów lub tylko zajawki rozwiązań sprawią, że osoby się zainteresują głębiej danym tematem. W prezentacji nie chodzi o to, aby całościowo przedstawić rozwiązanie jakiegoś problemu, bo na to zawsze braknie czasu w trakcie 45-minutowej prezentacji.

Chodzi o to, aby swoją prezentacją zainspirować ludzi. Powiedzieć że istnieją rozwiązania które mogą im pomóc. To co jest dodatkowo ważne, to linki do źródeł. Zamieszczam je na slajdach prezentacji, jeśli wiem, że będzie udostępniona w sieci. Lub zamieszczam informacje o źródłach na kanałach społecznościowych czy innych kanałach komunikacyjnych jakie powstają przy okazji danej konferencji (np. Slack, mailing, itd),

W przypadku szkolenia, to najczęściej celem szkolenia jest przedstawienie sposobu rozwiązania danego zagadnienia w sposób jak najbardziej efektywny. Dodatkowo, mogę przekazać informacje oraz pokazać jak używać najnowszych nowinek technologicznych aby sprawić, że nasza strona/aplikacja będzie lepsza pod różnymi względami.

I znowóż, tu chodzi o zainteresowanie uczestników danym tematem i dzielenie się wiedzą. To co jest przedstawiane na szkoleniach ma pomóc w codziennej pracy oraz zaciekawić innych danym tematem. 

Jako ciekawostkę dodam, że okresie pracy na uczelni, gdzie prowadziłem zajęcia z tworzenia aplikacji internetowych, zauważyłem jedną rzecz. Studenci często nie są zainteresowani tematem, tylko tym aby zdobyć punkty i wpis do indeksu. Co mnie osobiście zaskoczyło i sprawiło, że po roku takiej współpracy zrezygnowałem. Nie cieszy mnie współpraca z ludźmi, którym nie zależy.

Czy udzielasz się w społeczności Open Source? Dlaczego to jest dla Ciebie ważne?

W trakcie całej swojej kariery udzielałem się wielokrotnie w ruchu Open Source. Czy to na początku w społeczności użytkowników CMSów Joomla i WordPress, a potem już w społeczności różnych bibliotek JS, które często są wykorzystywane w różnych projektach internetowych. Istotne było dla mnie to że mogłem swoim wkładem pomóc innym. Ruch Open Source jest z jednej strony niedoceniany a z drugiej strony jest traktowany roszczeniowo. Bardzo wielu programistów oczekuje od twórców oprogramowania Open Source pomocy w ich codziennej pracy, rozwiązywania problemów które bardzo często nie są w żaden sposób powiązane z daną biblioteką tylko z błędną implementacją swoich rozwiązań.

To wszystko sprawia, że ruch Open Source, jeśli nie jest wspierany przez duże firmy to tak naprawdę zaczyna się kurczyć. Przynajmniej ja to tak odbieram. Stąd też pojawiają się takie akcje jak Hacktoberfest z Githuba, które mają na celu popularyzację rozwoju oprogramowania Open Source i popularyzację postawy współpracy między zupełnie obcymi osobami, które korzystają z danych rozwiązań. Niektórzy w tej akcji widzą tylko możliwość zdobycia jakichś dodatkowych “swagów” typu koszulki czy naklejki.

---

Piotr Nalepa. The game changer, Lead Software Engineer @ KUDO, bloger i speaker na konferencjach IT. W trakcie swojej kariery pracował przy wielu różnych projektach IT: branża medialna sportowa, branże e-commerce, projekty Open Source aż w końcu projekty związane z komunikacją między ludźmi. W swojej codziennej pracy skupia się na tym, aby zespół jako całość rósł pod względem umiejętności i był coraz bardziej efektywny w swojej pracy.

---

Zdjęcie główne pochodzi z unsplash.com