Jak to jest z tym dokształcaniem się

2

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?

13

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
image

screenshot-20220726202831.png

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ć.

3
  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ę.
4

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 :)

2

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.

5

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.

3

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.

6

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ł?

1

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?)

8

Ja też kiedyś miałem problem z zapamiętaniem co i jak.
Szczególne jak np. trzeba zrobić rebase.
Ale kiedyś znalazłem to: image
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

1 użytkowników online, w tym zalogowanych: 0, gości: 1