Jak efektywnie uczyć się programowania? - okiem programisty i psychologa

Z nauką programowania jest jak ze zdobywaniem gór. Nawet, jeśli wszystko dobrze zaplanujesz, zwykle podczas wspinaczki czeka Cię wiele niespodzianek i problemów. Jak się nie zgubić na tym szlaku? Co robić, żeby się za szybko nie zmęczyć? I co Cię czeka, gdy dotrzesz na szczyt? Wyjaśniamy w rozmowie z Wojciechem Miłkiem - programistą, który w Kodilli zajmuje się przede wszystkim developmentem PHP. Oprócz tego jest jednak także praktykującym psychologiem. O efektywnej nauce programowania jest zatem w stanie powiedzieć bardzo dużo.

Jak efektywnie uczyć się programowania? Czy są jakieś sposoby, procesy, które mógłbyś polecić? Można je wykuć na blachę?

Wojciech Miłek: Najpierw musimy rozróżnić dwa pojęcia: naukę składni języka od nauki programowania. Tego pierwszego można się nauczyć bardzo szybko i to rzeczywiście jest trochę jak szkolne wkuwanie. Wystarczy miesiąc, dwa, żeby już coś umieć. Żeby poczytać, pooglądać, przemyśleć i zacząć stawiać pierwsze kroki w koderskim świecie. Z nauką języka programowania jest już inna bajka.

A to nie to samo?

WM: Absolutnie! Znajomość składni jest fundamentalna, ale w żadnym wypadku nie wystarczy. Nauka programowania to z kolei nauka myślenia i rozwiązywania problemów, a to zupełnie inny rodzaj aktywności umysłowej. To analizowanie, wysnuwanie wniosków, znajomość dobrych praktyk pisania kodu, przetestowanych rozwiązań, sprawdzonych wzorców architektury na różnych poziomach oraz wykorzystywanie ich i osadzanie w dotychczasowych rozwiązaniach. A jeśli powyższych rozwiązań nie znasz, bo nigdy się z nimi wcześniej nie zetknąłeś...

...wtedy potrzebujesz kogoś, kto Cię poprowadzi. Nauczyciela. Potrzebujesz Mentora.

WM: Wielu początkujących programistów - mimo wielkiej determinacji i zaangażowania - bez wsparcia osób doświadczonych może się zagubić, zniechęcić, zmęczyć. To pokazuje, jak bardzo ważna jest rola Mentora, który prowadzi takie początkujące osoby podczas bootcampów Kodilli. Składnia, pisanie fragmentów kodu, znajomość podstawowych bibliotek - to można opanować szybko i w miarę bezboleśnie. To jednak nie wszystko.

Wyobraźmy sobie klocki, z których chcemy coś zbudować. Na początku musimy je poznać. To jest dwójka, to trójka, to czwórka, tu daszek, tu kółka, tu okienko. Są rozsypane. Niektóre do siebie pasują, inne nie. Można z nich stworzyć zarówno jakiś mały, koślawy domek, jak i piękny wieżowiec z tarasami, balkonami, windami i garażem podziemnym.

I nie jest to kwestia predyspozycji i talentu?

WM: To, co odróżnia początkujących programistów od doświadczonych developerów, to m.in. umiejętność architektonicznego myślenia oraz sprawdzonych algorytmów i struktur. Jeśli robisz coś od lat, to nie tylko budujesz szybciej i efektywniej, ale wiesz też, co się sprawdza, a co nie. Zdajesz sobie sprawę, że niektóre uproszczenia lub pominięcia prędzej czy później się mszczą, choć na początku wydają się świetnym pomysłem.

To też jest do nauczenia?

WM: Oczywiście. Tego się nie ma w sobie. Osobom początkującym może się wydawać, że to jest jakieś feng-shui, indywidualne wyczucie.  Im głębiej będą jednak eksplorować obszary programistyczne, tym bardziej zaczną dostrzegać, że istnieją pewne powszechne kanony, reguły myślenia i reguły tworzenia. Można o nich przeczytać w książkach i na poziomie teorii mogą wydawać się znane lub oczywiste, a czasem przeciwnie - całkowicie nadmiarowe i zbędne - ale gdy przychodzi do przekładania tej teorii na praktyczne tworzenie kodu okazuje się, że niekoniecznie jest to takie oczywiste i proste.

Mentor, feedback, code review…

WM: To są warunki sprzyjające i potrzebne. Samotni geniusze, którzy posiedli wszelką dostępną w swoich czasach wiedzę, umarli 300 lat temu. Uważa się, że ostatnim z nich był Leibnitz ze swoją koncepcją monad. Dziś należy przyjąć, że ja nie wiem wszystkiego - inni wiedzą. Żeby się uczyć efektywniej, żeby się rozwijać, trzeba też polegać na ludziach, którzy Cię odpowiednio ukierunkują, wskażą książki, które warto czytać, tutoriale, które warto oglądać. Powiedzą: spójrz na tamten kod, przyjrzyj mu się, prześledź go, spróbuj w nim znaleźć błędy. A może nie ma żadnych błędów, w takim razie zastanów się, dlaczego są w Twoim kodzie. Musisz ciągle szukać, drążyć i rozwiązywać prawdziwe problemy. Samodzielnie, ale jednocześnie z pomocą innych - tych, którzy są już o co najmniej kilka kroków dalej, którzy nauczą Cię, czym jest czysty kod.

Czysty kod? Kolejne nowe pojęcie.

WM: Praca programisty polega przede wszystkim na czytaniu kodu. Robert C. Martin, znany w świecie IT jako Uncle Bob w książce pt. “Czysty kod. Podręcznik dobrego programisty” przytacza, że stosunek pisania kodu do czytania kodu wynosi 1:10. To znaczy że w ciągu godziny czas spędzony na pisanie kodu to zwykle około sześć minut, pozostały czas to czytanie tego, co napisali inni. Czytanie kodu, analiza, zastanawianie się nad tym, co napisali poprzednicy - to charakteryzuje dobrego programistę.

Stworzenie takiego kodu, który ktoś będzie z wdzięcznością czytał.  Żebyś - jak mówi pewna anegdota - mógł w nim zostawić swoje nazwisko i adres i nie bał się, że jakiś inny psychopatyczny programista odwiedzi Cię którejś nocy z bronią w ręku.

Efektywna nauka programowania polega na tym, żebyś od samego początku dbał o to, by Twój kod był czytelny nie tylko dla Ciebie, ale przede wszystkim dla innych. Żeby jego czytanie to była przyjemność, tak jak smakowanie dobrego wina z południowych Włoch, albo żeglowanie ostrym bajdewindem w południowym słońcu.

I naprawdę trzeba to umieć? Przecież jest tyle programów, automatycznych rozwiązań. Komputer nie zrobi tego za mnie?

WM: Postęp technologiczny nie zwalnia z myślenia. Nawet, a właściwie tym bardziej programistów. Automat sformatuje Twój kod, wylistuje błędy składni, a nawet niektóre poprawi, ale to Ty musisz mieć spójną wizję tego, co chcesz osiągnąć i w jaki sposób. Narzędzia programistyczne tego za Ciebie nie zrobią. Jeżeli wejdzie Ci to w krew, unikniesz w przyszłości niektórych błędów. Wszystkich nie, bo to niemożliwe, ale niektórych na pewno. Te pierwsze kroki stawiane w świecie IT to najlepszy test dla osób początkujących.

No właśnie, testy... Mówi się o nich za każdym razem, gdy ktoś pisze o nauce kodowania i o dobrych praktykach związanych z programowaniem.

WM: Bo to integralna część pisania kodu aplikacji. To jest trend, w kierunku którego zmierza świat. Definicja oddanego zadania obejmuje zarówno napisanie kodu, jak i testów. Ty sam masz przetestować swój kod i napisać taki test, który zabezpieczy kod przed naruszeniem go podczas późniejszych zmian. To wymusza dyscyplinę i kodowanie według dobrych praktyk. Wymaga to co prawda większych nakładów pracy, jest czasochłonne i bywa mozolne, ale dzięki temu mamy dużą pewność, że kolejne modyfikacje aplikacji w innych miejscach nie wpłyną na napisany kod i nie uszkodzą go.

Bardzo to wszystko męczące… W pewnym momencie może pojawić się zniechęcenie. Co wtedy?

WM: Zniechęcenie, czyli spadek motywacji. Może być przejściowy (wszyscy mamy gorsze dni), lub być wynikiem dłuższych procesów. Można mu przeciwdziałać w różny sposób, ale celem jest powrót do systematyczności nauki. Czasem - jeśli coś Cię bardzo wciągnie - wpadasz w wir zainteresowania i możesz nad tym przesiedzieć nawet do rana bez snu. Działasz na adrenalinie, nie czujesz zmęczenia. Ale lepiej jest się uczyć codziennie przez godzinę, niż raz w tygodniu zarwać noc.

Matką uczenia się jest powtarzanie. Poprzez powtarzalność wyrabiasz sobie pewne nawyki i uczysz się schematów, które później zaowocują. Ucząc się przez 7-10 godzin na raz, ale tylko raz w tygodniu, możesz poczuć satysfakcję, euforię, odkryjesz trochę fajnych rzeczy, ale to potem ulatuje. Takie nagłe strzały, skoki choć są atrakcyjne emocjonalnie to niekoniecznie przekładają się na wyniki, jakie daje systematyczna nauka. Spontaniczność i brak uporządkowanego rytmu nauki nie jest zbyt owocne pod kątem skuteczności. Baterie się szybko wyczerpią i czasem nawet ktoś, kto miał odpowiednie predyspozycje do kodowania, może odpaść z gry.

Jest jakiś złoty środek? Co sugerujesz jako psycholog?

WM: Dość dobrze obrazują to prawa opisane przez panów Yerkesa i Dodsona, przedstawione na dwóch wykresach. Wynika z nich bardzo prosta zależność - że dla każdego typu zachowania istnieje optymalny poziom pobudzenia. Jeśli zadanie jest łatwe, powtarzalne, znane, wtedy zaczyna Cię nudzić. I dlatego pobudzenie, ale oczywiście nie za duże, jest wówczas wskazane. To może być jakaś ostrzejsza muzyka na słuchawkach, albo po prostu kawa.

Jeżeli natomiast uczysz się rzeczy nowych, nieznanych, trudnych -wtedy powinieneś się wyciszyć i skupić. W takich warunkach poziom wykonania zadania jest najlepszy, a nauka będzie efektywna. Gdy uczysz się czegoś nowego, ten stopień pobudzenia powinien być niższy. Gdy robisz coś, co już znasz, jest łatwe, chcesz sobie to np. tylko odświeżyć, możesz się trochę „nakręcić”.

A jeżeli po pewnym okresie nauki pojawia się faza zniechęcenia? Nie pomaga ani kawa, ani trash metal, żadnych efektów nie daje też drzemka i relaks w ciszy, w parku.

WM: To wtedy zadałbym pytanie, co się takiego stało, co się wydarzyło po drodze, że Ci się odechciało. A odpowiedzi mogą być bardzo różne. Może oczekiwałeś, że efekty powziętej decyzji przyjdą szybciej, niż to jest możliwe? Może nie spodziewałeś się, że potrzeba tak wiele wysiłku i czasu, by uzyskać efekt?  Po tym, jak napisałeś swoje pierwsze “Hello World” i poczułeś przypływ mocy, myślałeś, że po dwóch miesiącach będziesz wybitnym koderem? Może warto wtedy porozmawiać z doświadczonymi programistami? Zapytaj o ich początki, a opowiedzą Ci o swoich, często podobnych doświadczeniach. Pokażą Ci, że chociaż perspektywa jest szeroka i odległa, to każda godzina siedzenia nad kodem to kolejny krok w długiej podróży - i jesteś o metr bliżej.

A może rozczarował Cię feedback od mentora, który za mało Cię pochwalił? Z feedbacku rodzą się zmiany, korekty. Warto widzieć w nim narzędzie do rozwoju, a nie do umacniania się w przekonaniu o swojej świetności. Zwłaszcza umiejętność korzystania z negatywnych informacji zwrotnych jest świetnym narzędziem do rozwoju - jakiejkolwiek umiejętności. Oczywiście, jeśli feedback składa się tylko z negatywów, to albo jest coś nie tak z Tobą, albo z Twoim rozmówcą.

A może na przykład dałeś sobie w życiu za mało przestrzeni, może próbujesz robić za dużo rzeczy na raz, jesteś przemęczony? Być może mówisz, że nie masz tyle czasu, ile potrzeba. Prawda jest natomiast taka, że czas mamy zawsze, ale na rzeczy ważne dla nas. Każdy ma 24 godziny. To od niego zależy, na co je przeznaczy. Jeżeli nie masz czasu na naukę programowania, to może nie jest ona dla Ciebie aż tak ważna, jak myślisz lub mówisz.

Dobrze mieć wtedy przy sobie kogoś, kto skonfrontuje to, co mówisz, z tym, co robisz. Być może to pomoże tak przeorganizować sobie życie i hierarchię ważności spraw, żebyś mógł zacząć wspinać się wyżej.

Ciągła wspinaczka…

WM: W dodatku po ruchomych schodach, które jadą w dół. Musisz ciągle iść, bo jeśli się zatrzymasz, zjedziesz razem z nimi. Wszyscy dookoła mówią Ci, że musisz się ciągle rozwijać. Bo to jest prawda. Niewiele jest dziedzin takich jak IT, w których tak szybko następuje postęp i tak szybko pojawiają się kolejne zmiany. Jeśli się zasiedzisz, będziesz musiał gonić pociąg.

Lepiej już wspinać się konsekwentnie na tę górę, ale i z tym jest pewien problem. Bo osoby początkujące myślą, że droga na szczyt biegnie w linii prostej, której część można pokonać kolejką linową np. o nazwie „copy paste Stack Overflow”. Tymczasem po przejściu pewnego odcinka okazuje się, że trzeba tę górę najpierw obejść, żeby znaleźć ścieżkę, a potem jeszcze ze cztery razy okrążyć, a kolejki linowe albo jadą często w zupełnie w innym kierunku, albo nie ma ich wcale.

A gdy już na nią wejdziesz? Co tam jest? Nagroda?

WM: To zależy… Bo to nigdy nie jest tylko jedna góra. To nie jest jedno wyzwanie. Ich jest wiele. A czy jest nagroda? Dla każdego nagrodą będzie co innego. Dla jednego dobra praca, dla innego dobra kasa, możliwość zaspokajania ciekawości, możliwość rozwoju, uczenia się czegoś nowego. Komuś zależy bardziej na dobrych relacjach z ludźmi z pracy, dla wielu będzie to mieszanka tych wszystkich elementów.

W trakcie kodowania zyskujesz nowe perspektywy, nowe obszary wiedzy, nowe umiejętności, możliwości na rynku pracy - i to jest właśnie Twoja nagroda. A te drinki z palemką na słonecznej plaży na Bali sączone podczas nudnego koderskiego dnia… to już tylko skromny, nieistotny dodatek :)