Jak to jest z tym dokształcaniem się

Z zażenowaniem stwierdzam, że mimo ponad 10 lat w zawodzie, łapię się na tym, że nie kumam rzeczy uchodzących za podstawy.
Na przykład: niedawno merdżowałem branch B do brancza A i chciałem żeby był tylko jeden zbiorczy commit.
No to daję "git merge --squash". Poszło, ale widzę, że teraz w gitk A i B się nie łączą.
Dopiero kolejny "git merge" sprawił, że A i B się ładnie zbiegają w wizualizacji historii, tak jak mi się wydaje że powinny.
Czemu tak? Otóż kurde nie wiem. Z czego płynie prosty wniosek, że tak naprawdę moje rozumienie GITa jest co najwyżej powierzchowne.
Mam ogarnięte kilka scenariuszy: skakanie po branczach, commitowanie i cofanie zmian, elementarna praca ze zdalnym repo.
Rozumiem podstawowe koncepty. Ale jak trzeba zrobić coś co wykracza poza wąskie standardowe działania, to się wywalam.
Ten GIT to tylko przykład. Jedno z wielu podstawowych narzędzi, którego nauczyłem się po łebkach.
Cośtam czytałem, cośtam zapamiętałem, wiele zapomniałem, jakoś używam.

Gdy się zastanawiam, jak do tego doszło, że mam takie dziury w wiedzy, to nasuwają mi się następujące wyjaśnienia:

• jestem głupi i nie przyswajam tyle co inni
• to powszechne zjawisko, tylko mało kto się przyznaje
• za mało czasu poświęcałem na naukę, a za dużo na krzątaninę wokół aktualnych tasków.

Żeby zweryfikować tę ostatnią hipotezę, chciałbym zapytać, ile poświęcacie czasu w tygodniu na naukę technik, narzędzi, konceptów?
Mam na myśli dążenie do głębszego zrozumienia, a nie tylko tyle żeby opędzić bieżący task.
Ile książek programistycznych czytacie w roku?

Książki to czytałem jak zaczynałem. Żeby napisać książkę trzeba temat, przyswoić, zrozumieć, napisać książkę i ją wydać więc w momencie jej kupna jest już dawno przestarzała. Co do tematów które się nie starzeją to po przeczytaniu paru książek ciężko trafić na kolejną która nie będzie wałkować znowu tego samego. Raczej blogi, dokumentacja, artykuły w Internecie, szkolenia w pracy.

Odpowiedź: b) to powszechne zjawisko, tylko mało kto się przyznaje

BTW z gita byłem nawet na paru szkoleniach w kolejnych pracach (zawsze trafiałem akurat na moment przechodzenia z innego systemu kontroli wersji w projekcie) - zawsze prowadzący przedstawiał tylko podstawy, a zapytany o coś bardziej złożonego nie potrafił odpowiedzieć.

1. Tak działa squash merge. Nie przejmuj się, skoro wiesz, że nie wiesz jak działa, to świetna okazja by się douczyć.
2. Więcej niż 3h.
3. Co do książek, nie wiem, nie liczę. Częściej niż książki czytam publikacje, blogi, fora, słucham podcastów, robię kursy na courserze i udemy, przeglądam githuba. Zależy na co akurat mam ochotę.

Do uczenia się na zapas podchodzę sceptycznie. Normalna sprawa, że się zapomina rzeczy, których na co dzień się nie używa. Kiedyś do CV właśnie sobie gita mocno ogarnąłem i po roku nie pamiętałem zdecydowanej większości komend. Także wszystko w porządku.
Polecam robienie notatek ale porządnych by faktycznie wracając do nich po roku można było szybciej ogarnąć temat niż poprzez googlowanie.
Co do dokształcania się, w tygodniu staram się poświęcić ok. 12h na tematy z poza pracy, głównie swoje projekty na githuba ale książki też. Tematy do pracy ogarniam tylko w czasie pracy :)

Nie jest w tym nic dziwnego, ponieważ tylko komórki that fire together wire together.

Być może technika zapamiętywania spaced repetition w dużym jakimś stopniu ułatwi ci zapamiętywanie kluczowych komend, itd.

Trochę mylisz tutaj dwie podstawowe czynności:

1. Głębsze zrozumienie.
2. Zapamiętywanie konkretnego rozwiązania.

W kontekście Gita możesz rozumieć, że istnieje coś takiego jak reflog, commit hash, w jaki sposób konkretne commity współgrają ze sobą i w jaki sposób Git określa pozycje commitów w drzewach i czy np. coś trzeba merge'ować/rebase'ować czy nie. Jednocześnie możesz też kompletnie nie pamiętać, jaka komenda pozwoli ci wylistować reflog.
I tak jest ze wszystkim. Przy streamingu danych możesz rozróżniać architekturę stateful/stateless, czym się różni join od merge'a, jakie są rodzaje okienek - ale za cholerę nie zapamiętasz, jak pogrupować elementy w kolekcje po tysiąc elementów, bo to jest bardzo mocno zależne od API.

Osobiście uważam, że takie poznanie wszystkiego na pamięć jest praktycznie niemożliwe w dłuższym okresie, natomiast od pewnego momentu należy znać te teoretyczne podstawy tego, na czym się pracuje.

Ciekawa jest ta gierka do gita przeszedłem ją sobie kilka razy https://learngitbranching.js.org/

A tak, to robiłem sobie katalog testowy git init, tak jakieś przypadkowe dane w plikach, echo "sad"> bug.txt, dodawałem commitowałem, sprawdzałem potem jak wygląda gałąź historii commitów, git log --graph --all, checkoutowałem, testowałem ls jak struktry katalogów się zmieniały, łatwo potem szło wywnioskować, nawet bez czytania dokumentacji, że git reset --soft wykonywał squasha, a git reset --hard usuwał całą gałąź commitów i ustawiał brancha na danej gałęzi którą się podało.

Potem się trzeba zastanowić czy jak usunę gałęzie to czy one znikną?
Oczywiście, że nie cały czas leżą w .git/object/{hash[:2]}/{hash[2:]}, dopiero jak pushujemy na origin to te commity poza gałęziami pushowanymi nie są wysyłane, ale lokalnie nadal leżą w katalogu.

Nie wiem może jestem dziwny ale od 5 lat jak pracuje nie obejrzałem więcej jak 10% jakiegoś kupionego kursu czy szkolenia. I nie przeszkodziło mi to w przejściu na stanowisko seniorskie.

Wydaje mi sie ze najwięcej mi daje poszukiwanie lepszych rozwiązań w codziennej pracy. Widzę jakis kod, chwile pozastanawiam się co by można w nim poprawić, pomyśle jak coś napisać zeby za pół roku po zmianie wymagań można to łatwo dostosować, przy okazji coś na ten temat przeczytam i tak leci dzień za dniem.

Mam wrażenie że na wiele tematów zwyczajny student mógłby mnie zagiąć ale z drugiej strony po co wiedzieć wszystko skoro na codzien i tak tego nie będę używał?

Git po prostu ma mierny interfejs liniowo-komendowy, tyle.

Gdyby Gita stworzył jakiś Apple, albo ktokolwiek mający UXów, to byłby pewnie o wiele bardziej oczywisty (chociaż pewnie momentami mniej powerful, ale who cares?)

Ja też kiedyś miałem problem z zapamiętaniem co i jak.
Szczególne jak np. trzeba zrobić rebase.
Ale kiedyś znalazłem to:
I mne tak rozbawiły te komentarze w klockach "Czy ktoś to widział i czy zależy na tym bajzlu?", od tego czasu wiem, co mam robić :D

ja tam siedzę ponad 3 lata w programowaniu i konsoli gita nie ruszałem (poza jakimś kursem kiedyś bo chciałem poznać gita bo niby siara nie znać, ale i tak wszystko zapomniałem), wszystko wyklikuję sobie w InteliJ i wszystko działa, jeszcze mi przy okazji InteliJ i Sonar robią analizę kodu i np. krzyczą że grozi NullPointer

Witaj w realnym świecie. Większość ludzi, jak nie prawie wszyscy z którymi pracuje/pracowałem rozumuje wszystko po łebkach. Jakoś działa i działa a jak trzeba coś zdebugować to wtedy już jest "please help, i am having issues"...
Zazwyczaj opcja "squash and merge" jest dostępna z defaultu w githubie przy mergowaniu PRa i ludzie jej uzywaja nie wiedząc po co...
A historia repo ładna i pookładana? Hahaha dobre żarty. Do tej pory tylko w 1 projekcie spotkałem się ze była dobra gdy kolega devops o nią dbał i to on był jakby release managerem i deployowal zmiany i mergowal itd...
Przez co historia była liniowa i każdy PR to byl 1 commit z ID jiry i opisem w 1 zdaniu co zostało zmienione.
Wszędzie indziej gnój niestety gdzie pracuje/pracowałem.
95% ludzi wg mnie nie rozumie różnicy miedzy merge a rebase na przykład...
Co do uczenia na zapas zgadzam się - jest to ciężkie, dlatego ja się uczę jak coś potrzebuje, a na zapas tylko tyle co jest w jakichś kursach mi potrzebnych, z których powiedzmy 50% wiedzy używam w projekcie a ta reszta 50% jest jakby "na zapas". Niestety często się to "na zapas" zapomina po kilku tygodniach od nieużywania ale warto pamiętać chociaż ze coś takiego kiedyś się na przykładach hello world uczyło i jest gdzieś zapisane i wiemy gdzie tego szukać. Zawsze lepsze to niż kompletny brak rozumowania co to jest.

umieć coś a rozumieć a jeszcze głęboko rozumieć to są trzy różne rzeczy

Też mam takie myślenie jak Ty i mnie to poraża, że dla mnie największym hamulcem przed ewentualną zmianą pracy by było myślenie "a co jeśli sobie nie dam rady, przecież jestem tak nieogarnięty w porównaniu do innych i nic nie umiem", mimo że przecież jest pełno głąbów ogarniających jeszcze mniej i zarabiających dwa razy więcej.

I nikt nie odpowie na to pytanie, bo nie może :). My nie znamy prywatnego życia innych osób i nie wiemy ile pracy te osoby włożyły, by być tam, gdzie są, by uczyć się szybko, by mieć wysokie skille. Niestety, też bym chciał wiedzieć jak to jest :<

Marcin Marcin napisał(a):

umieć coś a rozumieć a jeszcze głęboko rozumieć to są trzy różne rzeczy

Pytanie, jak głęboko chcemy iść. I czy lepiej poświęcić czas na głębszą naukę Gita, czy może pogodzić się z powierzchowną znajomością Gita, za to poświęcić czas na zrozumienie czego innego głębiej, ew. na powierzchowne poznanie z kilku innych rzeczy.

Myślę, że to zależy od tego, co już umiemy i gdzie mamy braki. Jeśli komuś przeszkadza, że nie zna dobrze Gita i traci czas na commity, to może być dobrym pomysłem głębsza nauka Gita. Ale ktoś inny może uznać, że przez ten czas pouczy się czegoś innego, a do Gita będzie używać StackOverflow.

Tyle jest technologii, że trzeba wybierać, które technologie chcemy głęboko poznać, a które tylko trochę. A nauka których technologii musi poczekać, bo teraz trzeba się nauczyć innych.

@LukeJL: moim zdaniem (nawet napisałem o tym artykul) wiedzą ma datę ważności i nie warto uczyć się na zapas rzeczy z ktorkimterninem ważności a takie które mają krótki termin ważności uczyć się na bieżąco. Na zapas tylko tych niezmiennych jak matematyka, algorytmy itd.

Ale czasem to nie jest nauka na zapas, tylko po prostu czegoś potrzebujesz i się uczysz, jednak później nie sięgasz do tego i po przerwie znowu siadasz i musisz sobie przypominać.

W mojej opinii swój czas na doszkalanie się w większym wymiarze warto poświęcić w trzech przypadkach:

1. Technologia, której pogłębianie sprawia przyjemność, a przy okazji rozwija horyzonty i daje jakieś nowe perspektywy na przyszłość.

2. Technologia, którą można rozwijać podczas codziennej pracy, np. przy okazji realizacji nowego projektu, w mniej znanej mj technologii.

3. Chęć migracji do innej technologii.

Według mnie nie ma sensu uczyć się czegoś zupełnie na zapas w większym wymiarze jak nie ma w miarę bliskich perspektyw wykorzystania tego w pracy na codzien, chyba że po prostu temat nas ciekawi i jest to forma hobby. Uczyć się, mam na myśli, faktycznie dogłębnie poznawać dany temat, pisać apki itd.

To, co natomiast polecam to czytać artykuły na różne tematy, słuchać podcastów czy ciekawych szkoleń na YouTube, we wszelkich tematach, najlepiej w języku obcym. Nie dość że osłuchujemy się z językiem obcym technicznym, to jeszcze mamy szeroki ogląd na różne tematy i jakieś podstawy, pojęcie, jak zaistnieje potrzeba numer 1, 2 lub 3 powyżej :)

Zastanawia mnie jak ja mam się nauczyć Kubernetesa z podcastów. W zasadzie jakiejkolwiek technologii

Ty nie masz umieć wszystkiego. To nie jest umiejętność za którą się teraz płaci.

Ty masz w dowolnym momencie szybko umieć znaleźć działające rozwiązanie na dowolnie postawiony problem.

Więc musisz szybko umieć coś powierzchownie zrozumieć i wdrożyć. A potem zapomnieć. I tak w kółko.

A co do tego że jesteś głupi to: być może. Większość programistów jest głupia tak samo jak większość ludzi jest głupia. Jak w każdej grupie społecznej.