nauka kodowania przez "ciężką pracę"

cześć wszystkim
Ostatnio po głowie chodzi mi pewna myśl. Może zacznę od tego, że jak przypuśćmy chcemy się nauczyć matematyki to zwykle uczymy się z książki, a potem robimy zadania. Zwykle im wiecej zadań robimy, tym jesteśmy lepsi: uczymy się nawyków, zapamiętujemy sztuczki i wzory. Stąd często się mówi np. że można być bardzo dobrym z matematyki jak się "ciężko pracuje".

Takie same zwroty często widuje w wypowiedziach ludzi między innymi na tym forum lub jakimś innym, w stylu: ciężko pracowałem przez pół roku(np uczylem sie javy, php, c++ whatever) i dostałem się na staż/juniora

Przypuśćmy, że jest pan Gienek. Pan Gienek ma czas, ma dużo chęci i zapał do nauki, ale nie bardzo wie, co to znaczy "ciężka praca", a chce być dobry.
Jak wszyscy wiemy, np. czytajac same tutoriale dobzi nie będziemy. "praktyka czyni mistrza", ale nie łatwo jest odwzorować praktykę, która istnieje w pracy, praktykując samodzielnie w domu i w dodatku, nigdy nie mając styczności z taką "prawdziwą" praktyką.

Przypuśćmy, że Gienek chce być dobrym developerem Javy w przyszłości. Prostackie będzie pytanie "co zrobić żeby być dobrym?" bo pewnie za to zostałbym utopiony falą WTFów w odpowiedziach, ale jak postępować, żeby nie marnować czasu na bzdety, a faktycznie uczyć się wartościowych rzeczy. Co to znaczy "cięzka praca": robienie w kółko nowych programów, o różnej funkcjonalności bez czytania za dużo, czy może praktykowanie i czytanie na równi, czy może jedynym sposobem jest staż/praktyki? Co tak na prawdę w okresie nauki odróżnia tych, którzy kiedyś będą dobzi, a tych którzy bedą przeciętni?

Selige widziałem. Ale nie wiem czy wkucie informacji dot. concurrency, protokołu TCP czy inne bez praktyki coś da. Wiadomo, że to ważne informacje, ale zdobyte w drodze nauki, a nie wstukane w łeb młotkiem bo "must know to be awesome".

Stawiam, że open-source jest dobrym sposobem na zdobycie doswiadczenia. Tylko zeby gdzieś się wkręcić to trzeba mieć jakąś porządna wiedze, zeby nasze commity były w ogole uwzglednione, jako przynajmniej akceptowalne.

Mam szczerą nadzieję, że mój przekaz zrozumieliście :)
Pozdrawiam

nauczyć się tyle, żeby umieć coś napisać -> napisać tyle, żeby mieć co pokazać na rozmowie -> zacząć pracować w danej technologii

Wiem po sobie, że rozkminianie "jak się uczyć" kiedy nie ogarnia się danej technologii na tyle, żeby w niej pracować na najniższym stażowym/juniorskim stanowisku to strata czasu.

Jasne, że trzeba mieć jakieś podstawy teoretyczne. Przecież nie można pisać "z głowy" w frameworku, którego się na oczy nie widziało :D Przeglądanie/pisanie z API/tutorialami to nic innego jak nauka tej "teorii".

Książki (dobre!) dają fajny fundament, ale na początku polecam je czytać raczej do poduszki, a skupić się na robieniu konkretnych rzeczy.

Powiem ci co to ta "ciężka praca" w moim wypadku była.

Jakieś 4 miesiące nauki Ruby i RoR + JavaScript, HTML, CSS na znośnym poziomie. Głównie dobre tutoriale + dokumentacja + klepanie małych rzeczy na początku praktycznie przeklepywanie z tutoriali, potem pisanie bardziej samodzielnie i zadawanie pytań na Stackoverflow jak coś się wysypało, a ja nie umiałem sobie poradzić. Do poduszki jakaś dobra książka dot. samego języka + coś tam Meyer'a dot. CSS i HTML.

Skąd taka rezerwa u wielu do książek (pytanie bez tezy)? Rozumiem, że można z dystansem patrzeć na pozycje, których tytuły zawierają słowa/frazy jak "wstęp", "podstawy", "w 10 dni", ale przecież na rynku jest trochę "krów", "cegieł" po prawie 1000 stron na temat jednej technologii. Nie jest to wystarczająca ilość teorii dla juniora, a nawet regulara?

Książka pomaga zacząć ale później ją odkładasz i już więcej na nią patrzysz.

Różnie często książki są bezsensu napisane, bo wałkują proste tematy, a trudne są opisane, jakby autor sam tego nie rozumiał, albo co gorsza leją wodę, czytam czytam a dalej wiem to samo. Poza tym takie przerabianie książek, że lecimy po kolei i rozkminiamy przez początkującego jest bezsensu, wiem bo sam tak robiłem, chociaż warto ogólnie ogarniać, ale nie za taką cenę czasu.

nauka to jedno, drugie to że trzeba być zorientowanym w rynku, czyli przegladac chociazby ogloszenia o prace albo fora branzowe i wiedzieć, jakich frameworków się używa, jakie są wymagania na stanowisko, na ktore byś chciał aplikować - wtedy nie będziesz się uczyl w ciemno.

No i ważne są rzeczy typu system kontroli wersji (np. GIT), testy jednostkowe, umiejetnosc pisania eleganckiego kodu (a nie spaghetti), umiejetność pracy z cudzym kodem, i ogólnie z dużą iloscia kodu źródłowego napisanego przez kogoś innego (na szczescie jest duzo projektow open source, ktore mozna sobie podejrzeć/użyć/zmodyfikować, a wiec rownież cwiczyć te umiejętnośc "pracy z cudzym kodem").

No, a to niekoniecznie są rzeczy majace związek z jakąs konkretną technologią.

ciezkom pracom ludzie sie bogacom

Pierwszą książkę o programowania warto przeczytać cała, po polsku. Dlaczego? Bo łatwiej zrozumieć pojęcia klas,klas abstrakcyjnych,obiektów, dziedziczenia ,pól,metod i wielu innych. Jak się będziesz uczył kolejnego języka to wtedy warto korzystać z dokumentacji bo jak to wyżej napisali wszystko się ciągle zmienia.

Z tym, że przykładowo: uczyliśmy się danych techonologii (zostanmy przy javie, bo troche ją znam) gdzie są frameworki tj spring czy jee, gwt, wicket, jsf i wiele innych i nagle staneliśmy w miejscu i nie wiemy co dalej. Tutoriale przeklepane, pare swoich niedokonczonych aplikacji popisane i świadomość, że można wiedzieć znacznie więcej, ale kompletnie nie wiadomo skąd to brać.
A jeśli ktoś zna np springa i jakiegos vaadina, to czy warto uczyć się znowu kolejnych technologii frontendowych(nauka gwt, jsfa i innych) czy backendowych(jakies implementacje jee tj. jersey), bo myślę, że lepiej jest coś, jak to się mówi "zmasterować", niż wiedzieć o wszystkim po troche.
A może dodatkowy język jest wart nauki, scala, python, ruby? (ale to chyba podobna sytuacja co uczenie się nowych frameworków: nie masterujemy, a poznajemy wciąż nowe)

Zależy od tego, czy stawiasz tylko na kasę, czy również na erudycję.