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. zwykle się kończyło na tym, iż 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. ale jak to na studiach, kilka było zajęć które wnosiły coś do mojej edukacji informatycznej. Co nie znaczy, iż 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ł iż tak naprawdę zainteresowałem się tworzeniem stron i aplikacji internetowych. Bez sportu nie byłbym tu gdzie teraz jestem.
Natomiast, jeżeli 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żeli 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, w tej chwili 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, iż w tamtym okresie (około 2008 roku) było bardzo kilka 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ę, iż 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, iż 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żeli 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ć iż 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żeli 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, iż 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 iż 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ć, iż gwałtownie się wybije na wyższy poziom,
- Może również sprawić, iż 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 iż 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 iż 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ż, iż korzystanie ze StackOverflow jest czymś złym. Trzeba jednak zachować odpowiedni balans.
