Zdałem sobie sprawe jak szybko zapominam. Wystarczy parę miesięcy nie pisać w jakiejś technologii i człowiek się dziwnie czuje.
Jak odkurzyć sobie tą wiedzę? Przejrzec tutoriale? Swój poprzedni kod?
Domyślam się że macie taką sytuację że w pracy nie używacie wszystkich technologii, które znacie, i zdarzają się krótsze lub dłuższe przerwy w używaniu. Czy w związku z tym piszecie coś, by tylko nie zapomnieć? Czy może jesteście na bieżąco głównie poprzez czytanie?
To samo w kwestii nowych technologii których nie używacie w pracy. Wymyślacie na siłę jakiś temat żeby poćwiczyć dany framework czy jak działacie?
Pytam tak bo nie wiem jak się mam dalej rozwijać, by było to z głową. Zwłaszcza przeraża to zapominanie, z którego dopiero niedawno zdałem sobie sprawę.
To jest naturalny (i korzystny) proces. Natura wyposażyła nas w optymalizację. Jeśli czegoś nie używamy to jest to redukowane. Odpowiedzią na to jest ciągłe powtarzanie, utrwalanie wiedzy, aby nie zanikła. Najlepszym kierunkiem, aby odnieść korzyść w walce z "zanikiem" wiedzy jest wąska specjalizacja. Zastanów się czy szukając sklepu ze śrubami interesują cię ciastka z rodzynkami na przykład. Tak samo firmy szukające np. programisty node.js szukają specjalisty w tym temacie, a nie "kurczaka", który potyka się o własne nogi.
Ja bym postawił na specjalizację i ogólne rozeznanie się w pozostałych tematach. Poza tym majac XX lat doświadczenia, nikt nie będzie od Ciebie oczekiwal znajomości tematów z N technologii na poziomie implementacji. Tzn. niektórzy będą wymagać, ale to są albo najlepsze firmy na rynku, albo chorzy umysłowo, niespełnieni zawodowo ludzie :D
Ja osobiście robię "notatki" jako mapę pojęć + opisy w aplikacji (webowej, super-prostej) o nazwie coggle - www.coggle.it - pomoże Ci ona zapanować nad chaosem pojęć w głowie. Nie uchroni natomiast przed zanikiem wiedzy "z pola walki" tzn. umiejętności programowania w danym temaci i tak zanikną jeśli nie będziesz praktykował
Co do zdobywania wiedzy - tzw. side projects (własne/cudze projekty robione po godzinach) - nie ma nic lepszego i nie ma co filozofować nad sensem tego. Praktyka czyni mistrzem.
Dzięki za odpowiedź
A co polecasz, robienie małych projektów skupionych na tym by dany fragment frameworka poznać czy raczej dużych, godząc się na to że tylko niektóre kwestie się poruszy? Zauważyłem że duże projekty zabierają niewspółmiernie dużo czasu, i programując dziennie 8h w pracy przy wielkich projektach, po pracy już się nic wielkiego robić nie chce... No i też się zastanawiam, skoro to tylko dla samorozwoju, to czy opłaca się kończyć projekty? Bo żeby coś było "gotowe" to należy poświęcić sporo czasu który niekoniecznie będzie rozwojem tylko zwykłym boilerplate w dziedzinie czasu. Jak szedłem do pracy to myślałem "github, portfolio" ale jak się ma już doświadczenie to mało kto na to patrzy, więc sam zadaje sobie pytanie, jak robić projekty, by było to dla mnie rozwijające, a nie dobrze wyglądało na githubie.
Pozwolę sobie zaprosić do wątku parę osób bo jestem ciekawy też jak oni to widzą @Shalom @aurel @somekind
Frameworki/technologie itd to tylko narzędzia, można sobie zawsze wiedzę odświeżyć jak będzie trzeba lub sie douczyć w razie potrzeby. Większe znaczenie ma algorytmika, projektowanie itp, a to raczej nie jest podatne na zapominanie w pracy IT. Chyba ze masz pecha i robisz w utrzymaniu.
Co do zdobywania wiedzy - tzw. side projects (własne/cudze projekty robione po godzinach) - nie ma nic lepszego i nie ma co filozofować nad sensem tego. Praktyka czyni mistrzem.
Jestem tego samego zdania. Projekty po godzinach to tak naprawdę esencja programowania.
Zdałem sobie sprawe jak szybko zapominam. Wystarczy parę miesięcy nie pisać w jakiejś technologii i człowiek się dziwnie czuje.
Jak odkurzyć sobie tą wiedzę? Przejrzec tutoriale? Swój poprzedni kod?
pewne rzeczy czasem ciągle się zapomina. Np. jak programowałem w PHP, to zapominałem kolejności parametrów needle i stack. Teraz zdarza mi się w CSS zapominać np. kolejności wartości wlasciwości padding dla dwóch lub trzech parametrów. W JavaScripcie zapominam czy funkcja się nazywa toUpperCase czy toUppercase albo zapominam rzeczy z konkretnych bibliotek (np. jak coś zrobić w jQuery).
Tylko, że to akurat niegroźne zapominanie, bo odpowiedzi na takie rzeczy można znaleźć w około 10 sekund.
Gorzej jak się zapomina co dany kod miał robić, albo jak zainicjalizować bibliotekę/moduł we frameworku. Czasem jak długo czegoś nie używam to faktycznie dużo mi zajmuje przypominanie sobie. Dlatego można sobie robić notatki albo zapisywać jakieś istotne fakty. No i komentować kod w miejscach gdzie te komentarze są potrzebne (nie wszędzie są), albo napisać dokumentację.
Wymyślacie na siłę jakiś temat żeby poćwiczyć dany framework czy jak działacie?
Nie jestem masochistą. Nie ćwiczę frameworków na siłę. Zdarza mi się, że wezmę się za coś nowego, nowa biblioteka, nowy framework i robię jakieś hello worldy, albo nawet większy projekt, żeby wypróbować czy po prostu nauczyć się frameworka - ale imho nie ma sensu na siłę każdego frameworka sobie powtarzać. Ten czas można wykorzystać w inny bardziej sensowny sposób, tj. uczyć się całkowicie nowych rzeczy, a nie powtarzać stare (co i tak jest bez sensu, bo i tak po wyjściu kolejnej wersji frameworka np. za pół roku ta cała wiedza będzie już nieco nieaktualna).
. Poza tym majac XX lat doświadczenia, nikt nie będzie od Ciebie oczekiwal znajomości tematów z N technologii na poziomie implementacji
nie aplikowałem do takich firm, ale zawsze mnie rozbraja jak w ogłoszeniach jest napisane "biegła znajomość technologii X". Nie wiem kto może posiadać w ogóle taką znajomość (oprócz samych twórców, ew. ludzi z min. 10-15 letnim doświadczeniem).
Zauważyłem że duże projekty zabierają niewspółmiernie dużo czasu, i programując dziennie 8h w pracy przy wielkich projektach, po pracy już się nic wielkiego robić nie chce...
możesz ćwiczyć TDD. Wtedy możesz podzielić sobie pracę na małe części. I wtedy napisać np. jeden test case. Potem zaimplementować. Potem kolejny. Jak ci się będzie chciało. Jak nie to do znowu Facebooka itp.
edit: W sumie wujek Bob ma rację - że TDD pomaga utrzymać focus, nawet jak się człowiek łatwo rozprasza
Zapominanie - normalna rzecz. Kiedyś miałam takie loty, że np. postanawiałam sobie skończyć tutorial pythona. Skończyłam, fajnie było, fajny język - przez następne 2 lata nie napisałam w pythonie ani linijki. IMHO nie ma to sensu ;) Lepiej by było zarzucić sobie jakiś projekt i rozwijać wiedzę potrzebną do jego ukończenia. Dużo lepiej się zapamiętuje przez praktykę.
Ale i wiedzę nabytą przez praktykę również się zapomina - ale to nic, bo za każdym kolejnym podejściem do tego samego problemu idzie coraz szybciej. Np. gdy po raz kolejny zobaczę ten sam komunikat błędu, to już coś mi świta, że chyba rozwiązanie znalazłam tu czy tam. Albo czasem uda się zapamiętać frazę, która pozwoli znaleźć w google'u to co trzeba. Następnym razem, gdy trafię na ten sam błąd, już będę wiedziała co robić. Ciekawsze przypadki zapisuje sobie w issue trackerze i potem tylko wyszukuję po komunikacie.
Z resztą zawsze warto podeprzeć się dokumentacją ;) W programowaniu nie chodzi o to, żeby wykuć się rzeczy na pamięć. Tak się składa, że całkiem dobrze znam CSSa - nie przeszkadza mi to bardzo często wpisywać w google: "font-face example" czy "how to center div in div vertically" ;)
To jest tak samo jak z pływaniem - generalnie nie zapomnisz, jak się pływa. Im częściej będziesz pływać danym stylem, tym lepiej będzie szło. Jak będziesz pływać innymi stylami, to też to pomoże, choć nie tak bardzo. Jak przestaniesz pływać, to z czasem technika spadnie, kondycja siądzie - ale gdy znów wskoczysz do basenu, popłyniesz.
Zauważyłem że duże projekty zabierają niewspółmiernie dużo czasu, i programując dziennie 8h w pracy przy wielkich projektach, po pracy już się nic wielkiego robić nie chce... No i też się zastanawiam, skoro to tylko dla samorozwoju, to czy opłaca się kończyć projekty?
Dobrym sposobem na motywację jest robić projekty za pieniążki - podpisujesz umowę i już MUSISZ skończyć :P
Zaczynaj dzień od prostego i krótkiego Code Kata w jakiejś "nie pracowej" technologii. Codziennie innej. Byle by tylko pokrywała podstawowe elementy języka.
moim zdaniem zapominanie to pozytywna rzecz
ważniejsze od braku zapominania jest szybsze uczenie się
jak zapomniałem to znaczy że mogę się nauczyć tego jeszcze raz
nie ma sensu sobie przypominać codziennie czegoś z czego się nie korzysta bo kiedyś może jednak się skorzysta - szybciej nauczyć się tego na nowo gdy nadejdzie potrzeba - za drugim razem uczy się szybciej i ma się świeższe podejście - można zrozumieć coś czego się wcześniej dokładnie nie rozumiało, dzięki doświadczeniu które się zdobyło w międzyczasie przy czymś zupełnie innym
Zauważyłem że duże projekty zabierają niewspółmiernie dużo czasu, i programując dziennie 8h w pracy przy wielkich projektach, po pracy już się nic wielkiego robić nie chce... No i też się zastanawiam, skoro to tylko dla samorozwoju, to czy opłaca się kończyć projekty?
Dobrym sposobem na motywację jest robić projekty za pieniążki - podpisujesz umowę i już MUSISZ skończyć :P
Druga dobra metoda to robienie czegoś, co się nam samym przyda. Np. program narzędziowy, który ci pomoże w codziennej pracy. Wtedy robisz z motywacją, że robisz to dla siebie (a potencjalnie i dla innych osób, jak wrzucisz na jakiegoś GitHuba).
Inną metodą, której niestety nie próbowałem, jest zaangażowanie się w większy open source'owy projekt. Wtedy też byś nie robił czegoś ot tak, tylko to coś byś pisał, miałoby jakąś wartość dla innych.
EDIT:
a jeśli chodzi o samorozwój, to czy naprawdę dla samorozwoju programistycznego trzeba programować?
Można poczytać sobie coś o dobrych praktykach, architekturze, wzorcach. Pooglądać materiały na Youtube z różnych konferencji. Poczytać trochę z historii informatyki. Albo pouczyć się czegoś co każdy programista powinien poznać, czyli linuxa/unixa. Albo też potestować różne edytory i środowiska (łącznie z Vimem, trudno się nauczyć, ale jednak da się w nim zrobić fajne rzeczy), a potem wybrać najwygodniejszy. Albo poczytać o metodyce pracy i o skuteczności/efektywności. Nie tylko informatyczne książki przecież. Rozwój zawodowy programisty nie polega na samym programowaniu.
Najważniejsze, by nie zapomnieć w jaki sposób można sobie coś przypomnieć. A kartkę z napisem http://www.google.com można przykleić na dole monitora, i po kłopocie. :)
To nie jest tak do końca że coś się zapomina, bo wydaje mi się że pewne rzeczy gdzieś tam są zapisane w pamięci, tylko człowiek (na poziomie świadomym) nie zdaje sobie z tego sprawy. Mózg to jak wiadomo sieć neuronowa, ogromna ilość neuronów, działa w określony sposób.
Jakbyście tak dokładniej przyjrzeli się temu co robicie, to zauważycie że pewne rzeczy będziecie robili częściej niż inne. I właśnie to co jest częstsze będzie utrwalane, przypominanie czy też wkuwanie żeby tylko nie wyleciało czegoś co jest rzadko albo wręcz prawie nigdy nie używane to po prostu nonsens (nienaturalne, nieefektywne).
Optymalizacja polega na tym, że to co macie w pamięci a jest wykorzystywane często będzie powodowało to, że w ogóle całą aplikację pisze się prostu sprawniej (bo nie latacie po dokumentacji). A to co jest rzadko wykorzystywane? Nie ma problemu, zajrzycie sobie do dokumentacji. A niby na jakiej zasadzie działa w ogóle pamięć podręczna Windows? A zresztą jakie programy macie uruchomione jak piszecie jakąś aplikację? Kilka najważniejszych i najbardziej potrzebnych. I pewnie też tylko w tym czasie przechodzicie pomiędzy nimi za pomocą Alt-Tab a nie szukacie gdzieś tam z menu Windows czy Linux. Byłoby to po prostu nieefektywne.
First of all: nie ma czegoś takiego jak pamiętanie czy niepamiętanie, to nie są dane w komputerze, które istnieją lub nie i nie ma innej opcji. Pamięć człowieka jest skomplikowanym zagadnieniem i dzieli się na wiele typów, część z nich jest przydatna, część szkodzi, o części nie wiemy (jest w nie- i pod- świadomości), a o części myślimy, że wiemy itd.
No, ale dobra: trzymanie składni, API bibliotek, frameworków, konstrukcji, nazw funkcji itd. w pamięci długotrwałej jest szkodliwe. Lepiej nie pamiętać, na ogół jest to praktyczniejsze: jeśli coś ma siedzieć w cache przez 2 lata to lepiej, żeby tam nie siedziało i nie śmieciło, tylko zrobić update danych przed użyciem. W obecnych czasach mamy dostęp do dokumentacji i aktualnych informacji niemal non-stop i używanie wiedzy "zapamiętanej" sprawia, że używamy możliwe zdezaktualizowanych informacji. Przykład: używając Javy 1.6 jakiś czas temu pewnie pamiętamy, jak przefiltrować kolekcję. Robiąc to dzisiaj można użyć wyrażeń lambda i mieć ładniejszy i efektywniejszy kod. Nie ma nic złego w sprawdzeniu informacji przed napisaniem kodu - narzut czasowy nie jest wielki, a potencjalny zysk duży.