Ostatnio załąłem moja pierwszą pracę jako programista w zespole wytórczym. Niestety nie uczą mnie dobrych praktyk, tylko "rób zadania, komituj i ma działać".
Jak zrekompensować sobie brak takiej normalnej sytuacji gdzie doświadczony dev podpowie jak należy pisać albo zrobi code review?
Chodzi o back-end w appkach webowych.
Przegladanie jakichs open source? ale jak znaleźć te dobre?
Może macie jakieś inne pomysły?
Jest pełno półśrodków - książki, open source, własne projekty, konferencje... ale najlepiej szukać od razu nowej pracy.
Ja może rozwinę wypowiedź wyżej. Nawet najlepsza książka nie pomoże bez praktyki, czyli pisania. Pewne rzeczy muszą wejść w nawyk. Poza tym w podczas pisania mogą wyjść różne problemy, o których nie napisano w książce a w internecie informacje są szczątkowe. Sam nie raz tak miałem, że Spring zrobił magię (Spring robi dużo magii, bardzo dużo...) i coś się wysypało. Przekopywania się przez logi i stos wywołań było dużo. Z książek a bynajmniej z kursów nie dowiedziałbym się czegoś takiego. No bo w kursach musi wszystko działać i reklamować Spring jako ósmy cud świata (albo jako ósmy CRUD świata ;) ).
No i z tą pracą faktycznie może coś być, ale nie radzę szukać na wczoraj, żeby nie spaść z deszczu pod rynnę. Mając już pracę można się uczyć i szukać nowej pracy. Wyższe wymagania, wyższe pieniądze, ale też w firmie może być tworzony lepszy kod. Tam, gdzie nie mają wymagań co do kandydatów, mogą nie wymagać nic od kodu przez nich produkowanego. Słaby kod to też nauczka jak nie pisać.
Ostatnio załąłem moja pierwszą pracę jako programista w zespole wytórczym. Niestety nie uczą mnie dobrych praktyk, tylko "rób zadania, komituj i ma działać".
No to możesz zacommitować coś, co nie będzie działać za pierwszym razem. Coś, co się wywali i dzięki temu będziesz mógł się nauczyć na błędach (i nauczysz się np. testowania albo tego, w jaki sposób można uniknąć błędów, które popełniałeś wcześniej, czyli tzw. dobrych praktyk, które sam sobie wtedy rozkminisz w praktyce).
Możesz też patrzeć, co ludzie przed tobą spieprzyli - jeśli to zespół na zasadzie "rób zadania, komituj i ma działać", to jest duża szansa, że pisany przez twoich poprzedników kod jest pisany "na pałę". Wtedy grzebiąc w nieutrzymywalnym spaghetti uczysz się tego, "jak nie należy pisać".
Ogólnie uczyć się można na dobrych praktykach, ale można też na złych. Jak @PerlMonk pisze Słaby kod to też nauczka jak nie pisać.
No chyba, że programiści, którzy z tobą pracują, piszą dobry kod, a po prostu nie tłumaczą. Wtedy możesz się uczyć też pozytywnie, czytając ich kod. (chociaż zwykle to jest pomieszane i kod jest częściowo dobry, częściowo spaghetti).
Można podzielić to na dwa podproblemy jakość i wygląd kodu i umiejętności techniczne(np cloud, internalsy javy i springa, różnego rodzaju biblioteki, drugi język na JVM). O ile do pierwszego problemu potrzebne są ci realne casy i druga para oczu tak drugą część tj umiejętności techniczne możesz nauczyć się z czytając odpowiednie książki robiąc certyfikacje czy czytając whitepapersy i dokumentacje jakiejs technologii.
I warto pamiętać, że ładny kod mało kiedy przekłada się na twoją realną wartość biznesową.
Odnośnie nauki poprzez pisanie byłbym daleki od stwierdzenia, że samo pisanie kodu to najlepsza metoda na naukę. Tak to łatwo można zweryfikować czy wiedza jaka masz i umiejętności dobrze rzutują na projekt, i albo coś nam wychodzi albo projekt stawia opór. Oczywiście można się zatrzymać, pomyśleć, zbadać alternatywy, poznać więcej informacji, przećwiczyć inne ścieżki itp, ale podczas pisania projektu, zwłaszcza komercyjnego to takiego komfortu zbytnio nie ma, w trakcie pisania kodu skłaniamy się ku nieciekawym kompromisom, to nie są rzeczy jakie chce się powtarzać w kolejnych projektach.
Także tak to nawet nie zawsze sie dowiemy czego nie wiemy, w zasadzie bardziej byłbym skłonny do stwierdzenia, że dowiemy się tylko jakie problemy były dla nas kłopotliwe / niewygodne.
Tutaj rokujący programista to taki, który tutaj odrobi pracę domową i ten problem wyłapie i zacznie studiować metody radzenia sobie z takimi rzeczami. W lepszej sytuacji jest ten kto zna więcej paradygmatów, więcej zróżnicowanych technik, bo takie rzeczy pozwalają patrzeć z różnych perspektyw, pozwalają sprawniej dokonać selekcji i zawęzić obszar przeszukiwania.
Ale samo programowanie to nie wszystko, bo ważniejsze są narzędzia. To drugi ważny obszar od którego zależy jak bardzo pewny grunt mam pod sobą. Tutaj warto poznać ograniczenia z jakich składają się narzędzia, wiedzieć dlaczego tak te narzędzia działają, jakie są problemy, jak mozna przy nich postąpić - ta rzecz wymaga przebrnięcia przez książki, dokumentacje, rozmowy z programistami, czytanie kodu, coraz większego zagłębiania się w temat i problemy związane z narzędziem itp. Bez tej świadomości nic nam po samym pisaniu, bo to co przedstawiamy w kodzie wtedy wygląda raczej jak zgadywanie.
No i trzecia rzecz, jak ktoś się nauczył wielu technik oraz rzeczywiście zna narzędzia to kolejna trudna rzecz jaka go czeka to mooooocne wdepnięce hamulcja, ponieważ potrzebny będzie umiar, słuchanie innych, rozkładanie sił na cały projekt, pisanie możliwie prostego kodu i to nie jest taka łatwa zrobić to (to tak jak przejście z haskella / rusta do pracy okopach w javascript es 3). Ciężko jest powiedzieć stop sobie, a co gorsza innym, gdy przecież cały świat przecież gna do przodu jak gazela.
Jeśli mamy taką osobę w zespole to niemal wszyscy programisci przy takim gościu również wyglądają jak gwiazdy. Dużo łatwiej jest wtedy redukować poziom złożoności w projekcie, ryzyka jakie wiąże się z projektem, nie wspominając już o samym utrzymaniu.
Także ja tak bym w skrócie ujął to co ma znaczenie z perspektywy uczenia się programowania.
Jest to praca i zarabia się pieniążki i trzeba to szanować. Ktoś płaci za produkt który wykonujesz i możesz pogłębić ten temat - kto za to płaci i dlaczego ? Wgłębić się w logikę biznesową aplikacji do której prawdopodobnie nikt Cie nie będzie chciał dopuścić ;)
Można znaleźć sobie w ofertach prace do której chciałbyś się dostać i nauczyć się technologi które są w niej wykorzystywane np. Angular 8 , rabbit MQ, mongo.
Jest to rozwój i motywacja do pracy ( często zmiana pracy wiąże się również z podwyżką )
Jak poszedłem do mojej pierwszej pracy jako programista z zerowym doświadczeniem to było podobnie. Parę szkoleń ale jedynie produktowych. Poza tym od razu jakiś bug do naprawy i jazda bez tłumaczen. Na początku nie wiedziałem co się dzieje, bo kod był ogromny i to taki stary c++ gdzie ma się nieraz po 10k linii w jednym pliku, dziedziczenie po kilkunastu klasach, bez testów itd, no ale po czasie udało mi się odnajdywać w czymś takim.
Niestety teoretycznie miał być ktoś moim tz mentorem, ale sam powiedział menadżerowi przy wszystkich, że on nie chce i raczej nie miałem z nim później większego kontaktu xD.
I tak przejechałem 1,5 roku, bo nie wiedziałem jak powinno wszystko wyglądać a praca polegała tylko na debugowaniu i dopisywanie pojedynczych ifow, albo dodawania czegoś nowego ale w C# xD.
Później na wskutek covidu straciłem pracę. Uratowalo mnie trochę to, że zakolegowalem się z jednym gościem który siedział obok mnie i od niego czasem czerpałem wiedzę, ale to pod koniec. Poza tym czuje jakbym przespał te 1,5 roku. Kiedy po roku stwierdziłem, że dość tego syfu to zacząłem chodzić na rozmowy rekrutacyjne i wtedy się okazało że tak naprawdę mam totalnie beznadziejna wiedzę teoretyczną, musiałem wyciągnąć książkę i zacząć się uczyć. Niemniej jednak najchętniej zatrudniłbym się jeszcze raz jako junior gdzieś gdzie mógłbym się uczyć od zera ... Ale nadrobić się już nie da i będę musiał bez pewności siebie, że umiem wystarczająco jakoś funkcjonować w nowej pracy. Także uciekaj stamtąd po 3 miesiącach najdalej jak się da, bo tylko sobie krzywdę zrobisz
