Masz już kilka dobrych odpowiedzi, ale pozwól mi dodać trochę przekrętu…
Lubię ludzi używających dokumentacji i jest to świetny znak dla twojego profesjonalizmu.
Not using documentation
Znam wystarczająco dużo programistów, którzy potykają się bez prawdziwego planu na długie okresy czasu, próbując tego i owego przez przypadek, wybierając przez stary kod źródłowy, gdzie cokolwiek chcą osiągnąć wydaje się, że zostało już zrobione (ale nie całkiem) i tak dalej. Szczerze mówiąc, nienawidzę tego rodzaju podejścia. Nigdy nie zbliżają się bardzo daleko, często muszą pytać ludzi, rzadko korzystają z rad i wolą kontynuować to w ten sposób na zawsze, pozornie.
Tylko tutoriale?
Ludzie często googlują po tutoriale lub fragmenty kodu, w tym SO, bez odwoływania się kiedykolwiek do dokumentacji, irk mnie do końca. To zachowanie jest, moim zdaniem, ogromną pułapką. Prowadzi ono do pewnego rodzaju programowania napędzanego na wpół upieczoną, arbitralną, niesystematyczną “wiedzą”. Ci programiści mają tendencję do kończenia z wieloma uprzedzeniami. To właśnie stąd pochodzą takie nuggetsy jak “never use git rebase”, “never use not in in SQL”, “always do XXX”, “never do YYYY”. Będzie im bardzo trudno myśleć nieszablonowo, wymyślać nowe pomysły, formować intuicję o tym, jak zbudować swoje aplikacje i wszystko to, co składa się na świetnych programistów.
Nalegam, abyś rozwiązał każdy problem najpierw patrząc na dokumentację/podręcznik, i then szukaj SO lub innych snippetów.
Oczywiście są wyjątki. Jeśli twój problem jest oczywiście czymś w rodzaju błędu, lub czymś bardzo, bardzo, bardzo szczególnym, co raczej nie będzie rozpatrywane w jakiejkolwiek dokumentacji (np, specjalna kombinacja bibliotek/modułów itp.), wtedy na wszelki wypadek przejdź od razu do SO.
Jeśli jest to coś co może być łatwo rozwiązane przez dokumentację/API, wtedy sugerowałbym usiąść i popracować nad tą konkretną częścią twojego języka programowania / bibliotekami itp. tak aby twoja wiedza się zacieśniła.
Dokumentacja
Najlepszy rodzaj, dla mnie, to programista, który spotykając się z nowym tematem, poświęca czas aby naprawdę usiąść, zagłębić się w niego, uzyskać dobry przegląd i dobre zrozumienie techniczne. Najczęściej osiąga się to (znów, z moim doświadczeniem, z wieloma językami programowania, z którymi miałem kontakt) czytając starą, dobrą dokumentację zawierającą odniesienia do API i tak dalej. Moim zdaniem, nigdy nie można tego zastąpić niczym innym.
Nie uważam, aby czytanie, na przykład, starej klasyki C++ (starego dobrego papieru), Gang of Four Design Patterns, (internetowej wersji) podręcznika “Programming Ruby”, niezwykle dobrze przygotowanych manuskryptów Perla, książki Gita, niektórych RFC, specyfikacji HTML/XML/etc. i tak dalej od przodu do tyłu. Zrobiłbym i zrobiłbym to nawet w wolnym czasie i, szczerze mówiąc, oczekiwałbym tego od każdego programisty wartego jego soli (oczywiście w zależności od tego, z czym pracują). Jestem również w pełni świadomy, że jestem (przynajmniej w firmach, w których pracowałem, w ostatnich dekadach) całkiem sam z tą opinią.
(Uwaga: Oczywiście nie musisz zapamiętywać ogromnych list referencji API, ale przynajmniej zerknij na nie, aby zobaczyć co jest dostępne i jaki jest “duch” API. )
Po dokładnym zapoznaniu się z tematem, then to czas na przyjrzenie się kodowi strony trzeciej w poszukiwaniu inspiracji, lub na przyjrzenie się starszym pytaniom SO (lub zadawanie nowych pytań samodzielnie).
Możesz również zauważyć, że gdy wchłonąłeś jedno takie pole, bardzo łatwo jest znaleźć odpowiedzi poprzez zbliżenie do miejsca, z którego otrzymałeś dokumentację (man pages etc.). W tym momencie, autokompletacja Twojego edytora może być już wystarczająca. I równie dobrze możesz szybko dowiedzieć się, kiedy coś jest po prostu niemożliwe z narzędziem, z którym pracujesz, oszczędzając wiele daremnych poszukiwań.