admin 0Comment

Nigdy nie uważałem, że samodzielna nauka programowania jest najbardziej optymalną drogą. Może taką być, tyle, że nie dla każdego. I tylko do pewnego momentu.

Jestem przekonany, że każdy sposób nauki ma swoje minusy. W przypadku programowania, jak już pisałem wcześniej, możemy uczyć się w bardzo różny sposób – od studiowania przez kilka lat na kierunku informatycznym, przez samodzielną naukę, po kilkutygodniowe bootcampy. Każdy z tych sposobów z różnych perspektyw może być festiwalem kompromisów.

Dzisiaj napiszę kilka słów o wadach samodzielnej nauki, bo w przeciągu ostatnich miesięcy miałem okazję je, nieraz wielokrotnie, zaobserwować na własnym przykładzie. Niektórych można uniknąć, z niektórymi walczyć, a z innymi wreszcie należy się po prostu pogodzić, bo będą, i tyle. Lecimy!

 

Nie wiesz jak rozpocząć

 

Tak, początkowy zalew informacji potrafi być demotywujący, a nawet paraliżujący. Bo przecież na starcie o programowaniu najczęściej nie wiesz kompletnie nic. Pisałem o tym trochę tutaj więc, nie ma sensu żebym się ponownie rozpisywał. Ciężko jest uniknąć tego poczucia zagubienia na początku (a i pewnie później także), można jednak skrócić jego czas. By ci w tym pomóc powstał m.in. ten blog.

Moja rada? Nie poddawać się, ale też nie spinać za bardzo – nawet jeśli, próbując przyswoić informacje, masz wrażenie, że w głowie pozostaje ci tylko chaos, nie poddawaj się ale też nie narzucaj sobie nie wiadomo jakich wymagań od samego początku. Przygotuj sobie kawkę, czy co tam lubisz, siądź do laptopa, i poserfuj w sieci, pobłąkaj wokół danego tematu. Wiem, że na początku będzie to wyglądało jak równanie z samymi niewiadomymi, bo, nawet, jeśli trafisz na jakiś sensowne źródło wiedzy, to już sama nomenklatura wywoła konsternację, ale z czasem zacznie ci się rozjaśniać w głowie. I postaraj się nie tracić frajdy z tego, że uczysz się czegoś nowego.

 

Nie wiesz, czy sposób, w jaki się uczysz, jest efektywny

 

Za dużo teorii? A może właśnie za mało? Narzucasz zbyt duże tempo, a może właśnie zbyt rozmieniasz się na drobne? Może jednak powinieneś wgryźć się w tamtą książkę, którą odpuściłeś po pierwszych dwóch rozdziałach?

Brakuje ci doświadczonego spojrzenia z boku, czy chociaż porównania twoich postępów z postępami innych. Nie wiesz, czy idzie tak jak powinno. Bo, że jest ciężko, to wiesz, ale też i nastawiałeś się na to.

Rada? Prawda jest taka, że jeśli nie jesteś w stanie zrewidować na bieżąco tego, czy uczysz się efektywnie, to prawdopodobnie tak nie jest. W jaki więc sposób to rewidować? Zdecydowanie pomaga praktyka, i to ona powinna nadawać rytm, kierunek i tempo twojej nauce. Wróć do problemów, jakie napotkałeś jakiś czas temu, a których nie udało ci się wtedy rozwiązać. Czy jest to teraz możliwe? Zerknij do kodu, który napisałeś iks dni, tygodni czy miesięcy temu – jeśli nie krzywisz się na jego widok to albo jesteś bezkrytyczny w ocenie swojej pracy, albo też jest coś nie tak z efektywnością twojej nauki. Zerknij do praktycznych projektów (a jeśli po dłuższym czasie żadnych jeszcze nie masz, to nie, nie uczysz się efektywnie), które napisałeś i zobacz czy wykorzystujesz narzędzia i metody, które opanowałeś, czy  też opanowujesz je dla zasady i odhaczenia, nie korzystając z nich w praktyce.

 

Nie wiesz, kiedy przestać zagłębiać się w dany temat

 

Praktyka praktyką, ale po prostu trzeba najpierw przysiąść do teorii, żeby zadziałało to, co potem wyklepiesz. No i właśnie…kiedy od tej teorii wstać? Już opanowałem dane zagadnienie czy jeszcze jestem w lesie? Ciężka sprawa, bo z boku nie ma nikogo, kto powie ci, że wystarczy, możemy przejść dalej. Jak możesz stwierdzić, że „to” opanowałeś, skoro wiesz, że, realnie, tylko poskrobałeś po powierzchni? W samodzielnej nauce raczej nie uciekniesz od tego problemu, możesz go tylko próbować minimalizować.

Ta odpowiedź wydaje się być motywem przewodnim tekstu, ale – niech powie ci to praktyka. Najłatwiej, jeśli to, nad czym aktualnie pracujesz, wyznacza ci poziom, w jakim powinieneś opanować dane zagadnienie czy narzędzie. Czyli, raz jeszcze, nauka w trybie JIT – Just In Time. Wtedy, kiedy trzeba, bo cel tego wymaga.

A nieco bardziej abstrakcyjnie – roboczo możemy przyjąć, że „opanowałeś” wstępnie dane zagadnienie, jeśli potrafisz korzystać z jego podstawowych funkcji i wiesz, jak praktycznie go zastosować w nieszczególnie skomplikowanych przypadkach.

 

Trudniej zrewidować jakość tego, co już stworzyłeś

 

Zwłaszcza, kiedy nie jesteś już absolutnie początkujący i twój kod potrafi być już relatywnie długi (co nie znaczy, że idzie za tym jego klarowność). Pewnie, że w sieci są miejsca, gdzie możesz wrzucić swój kod, zapytać o rozwiązanie jakiegoś problemu. Tyle, że twoje problemy i wątpliwości to już nie błąd kompilacji przy helołorldzie, bo ci się średnik zagubił. Stosunkowo niewiele osób będzie chciało zadać sobie trud i przejrzeć twój większy projekt, a jeszcze mniej wyrzuci z siebie cokolwiek poza niekonstruktywną krytyką, niestety.

Raczej nie wrzucisz grubszego projektu na stackoverflow z prośbą, „oceńcie czy piękny”, prawda? Pół biedy, jeśli wrzucisz go z pytanie „oceńcie czy jebnie”, to jest łatwiejsze, ale dużo trudniej przekonać kogokolwiek do sprawdzenie naszego kodu pod względem designu. W momencie, kiedy wychodzisz już poza problemy „jak zrobić to i tamto” i wchodzisz w zagadnienia „Wiem, jak zrobić to by działało, ale jak zrobić to optymalnie?”, przestają one być zero-jedynkowe, i różnica między fajnym i słabym kodem mocno się rozmywa. Dodatkowo, przy każdym wyjściu z kodem „na świat”, musisz pokonać opór wewnętrzny będący wynikiem obawy przed narażeniem się na krytykę i krytykanctwo.

Rada? Niestety, nikt nie mówił, że będzie łatwo. Próbuj, aż do skutku, jako wannabe – programiści i tak możemy powiedzieć, że mamy szczęście, ponieważ istnieje jeden serwis, który odpowie na 99% naszych wątpliwości (i niedawno słyszałem określenie, że stajemy się w ten sposób „full stack-overflow developerami”. Heheszki).

 

Brakuje ci zewnętrznej motywacji

 

Wiadomo – to twoja WEWNĘTRZNA motywacja jest tą, której nie powinno ci zabraknąć, jednak zewnętrzna motywacja pomaga nie wypalić się z czasem tej pierwszej. Choćbyś nie wiem, jakie metody stosował, nauka tydzień po tygodniu stanie się w pewnym momencie procesem żmudnym, i tyle.

Rozwiązanie? Nie trać z oczu celu ogólnego, jaki sprawił, że uczysz się programowania (bo masz taki cel. Prawda?). Chcesz stworzyć program czy stronę, którą wymarzyłeś sobie jakiś czas temu? A może chcesz zmienić branżę, bo ostatnia nudziła cię już śmiertelnie i nie czułeś, że się w niej spełniasz?

Przy okazji określać również (i także nie trać z oczu) cele pośrednie – mniejsze projekty, opanowanie danego narzędzia etc. No i, kurcze, nie bądź swoim najgorszym wrogiem – nagradzaj się czasem za twoją ciężką pracę!

 

Dodaj komentarz