Kto stoi w miejscu, ten się cofa, głosi jeden z popularnych cytatów. Zasada ta niewątpliwie ma zastosowanie między innymi w branży IT, która nieustannie rozwija się, nie pozwalając programistom na zawodową stagnację. A zatem rozwój, postęp, bycie coraz lepszym – ale jak? Dziś przedstawię kilka pomysłów na realizację tego celu w oparciu o artykułu Jasona Rudolpha [1] oraz Richa Hickeya [2].
Spis treści
Droga wszechstronności
Problemem procesu stawania się lepszym programistą jest trudność w jego mierzalności. Sportowiec, aby móc określić się dobrym powinien osiągać wyniki na liczbowo określonym poziomie, np. być w stanie przebiec M kilometrów w N minut. W podobny sposób może on układać swój trening, stawiając przed sobą bardzo konkretne wyzwania, które albo uda się spełnić, albo nie.
Jak przełożyć taki sposób doskonalenia się na grunt programistyczny? W swoim artykule Jason zauważa, że tym, co różni kogoś przeciętnego w jakiejś dziedzinie od dobrego w niej jest przede wszystkim doświadczenie, jakie zdobył. Doświadczenie rozumiane jako suma pojedynczych unikalnych doświadczeń. Skoro zatem wiemy na czym polega różnica, najlepszym co możemy zrobić jest postępować zgodnie z poniższym algorytmem:
- Zidentyfikować doświadczenia, które rozwiną nas jako programistę.
- Wybrać jedno konkretne z nich do wykonania.
- Wykonać je (zdobywają tym samym „osiągnięcie”).
- Dokładnie przeanalizować to doświadczenie i wyciągnąć z niego wnioski.
- Powrócić do punktu 2., wybierając z listy nowe doświadczenie
Skąd wziąć taką listę? Najlepiej skomponować ją samemu, wykorzystując do tego propozycje innych programistów. Podstawowy zestaw achievementów do zdobycia Jason proponuje na liście, którą można znaleźć na jego GitHubie. W oryginalnym artykule znajdują się też linki do innych tego typu list. Sam oczywiście również pokusiłem się o dokonanie forka jednego z takiego zestawu wyzwań, poszerzając go o kilka elementów, oraz zaznaczając te, które uważam za spełnione. Zachęcam Was do tego samego – czyż wytyczenie dobrego planu rozwoju to nie początek sukcesu? 😉
Droga specjalizacji
Przestrzegam Was jednak przed zakończeniem owego planowania już na tym etapie. Zaproponowana w artykule Jasona ścieżka wydaje się mieć dużo sensu, ale po zastanowieniu się nad nią, trzeba ją raczej uznać za pewien uproszczony model. Garść krytycznych uwag na ten temat przedstawił Rich Hickey [2].
Nie kwestionuje on pozytywów płynących z obcowania z różnymi językami programowania, paradygmatami, algorytmami itp., ale poddaje w wątpliwość, czy ograniczający się do takiego postępowania sposób rozwoju prowadzi do mistrzostwa. Jako przykład podaje muzyka, który nie doskonali się, wciąż zmieniając instrumenty czy gatunki muzyczne, ale poświęcając się swojej specjalizacji.
Rich przekonuje, że zdobywanie wielu powierzchownych doświadczeń to nie sposób na to, aby zostać ekspertem. Za najbardziej uniwersalne umiejętności programisty można bowiem uznać dwie: umiejętność zdobywania wiedzy oraz rozwiązywania problemów. I tu pojawia się pytanie – czy łatwiej i skuteczniej doskonalić je przez osiąganie achievementów czy przez zdobywanie coraz to głębszej i bardziej specjalistycznej wiedzy w jednej dziedzinie? Odpowiedzią autora jest druga z opcji.
Połączenie?
Jak widać pomysły na stawanie się lepszym programistą są różne. Przeciwstawne czy może dające się jakoś połączyć? Wartościową lekturą, pomagającą w rozstrzygnięciu tego sporu są liczne komentarze z dyskusji, która toczyła się w serwisie Hackernews [3].
Jeden z użytkowników zauważa, moim zdaniem jak najbardziej słusznie, że problemem nie jest zaproponowany przez Jasona algorytm pięciu kroków, ale za szybkie przechodzenie z punktu 5. do 2. Może ono wynikać z wybrania zbyt prostego wyzwania, które nie skłania do dłuższego zajmowania się projektem i zagłębiania się w związane z nim zagadnienia. Zamiast tego programista ma ochotę przejść do czegoś nowego – ciekawszego.
Kluczowe jest zatem wybieranie odpowiednich projektów do realizacji w celu osiągania achievementów. Czy poznanie nowego języka lub frameworka to tylko nauczenie się jego składni, czy może pójście nieco dalej, próbując zrozumieć idee stojące za daną technologią i wewnętrzne mechanizmy pracujące „pod maską”? Moim zdaniem to drugie, a więc istotna jest odpowiednia definition of done dla programistycznych osiągnięć oraz wcześniejsze zastanowienie się nad właściwym zadaniem, które chcemy zrealizować, aby było ono na dostatecznym poziomie trudności.
Kolejna sprawa to traktowanie „skakania po tematach” jako zabawy, rozrywki służącej oderwaniu się od cięższych (lub nudniejszych) przypadków, z którymi zmagamy się przy codziennych programistycznych zadaniach. Jeśli zamiast na oglądanie kolejnego video na YT poświęcimy pewną część swojego wolnego czasu w ten sposób, to na pewno tylko pomożemy swej karierze, nawet jeśli wybierane projekty nie będą powalały stopniem swojego zaawansowania.
Na koniec moje ostatnie spostrzeżenie dotyczące rozwoju i wyboru tematów, którymi warto się zainteresować. Nierzadko zdarza się, że wykonując w pracy najrozmaitsze taski lekko zahaczamy o kwestie, których dobre zrozumienie wcale nie jest wymagane aby ukończyć przypisane zadanie. I to właśnie jest moment, aby w naturalny sposob zejść nieco głębiej. Bo moim zdaniem, aspirując do bycia dobrym programistą, nie wypada pozostawiać napotkanych tematów niezrozumianych.
Co sądzicie o przedstawionych w artykule sposobach rozwoju programisty? Który z nich jest Wam najbliższy? Zachęcam do dyskusji!
Źródła
- Programming achievements: How to level up as a developer, Jason Rudolph, 09.08.2011.
- Rich Hickey on becoming a better developer, Rich Hickey.
- HackerNews: On becoming a better developer.
- Moja lista programistycznych wyzwań (fork).
