W dzisiejszym poście proponuję wam jednak jedno z wielu możliwych rozwiązań tego jak w stosunkowo prosty sposób ogarnąć programistyczny chaos, przy okazji zachowując odpowiedni balans pomiędzy teorią i praktyką.
Przemek Smyrdek
2019-07-08
Rozmawiając z osobami wchodzącymi do świata programowania wielokrotnie spotykałem się z opiniami, że tematów i okazji na ich naukę jest tak dużo, że powoduje to więcej problemów niż korzyści. Pojawia się klasyczny paradoks wyboru, kiedy to liczba opcji jakie leżą na stole - wbrew pozorom - działa na naszą niekorzyść przy decydowaniu się na to “co dalej”.
Dodatkowo, od czasu do czasu spotykam się też z utartymi opiniami na temat wybranych aktywności w jakie angażuje się programista w trakcie nauki. A to konferencje są złe bo niski poziom prelekcji, a to Twitter jest zły bo to marnowanie czasu, a to wybrana technologia jest zła i lepiej przeznacz trochę czasu na coś zupełnie innego.
Mając na uwadze oba te problemy trudno się dziwić, że dla wielu z nas próg wejścia do programowania jest tak wysoki, że wiele osób decyduje się porzucić ten kierunek i po prostu zająć czymś bardziej przystępnym. W dzisiejszym poście proponuję wam jednak jedno z wielu możliwych rozwiązań tego jak w stosunkowo prosty sposób ogarnąć cały ten programistyczny chaos, przy okazji zachowując odpowiedni balans pomiędzy teorią i praktyką.
Przed wami mój “warstwowy model nauki programowania” (nazwa mocno robocza).
Patrząc z boku na cały świat programowania można odnieść wrażenie, że przed adeptami tej właśnie dziedziny informatyki stoi nieskończona liczba równych sobie możliwości pozyskiwania wiedzy. Bez problemów wymienimy kilkanaście dróg, które w lepszy bądź gorszy sposób nauczą cię programowania:
Dla wielu z nas programowanie zaczyna się na studiach, kiedy to pierwszy raz mierzymy się z językami takimi jak C++ czy Python. Inni omijają tę ścieżkę decydując się na bootcampy czy też kursy, które realizują po godzinach. Równolegle do takich rozwiązań możemy też decydować się na naukę z książek, śledzenie autorów wybranych rozwiązań w mediach społecznościowych czy uczęszczanie na konferencje celem pozyskania wiedzy o tym, co tak naprawdę jest istotą programowania. W końcu idziemy też do pierwszej pracy przeskakując na kolejne poziomy wiedzy o wybranym języku programowania czy technologii.
Pojawia się jednak problem - wiedząc, ile możliwości stoi przed kimś, kto wkracza do świata programowania, możemy głowić się nad tym, jaka jest ta jedyna i właściwa kolejność przechodzenia przez poszczególne etapy nauki i rozwoju programisty.
Czy szukanie pracy bez studiów to dobry pomysł? Czy konferencje, w momencie kiedy nie mamy odpowiedniego doświadczenia, to strata czasu i pieniędzy? A może zapisać się na ten bootcamp, który polecał znajomy? Czy na początek muszę przeczytać “Clean Code”? To nie są pytania, które wymyślam na potrzeby tego artykułu ale raczej historia oparta na faktach, czyli realnych pytaniach zadawanych przez realnych programistów.
Błąd, jaki popełniamy przy takim sposobie myślenia o nauce programowania polega na tym, że na programistyczną ścieżkę patrzymy jednowymiarowo. Myślimy o tym, na co poświęcać swój czas, tak jakby czytanie książki wiązało się z rezygnacją z kursów po wsze czasy.
Nie ma się co dziwić, że w takim modelu zawsze będziemy pytać tych bardziej doświadczonych o właściwy kierunek rozwoju, czy też o to, czy tematy, które mamy przed sobą, są warte przeznaczanego na nie czasu.
Zazwyczaj na tym etapie pojawiają się też następujące pytania:
Dzisiaj chciałbym pokazać wam jak ja sam radzę sobie z odpowiadaniem na te dwie kwestie.
Zastanawiając się nad tym, jak ja sam podchodzę do nauki programowania doszedłem do wniosku, że dla mnie szczególnie wartościowe są dwie rzeczy:
Zgodzicie się chyba, że brzmi to dość rozsądnie?
Myśląc o tym, jak zamodelować naukę programowania w oparciu o te dwie wartości, przypomniałem sobie pewien model znany ze świata sprzedaży i marketingu. Modelem tym jest lejek sprzedażowy. Lejek sprzedażowy to przedstawienie procesu sprzedaży i marketingu w postaci kolejnych, następujących po sobie etapów przez które przechodzą osoby zainteresowane naszym produktem (najpierw będą do prospekci, następnie klienci a na końcu być może fani) w taki sposób, aby na każdym etapie dostosować nasze działania do poziomu zainteresowania tym co oferujemy.
Pomyślałem, że jest to znakomita metafora do tego, jak wg mnie powinna wyglądać skuteczna nauka programowania. Jak to wygląda w praktyce? Ano tak:
Taki oto lejek nauki programowania daje nam kilka wskazówek co do tego, jak gospodarować swoim czasem oraz tematami których się uczymy, przy okazji dokładając do naszej nauki dodatkowy wymiar - wymiar zaangażowania.
Moment, w którym zrozumiałem, że zaangażowanie w wybrany temat nie jest równoważne kolejności w jakiej się uczę, był dla mnie naprawdę przełomowy. Ale po kolei…
Mój model nauki programowania zawiera w sobie kilka warstw, które czerpią mnóstwo inspiracji z tego, czego dowiedziałem się o procesie sprzedaży. Spokojnie spokojnie, to naprawdę temat dla programistów - wszystko będzie jasne jak tylko przejdziemy przez kolejne warstwy naszego lejka:
Warstwa świadomości to wszystkie aktywności na które decyduje się programista, którego interesuje otaczająca go rzeczywistość. Dzięki śledzeniu mediów społecznościowych, uczestnictwie w konferencjach oraz rozmawianiu ze znajomymi pracującymi przy innych technologiach jesteśmy w stanie trzymać rękę na pulsie zyskując wiedzę o potencjalnych kierunkach naszego rozwoju w przyszłości. W warstwie świadomości możemy “łapać się” mnóstwa tematów które będziemy zgłębiać stosunkowo płytko, albo wcale. Chodzi tutaj o to, żeby nie stracić z oczu innych kierunków rozwoju oraz być w stanie komunikować się np. z programistami, którzy pracują w innych obszarach naszej branży.
Niektóre z tematów które zauważymy w warstwie świadomości (np. usłyszymy o czymś na konferencji, albo przeczytamy na Twitterze) powalczy o nasze zainteresowanie. Kiedy to już nastąpi, to wybrany temat możemy zgłębić nieco bardziej szczegółowo niż te pozostałe. Możemy np. poczytać dokumentację wybranego języka programowania, możemy przyjrzeć się jego społeczności, albo zobaczyć jakie firmy pracują z daną technologią. W tej warstwie nie wiemy jeszcze ile czasu spędzimy z danym tematem, ale na pewno skupiamy tutaj coraz więcej uwagi na ściśle zdefiniowanym obszarze programowania.
Do tej warstwy przechodzą te technologie, pojęcia czy też praktyki, którymi jesteśmy już dość mocno zainteresowani i zaczynamy je porównywać z tym czego używamy obecnie. W tym momencie możemy się zastanowić nad konsekwencjami postawienia na dany język programowania, nad jego mocnymi stronami czy też nad okazjami jakie wiążą się z jego nauką (odpowiednia sytuacja na rynku, chęć przejścia do firmy która z nim pracuje, itd.). Warstwa porównania kończy swego rodzaju “teoretyczną analizę” wybranego tematu, bo dalej przechodzimy już do części praktycznej.
Ewaluacja to moment, w którym zaczynamy weryfikować dany temat w praktyce. Możemy np. rozpocząć pracę nad projektem pobocznym we frameworku, którego do tej pory nie mieliśmy okazji przetestować, możemy zgłosić się do hackathonu i zbudować MVP w oparciu o nową bibliotekę, czy też wymienić mały fragment istniejącego już systemu na rozwiązanie które chodzi nam po głowie. Zalecałbym tutaj to, żeby praktykę i testy wiązać ze stosunkowo niskim ryzykiem - na tym etapie wciąż jeszcze nie jesteśmy pewni, jak wybrana technologia sprawdzi się w warunkach produkcyjnych, z produkcyjnym obciążeniem i produkcyjnymi problemami.
Wszystko, co przechodzi do tego etapu wpisujemy w swoim profilu na LinkedIn w sekcji “umiejętności”. Etap działania to moment w którym nie obawiamy się wykorzystać danego rozwiązania w praktyce, zbadaliśmy jego mocne i słabe strony, zrozumieliśmy sposób działania i zaczynamy się w nim specjalizować. Rozwiązania w tej warstwie będą tematem książek które czytamy, prelekcji które oglądamy czy też tematów które naturalnie poruszamy z innymi programistami na podobnym stanowisku. Nasze zaangażowanie w dany temat będzie bardzo mocne, bo bezpośrednio będzie się wiązać np. z naszą pensją, pozycją w firmie czy statusem w wybranej społeczności.
Promowanie to warstwa dodatkowa, jednak przynosząca korzyści których nie sposób pominąć. Od czasu do czasu okazuje się bowiem, że wybrane zagadnienie pasjonuje nas tak bardzo, że chcielibyśmy podzielić się nim z innymi. Zaczynamy opisywać go na blogu, promować w trakcie prezentacji lub - jak to się czasami określa - ewangelizować innych w tym temacie (czyli po prostu być kimś więcej niż zwykły konsument). Aktywność w warstwie promowania bywa bardzo angażująca i czasochłonna, jednak zwrot z inwestycji jest naprawdę znaczący jeśli mowa chociażby o naszej marce osobistej, poznaniu innych specjalistów czy budowaniu sobie fundamentu pod kolejne lata kariery.
Dla mnie, jako front-end developera, nauka programowania wg tego modelu może być realizowana na przykład tak:
Wszystkie aktywności które dotyczą programowania, ale nie wymagają dużego skupienia czy uwagi to warstwa świadomości. Od czasu do czasu czytam blogi programistyczne, przeglądam Twittera, śledzę znanych autorów frameworków czy bibliotek, albo pojawiam się na konferencjach. Mój stopień zaangażowania w te aktywności jest jednak stosunkowo niski - jedna pominięta konferencja raczej nie zdecyduje o tym, gdzie będę za pięć czy dziesięć lat. Ta warstwa, jak już wspominałem wcześniej, pomaga mi poszerzać horyzonty oraz trzymać rękę na pulsie (a nuż zdecyduję się na back-end?).
W kontekście front-endu niektóre z poznawanych tematów interesują mnie jednak szczególnie mocno (warstwa zainteresowania) dlatego nieco bardziej uważnie obserwuję technologie podobne do tych z którymi pracuję, lub takie, które mogłyby je kiedyś zastąpić. W moim przypadku może to być np. Svelte, lub Nest.js. Na tym etapie niektóre z tematów o których się uczę są już odfiltrowane i traktuję je bardziej jako ciekawostkę niż narzędzie do mojej pracy.
Szczególnie blisko trzymam się wiedzy która może się bezpośrednio przekładać na moją pracę. Pomimo tego, że specjalizuję się w Angularze, to nowości Reacta czy Vue nie są mi obce. Często porównuję to jak obecnie realizuję projekty do tego, jak to wygląda w sąsiednich społecznościach, a wszystko to zaliczam do warstwy porównania (bardziej uważnej analizy).
Praktyka i ewaluacja to tematy, techniki i technologie, które uznałem za warte poświęcania czasu w kontekście pracy i mojej bieżącej sytuacji w programowaniu. Obecnie znajdują się tam np. Web Components oraz Stencil, które wykorzystuję w codziennej pracy, jednak tutaj moje krytyczne zasoby - czas oraz energia - wciąż nie są jeszcze wykorzystywane na sto procent. Są to tematy które w perspektywie kilku miesięcy zajmą prawdopodobnie znaczną część mojej pracy, więc już teraz przygotowuję się na mocniejsze ich stosowanie.
Warstwa działania (akcji) to Angular (no i może JavaScript jako taki), w którym mam zdecydowanie największe doświadczenie z wymienionych wcześniej tematów, pracuję z nim na co dzień i rozumiem go najlepiej. Mój stopień zaangażowania w te obszary programowania jest duży, jednak aby znaleźć czas na skuteczną naukę, ich liczbę muszę ograniczać najwyżej do kilku.
Promowanie, czyli warstwa ostatnia i opcjonalna, to np. blog który właśnie czytasz, moja prelekcja na której być może będziesz, albo podcast którego posłuchasz. Od kiedy wpadłem w sidła dzielenia się wiedzą to nie mogę z niego wyjść, dlatego właśnie na ilustracji powyżej określiłem to jako etap bez daty zakończenia. Jest to warstwa niesamowicie czasochłonna oraz angażująca, jednak przynosząca tak wiele korzyści, że po prostu nie mogę jej pomijać.
Warstwy, które tutaj opisuję, nie muszą oczywiście zawierać tylko i wyłącznie wymienionych wcześniej aktywności. Jeśli dla ciebie przeczytanie książki to coś, co wiąże się z niskim stopniem zaangażowania, to pewnie taka aktywność wyląduje w jednej z wyższych warstw (dla mnie jest to o wiele bardziej angażujące niż np. wstępne czytanie dokumentacji). Jeśli w pracy masz możliwość eksperymentowania z wybranymi technologiami i wdrażania ich do projektu bez zbyt dużego ryzyka, to również będzie to wyglądać nieco inaczej niż u mnie. Koniec końców w moim modelu nie chodzi o wrzucanie poszczególnych aktywności do kubełków o nazwie "Zainteresowanie" albo "Ewaluacja", ale o świadomość tego, że nauka odbywa się w dwóch wymiarach - zaangażowania oraz poświęcanego czasu.
Dzięki zamodelowaniu tego, jak ja sam uczę się programowania, moje spojrzenie na poszczególne aktywności składające się na naukę jest zdecydowanie bardziej uporządkowane.
Przykładowo, nie obwiniam się poświęcając czas na konferencję lub czytanie bloga (a są takie osoby) bo wiem, że jest to znakomity sposób na zrozumienie aktualnych trendów oraz problemów naszej branży. Wiem też, że muszę posiadać pewną dość niewielką liczbę tematów w których będę się specjalizował, bo dzięki temu zyskuję na pewności siebie oraz lepiej rozumiem swoją wartość. Dodatkowo, nie tracę czasu stojąc w miejscu i zastanawiając się co dalej, tylko rozważam to, jak bardzo zaangażowany w daną aktywność powinienem być - im mniej pewności, tym mniej zaangażowania, ale też więcej potencjalnie odkrywanych kierunków i możliwości.
To właśnie ten dodatkowy wymiar, czyli zaangażowanie, sprawia, że na aktywności którym poświęcam czas patrzę bardziej świadomie i nie obawiam się poprawnej kolejności ich realizacji. Tematy którymi się zajmuję są niejako “promowane” do kolejnych etapów wymagających większego zaangażowania, ale dzieje się to tylko wtedy, kiedy spełniane są wcześniej zdefiniowane kryteria (użycie biblioteki w pracy, realizacja projektu, wymaganie klienta, więcej argumentów w dyskusji, itd.).
Dodam też, że model, który tutaj proponuję, nie dotyczy samego początku nauki wybranego zagadnienia, ale pomaga też poruszać się po całej ścieżce zawodowej, która w programowaniu jest przecież jednym wielkim procesem uczenia się. Procesem, który wymaga wyrobienia w sobie pewnych nawyków oraz zachowań związanych z nieustannym rozwojem, a to nie zawsze przychodzi tak łatwo jak moglibyśmy sobie wyobrażać.
Oczywiście nie napiszę na koniec, że jest to model, który pomoże wam odnieść sukces, albo, że jest to jedyna ścieżka, którą możecie iść, ale wydaje mi się, że takie mapowanie nauki programowania na poszczególne warstwy to coś, czego być może brakowało niektórym z początkujących. Jeśli masz wyrobiony swój autorski sposób nauki programowania - świetnie, podziel się nim w komentarzu. Jeśli na razie improwizujesz, spróbuj wykorzystać mój model do tego czego aktualnie się uczysz - SOA #1 ;)
Co piątek rano dzielimy się sześcioma wartościowymi materiałami na dobry początek weekendu.
Dołącz do społeczności 2 tys. ambitnych programistów.
