Jak wiadomo, wszelkiego rodzaju podręczniki informatyczne to mnóstwo przydatnej wiedzy. Ale bądźmy szczerzy – kto ma czas i cierpliwość na ich czytanie? Książki wymagają skupienia przez wiele godzin, po których i tak zdobyte przez Ciebie informacje są wciąż bardziej teoretyczne, niż praktyczne. Poza tym wiesz dobrze, że IT to jedna z najbardziej dynamicznych branż na świecie. W związku z tym treść podręczników bardzo szybko się dezaktualizuje. Czy naprawdę nie szkoda Ci czasu spędzonego na żmudnym uczeniu się teorii, która dawno temu straciła swój termin przydatności?

W sieci istnieje mnóstwo tutoriali, poradników i hintów on-line na temat Reacta. I to byłaby świetna wiadomość, gdyby nie fakt, że większość z nich dotyczy bardzo podstawowych zagadnień. Nie mówiąc już o tym, że nie oferują one rozwiązań w pracy na prawdziwych, komercyjnych projektach. Przypomnij też sobie, ile z nich masz wciąż na liście “do obejrzenia”, a przyznasz, że nauki za ich pomocą raczej nie da się określić jako usystematyzowanej i kompletnej.

Na rynku istnieją również kursy, które kosztują zaledwie parędziesiąt złotych. Być może w przeszłości zdarzyło Ci się wykupić właśnie tego typu budżetowe szkolenie – i to nie jedno. Ale czy było to coś, co dało Ci 100% satysfakcji i konkretny zastrzyk wiedzy? Czy raczej rzecz, której nie udało Ci się ukończyć, a teraz leży gdzieś na serwerach, porastając e-pajęczyną? Nawet jeśli tego typu szkolenie, przeprowadzone najczęściej bez realnej obecności mentora, zostało przez Ciebie przerobione w całości, to pamiętasz ile to kosztowało zachodu, zaparcia i samodyscypliny?

Operacja na żywym organizmie, znana szerzej jako „metoda prób i błędów” to zdecydowanie najczęściej wybierana metoda nauki Reacta. I – niestety – również taka, która pociąga za sobą masę bugów. Nie oszukujmy się – na początku jest to raczej metoda „błędów i błędów”, gdzie rozwiązując jeden problem tworzysz przy okazji kilka innych. Wiem z doświadczenia, że traci się wtedy dużo czasu, a szef lub zleceniodawca raczej nie jest zadowolony z końcowych efektów pracy. Wybór i tak należy do Ciebie – wolisz być w projekcie rycerzem na białym koniu, czy najpopularniejszym developerem wymienianym przy okazji git-blame?