👌😎W jaki sposób uczyć się z pracy😎👌

Kiedyś czytałem, że przeciętny człowiek uczy się w pracy jedynie przez pierwszy rok, a następnie, przestaje się rozwijać. Osoba która ma 10 lat doświadczenia i pracuje ciągle na tym samym stanowiska, prawdopodobnie może umieć mniej, niż ktoś kto pracuje tam rok. Jednocześnie, w większości zawodów, a w IT w szczególności, najważniejszą umiejętnością jest uczenie się nowych rzeczy. Jak to zrobić, by stale rozwijać swoje umiejętności?

Jeśli pracujesz, jesteś w uprzywilejowanej sytuacji jeśli chodzi o naukę, ponieważ raczej wiesz, z jakimi przypadkami możesz się zetknąć. Wiesz jakie technologie są używane w zespole, może nawet dochodzisz do wniosku, że niektóre nie sprawdzają się zbyt dobrze. W tym artykule opiszę, jak zacząć poprawiać swoje umiejętności, zaczynając od technologii które znamy i przechodząc do tych, które przydają się nam mniej.

Nasze słabe punkty

Pierwszy akapit i od razu z grubej rury...

W projekcie jest zwykle tak, że musimy jakąś funkcjonalność skończyć jak najszybciej. Powoduje to dług technologiczny. Napisaliśmy kod który działa, ale nie wiemy do końca jak, albo z daleka widzimy że rozwiązanie jest mało eleganckie. Albo napisanie jakiegoś niby prostego fragmentu kodu zajęło nam dużo czasu, bo np. brakowało nam wiedzy w pewnym obszarze języka.

Jeśli świadomie nie zajmiesz się takim obszarem, będziesz popełniał te same błędy za każdym razem.

Moja porada - zapisuj sobie wszystkie takie rzeczy na kartce i wrzucaj je na listę rzeczy do nauczenia, a następnie konsekwentnie się tego douczaj. Jeśli widzisz dług techniczny, szukaj sposobów na jego poprawę. Rób projekty demo, które pozwalają na wyćwiczenie danej umiejętności. Zajrzyj do dokumentacji, być może problem z którym się męczyłeś był już dobrze opisany. Taka analiza po napisaniu kodu jest ważna, ponieważ nie skupiasz się wtedy na rozwiązaniu problemu a na innych aspektach.

W tym obszarze warto zastosować jaką formę treningu, na przykład przerabianie zadań.

Ulepszenia

Czasem więcej dobrego wyciągniemy z ulepszania tego, co już mamy, niż z prób odkrycia czegoś zupełnie nowego.

W latach 70. James Dyson postanowił że stworzy odkurzacz o jakim światu się nie śniło. Wymyślił odkurzacz bezworkowy i poświęcił czas na ulepszenie każdego aspektu tradycyjnego odkurzacza. Powstała z tego firma warta ponad miliard dolarów.

Co by się stało, gdybyś codziennie ulepszył jedną rzecz w swoim projekcie, zaczynając od rzeczy kluczowych? Być może pewne struktury kodu są już przestarzałe, albo zdajesz sobie sprawę, że kod mógłby działać wydajniej. A może wprowadzenie jakiejś zmiany pozwoli użytkownikowi na wygodniejsze korzystanie, albo programiście na łatwiejsze tworzenie kodu. Albo może istnieje biblioteka (lub możesz napisać taką bibliotekę), która pozwoli na wyizolowanie pewnego obszaru kodu i mniejsze związanie go z obecnym…

Przykładem może być repo, https://github.com/ngneat, której autorzy opracowali między innymi Transloco do tłumaczeń w Angularze oraz Spectatora, ułatwiającego testowanie.

Nowe pomysły najlepiej wypróbowywać w swoich projektach lub w projektach typu greenfield, gdzie tworzysz coś nowego. Jeśli działają dobrze, można je wprowadzać na przykład w nowych funkcjonalnościach w obecnym projekcie.

Ostrzenie piły, czyli szlifowanie umiejętności

To pojęcie pochodzi z książki Stevena Coveya 7 nawyków skutecznego działania. Wytłumaczę to na moim ulubionym modelu, czyli na grze w szachy.

Załóżmy że już znasz zasady szachów, wiesz jak dać mata na kilka sposobów i chcesz zwiększyć swój poziom. W takiej sytuacji najgorsze co możesz zrobić, to … tylko grać w szachy. Jeśli chcesz grać lepiej, musisz przerabiać podręczniki szachowe, oglądać filmy na temat strategii i taktyki i robić ćwiczenia. Wtedy Twój poziom rośnie. Z biegiem czasu wybierasz coraz trudniejsze materiały.

Podobnie jest w programowaniu, jeśli tylko działasz na projekcie, albo się nudzisz powtarzalnymi taskami, albo frustrujesz się, bo stale coś Ci nie wychodzi. Często ten problem zauważam backendowców którzy zaczęli robić GUI. Próbują zmieniać kod CSS i zwykle nic z tego nie wynika, oprócz zdenerwowania. Tymczasem warto by najpierw zapoznać się z tym, jak coś działa a potem zmieniać.

Druga rzecz - jeśli programujesz długo w danej technologii, powinieneś co jakiś czas przeglądać dokumentację, aby przypomnieć sobie jak co działa. O niektórych rzeczach po prostu zapominamy.

Ciekawość

Bardzo dobrą cechą programisty jest dociekliwość, doszukiwanie informacji o tym, jak rzeczy działają. Warto robić to nawet wtedy, gdy dana technologia nie dotyka nas bezpośrednio. Przykłady - możesz np. sprawdzać jak działają pod spodem biblioteki, albo analizować działanie frontendu/backendu, nawet jeśli w nim nie pracujesz.
W programowaniu ciągle pojawiają się nowe rzeczy. Możesz się z nimi zapoznać na przykład zapisując się do kilku newsletterów. Dzięki takiej proaktywnej postawie zawsze będziesz miał do odkrycia coś nowego, a Twoja praca stanie się łatwiejsza i ciekawsza.

Podstawy - matematyka i algorytmy

Tutaj kryje się ogromna dawka niewiedzy. Czy wiesz, do czego używa się transformaty Fouriera? Albo czym są liczby urojone, lub jak liczy się cosinus? Czy pamiętasz jeszcze coś ze złożoności algorytmicznej? Matematyka i algorytmika to podstawy informatyki i jeśli ich nie znasz, to niektóre rozwiązania będziesz wynajdywał na nowo, a niektórych problemów nie rozwiążesz wcale. Książki z tych dwóch tematów nie starzeją się, dlatego warto je mieć na półce.

Nowe rzeczy

Warto także zgłębiać nowe dziedziny informatyki, rzeczy które mogą całkowicie zmienić to, jak pracujemy za kilka lat. Przykłady - ML, BigData, IOT (Internet of Things) czy Blockchain. Być może w Twojej obecnej pracy jest możliwość zajmowania się projektem który jest nieco ciekawszy, niż zwykły CRUD. A może taki program ułatwi Ci jakieś powtarzalne zadania w domu i warto stworzyć go samemu?