Hej,
Jak wyglada u was kwestia dokształcania się po pracy. Czy regularnie wczytujecie sie w ksiazki/artykuly powiazane z technologiami w ktorych pracujecie? Kodujecie jakies wlasne projekty, czy raczej juz Wam sie nie chce po 8h zawodowego klepania kodu?
Jakie macie sposoby na zmotywowanie i skoncenteowanie sie na "popoludniowej" nauce?
W moim przypadku jeśli chodzi o dokształcanie się czysto teoretyczne to tak, dokształcam się regularnie i w zasadzie niezależnie od pory dnia. Nawet w czasie pracy kied znajdę chwilę (bo np. czekam na build) to czytam jakieś artykuły czy też programistyczne wiadomości.
Co do kodzenia samego w sobie to staram się poświęcić na to przynajmniej kilka godzin w tygodniu, choć będąc od 10 miesięcy szczęśliwym ojcem coraz trudniej znaleźć wolny czas. Zacząłem nawet robić coś co kiedyś było dla mnie nie do pomyślenia, i siędzę "po nocach". Robię jakieś poboczne projekty lub tutoriale z nowych (w sensie nowe dla mnie) technologii. Co ciekawe to w moim przypadku zapał do takiego dodatkowego kodzenia po pracy czy też w weekend jest cykliczny, i np. mogę mieć 2 tygodnie gdzie bardzo mało lub w ogóle nie dodykam kodu, nie mam najmniejszej ochoty, tylko po to by później przez kolejne dwa tygodnie mieć ogromny zapał i wciągać się w kodzenie. I tak w kółko. Co za tym idzie- nie zmuszam się, nie robię nic na siłę i czekam aż motywacja sama przyjdzie.
Jakieś ciekawostki artykuły tak. Ale coraz częściej znaleźć mi czas i siły na coś bardziej złożonego i zaawansowanego.
Obecnie działam tak:
Prowadzę notes w ramach, którego notuje pytania, potknięcia jakie zaliczam, a które z czasem prowadzą do ciekawych wniosków. Próbowałem podobnych rzeczy robić z użyciem internetowych aplikacji, ale sęk w tym, że lepsze myśli mam poza komputerem. Poza tym notes to dobre miejsce na szybkie szkice.
Nagrywam ekran jak koduję. Nagrywanie ma dwa atuty. Pierwszy to większe skupienie, nawet jak mam jakiś problem w kodzie, który mnie nuży/gryzie to trudniej jest mi się rozproszyć, po prostu daję z siebie więcej niż normalnie. Samo oglądanie to trudniejsza część, ale to najcenniejsza lekcja móc zobaczyć siebie z innej perspektywy, zobaczyć sposób rozwiązywania pracy ponownie. W przypadku wielu problemów, taka sesja pokazuje gdzie popełniłem rażące błędy.
Mało jest dobrych książek więc stosunkowo mało czytam. Z drugiej strony książki i tak kupuję, bo są tanie. Mniej więcej 90% treści zostawiam sobie na później. Jak kupię książkę to przeznaczam część wieczora na przeskanowanie jej treści, zwrócam uwagi na kluczowe sekcje, i jak coś mnie zaciekawi to czytam, a jak nie to nie. W zasadzie do książek to najczęściej wracam jak nad czymś się zastanawiam, wtedy kojarzę podobny temat jaki widziałem w jednej z książek i wracam do niej na chwilę.
W przypadku czytania to regularnie czytam projekty. Bywa też tak, że czytam projekt w języku którego w ogóle nie znam, ale na ogół dobry projekty charakteryzuje to, że taki kod jest stosunkowo lekki w odbiorze. Mogę w ten sposób więcej zrozumieć, przekonać się do innych rozwiązań. Z czasem przestałem trawić artykuły, blogi bo lokalni eksperci też się uczą i wychwalają jakieś rozwiązania, albo je negują. Najlepsze jest to, że ich zdanie się z czasem się zmienia więc wtedy to ja na tym najwięcej tracę.
Od czasu do czasu pomagam w nauce różnym osobom. Ucząc, dwie rzeczy nadrabiam. Pierwsza to analizowanie podstaw na których bazuje, wtedy sam sobie zadaje pytania o jakich wcześniej nigdy nie myślałem, wstyd przyznać ilu rzeczy jeszcze nie wiem. Druga to fakt, że tą wiedzę kolejno trzeba przedstawić, najlepej tak, by osoba sama dostrzegła swój problem. Wiele osób nie myśli nad tym co robi, woli uderzać głową o ścianę, zamiast ocenić przypadki z jakimi pracuje. Gdy znasz odpowiedź i ścieżkę, która do niego prowadzi to wszystko wydaje się banalne. Najgorsze w tym było to, gdy sam sobie uświadomiłem, że w mojej pracy wcale nie jestem lepszy. Dlatego częściej próbuje patrzeć na moje problemy z innych perspektyw, próbuje wyodrębniać przypadki, by zauważyć elementy sygnalizujące poprawne rozwiązanie.
Mam też obszary, które dopiero co poznaję więc tam musiałem wypracować sobie inne podejście.
Bazowo wykonuje dużo prostych ćwiczeń, robienie ćwiczeń jest nudne. Dlatego tutaj pewną część obejmuje wymyślanie przypadków na jakie chcę poznać odpowiedź. Wnioski notuje w zeszycie.
Zauważyłem, że w wielu rzeczach jakie już znam i umiem występują skrajności - one nie są moją odpowiedzią, ale ta odpowiedź leży pomiędzy nimi. Można być zwolennikiem jakieś techniki, a po drugiej stronie brzegu okazuje się, że panuje zupełnie oddmienny styl robienia tego samego. Zamiast skupiać się na jednej stronie, lepszym podejściem wg mnie jest poznawnie obu brzegów. Wtedy więcej pytań wychodzi, wtedy łatwiej jest zrozumieć o co tak naprawdę się rozchodzi.
Po przysłowiowych ośmiu godzinach, zawodowego kodzenia, miałem serdecznie dosyć czegokolwiek co związane było z programowaniem.
W tym zawodzie tak już bywa. Praca na etacie rozwinie Twoją pasję albo ją zamorduje. Jeśli się wkręcisz to będziesz siedział po fajranice. Jeśli nie... prędzej czy później dasz sobie spokój z programowaniem.
Pracuję w embedded, po pracy staram się rozwijać w równoległych tematach (analogowy hardware, różne symulacje, trochę fizyki) robiąc swoje projekty. Często zdarza mi się, że piszę w nich jakiś soft (np. firmware), ale generalnie mało czasu na to schodzi. Jeśli coś czytam to rzeczy które potrzebuję do realizacji jakiegoś swojego projektu.
Myślę, że po pracy nie powinno się robić tych samych rzeczy, jakie się robi w pracy.
Ludzie inteligentni się nie dokształcają tylko podejmują decyzje i wyciągają wnioski (albo wnioski wyciągają ich).
PS: Czasu jest niewiele.
Jak mi się chce to się rozwijam jak nie to nie. Jeżeli postanowię sobie zwiększyć swoje kwalifikacje to się uczę, inaczej mi się nie chce. Do tej pory pomagały mi studia, np praca inżynierska o tematyce programistycznej itd.
Pomaga w tym trwanie w różnych forach. Chodzenie na konferencje, albo oglądanie jakichś wykładów.
Coś tam też przygotuje, żeby do oceny rocznej w korpo powiedzieć i dostać podwyżkę a tak to nic.
Ja używam aplikacji ticktick, wrzucam tam sobie do ogólnej listy rzeczy które chciałbym poznać/przerobić (często z linkami do konkretnych materiałów) i potem sobie wrzucam takie taski na konkretne dni (powiadomienia na tel bardzo mnie motywują przypominając że mam co robić danego dnia i co ważniejsze wiem co mam robić).
Akurat mam okres w którym mam "zajawkę" i poświęcam sporo wolnego czasu na naukę, również czas w pracy, więc:
Ostatnio też kombinuję nad bardziej optymalnym sposobem notowania "ścieżki nauki", bo zauważyłem, że o ile po przeczytaniu jakiejś książki zostaje mi sporo w głowie, o tyle jak już chciałbym wrócić do tematu bo coś mi "świta", to nie wiem z jakiego źródła jest ta konkretna informacja. Padło na mapę myśli (MindMap) w której każdy miesiąc to nowa gałąź i do takiej gałęzi dopisuję to co przeczytałem/obejrzałem wraz ze skrótem informacji które wyniosłem. Czyli: obejrzałem kurs DDD, dowiedziałem się czym jest bounded context, agregat, serwis domenowy, itd. więc notuję to na mapie myśli i jeżeli w przyszłości będę chciał do tego wrócić to CTRL + F -> Agregat i wiem że uczyłem się tego tu, tu i tu.
Czytaj to co Cię ciekawi, nie ma sensu się pchać w rzeczy, które Cię zupełnie nie obchodzą ani nie interesują, życie jest za krótkie. Obecnie żyjemy w takich czasach, że jest przesyt informacji wszelkiej maści, na każdy temat jest tona materiałów, tutoriali, filmików, ale głowa by odpadła jakbyś chciał zgłębić wszystko. Skup się na swoich zainteresowaniach i staraj się nie rozpraszać na rzeczy zupełnie zbędne.