Przebranżowienie na programistę: plan na realny tydzień

Weź kalendarz i sprawdź dwa ostatnie tygodnie. To nie plan na przyszły miesiąc, tylko zapis tego, co się wydarzyło: o której wracałeś do domu, które wieczory zjadły sprawy, których nie dało się przenieść, ile razy usiadłeś do czegokolwiek trudnego po dwudziestej drugiej.

Ta kolumna rozstrzyga przebranżowienie na programistę.

Nie wybór między C# a Pythonem. Nie to, czy masz głowę do matematyki. Materiał leży wszędzie, w dużej części darmowy, a godzin nie da się dokupić ani nadrobić w jeden weekend, w którym akurat masz zapał.

Plan poniżej ma jeden rachunek i cztery etapy. Rachunek to liczba godzin, które masz w tygodniu, policzona uczciwie. Potem podstawy języka, aż przestaniesz zgadywać składnię. Dalej narzędzia, o których kursy języka milczą. Na końcu jeden projekt doprowadzony do końca, i dopiero po nim CV.

Rachunek godzin robisz raz i uczciwie

Weź ostatni normalny tydzień, bez urlopu i bez grypy, i wypisz wolne bloki dłuższe niż godzina. Odejmij potem te, w których jesteś zbyt zmęczony, żeby czytać cokolwiek nowego.

To, co zostanie, jest Twoim budżetem.

Odejmowanie boli bardziej, niż się wydaje. Wieczór z dojazdem, zakupami i kolacją zostawia najwyżej półtorej godziny, a nie trzy, na które wyglądał w planie. Poniedziałek po naradzie w pracy jest do wyrzucenia, choć w kalendarzu wygląda identycznie jak czwartek. Godzina przed snem policzona jako nauka zwykle jest godziną czytania o nauce, co jest inną czynnością i przynosi inne efekty.

Przy pracy na pełny etat i dziecku w domu wychodzi zwykle od pięciu do dziesięciu godzin. Bez dzieci, z pracą kończącą się o siedemnastej, bywa dwadzieścia. Na wypowiedzeniu albo między etatami bywa jeszcze więcej, ale to okno zamyka się szybko i nie warto opierać na nim planu dłuższego niż kwartał.

Zapisz tę liczbę i traktuj ją jako daną wejściową. Reszta planu jest od niej pochodna, nie odwrotnie.

Najczęstszy błąd wygląda tak: ktoś wpisuje piętnaście godzin, bo tyle wypadałoby wyrobić, robi dwie i po miesiącu odkłada naukę z poczuciem, że nie ma do niej talentu. Pięć wpisanych i pięć zrobionych to dokładnie to samo tempo, tylko wyglądałoby jak sukces.

Pięć, dziesięć i dwadzieścia godzin w tygodniu

Zamiast szacować, policz na konkretnym programie. Kurs „Mastering C# and .NET 10” ma 10 części, 60 rozdziałów i 670+ lekcji, a materiał jest wyceniony na około 100 godzin.

Sto godzin to sam materiał.

W tych stu godzinach nie ma wieczoru straconego na literówkę w nazwie pliku ani czasu na projekt, w którym nikt nie podpowiada, co wpisać. Podwój tę liczbę, żeby dostać coś bliższego prawdzie: dwieście godzin, licząc wszystko.

Przy pięciu godzinach tygodniowo to czterdzieści tygodni. Przy dziesięciu, dwadzieścia. Dwadzieścia godzin w tygodniu skraca to do dziesięciu tygodni, tylko że takiego tempa nie utrzymasz, jeśli w tym samym czasie ktoś inny nie robi zakupów i obiadu.

Tak wygląda pięć godzin wpisanych w kalendarz, a nie w postanowienie: wtorek i czwartek od 20:15 do 21:45, niedziela od 9:00 do 11:00.

Dziesięć: wtorek i czwartek od 20:00 do 22:00, sobota od 9:00 do 13:00, niedziela od 9:00 do 11:00.

Dwadzieścia: od poniedziałku do piątku od 9:00 do 12:00, sobota od 10:00 do 15:00.

Bloki trzeba jeszcze obronić, i to jest osobna umiejętność. Powiedz domownikom konkretnie, które wieczory są zajęte: wtorek i czwartek po dwudziestej, a nie „czasem wieczorami”. Wycisz telefon na czas bloku, bo po zerknięciu na powiadomienie wracasz nie do tej samej linii kodu, tylko do początku problemu. Jeden wieczór w tygodniu zostaw celowo wolny, jako zapas na tydzień, w którym coś wypadnie.

Policz sumę na swoim kalendarzu, zanim uznasz któryś wariant za swój. Trzy wieczory w tygodniu wyglądają nieszkodliwie w tabelce i wyglądają inaczej w czwartym tygodniu listopada, kiedy ciemno jest od szesnastej, w pracy trwa zamknięcie kwartału, a Ty siadasz do pętli i kolekcji.

Co da się zrobić w trzy miesiące

Kwartał to trzynaście tygodni, więc każdy budżet daje się przemnożyć i zobaczyć bez nadziei w liczbach.

Pięć godzin tygodniowo to sześćdziesiąt pięć godzin, czyli mniej niż połowa materiału. Po kwartale znasz typy, pętle, kolekcje i klasy, piszesz programy konsolowe na kilkadziesiąt linii i nie masz jeszcze projektu. To nie jest porażka, to jest tempo pięciu godzin i lepiej wiedzieć o tym w styczniu niż w maju.

Dziesięć godzin daje sto trzydzieści godzin, czyli większość materiału i początek własnego projektu. Umiesz czytać komunikat błędu, wiesz, do czego służy debugger, i masz jeden program, którego nie było w żadnym kursie.

Dwadzieścia godzin to dwieście sześćdziesiąt godzin w kwartale, czyli cały materiał i skończony projekt. Tyle samo nauki inna osoba rozłoży na dziewięć miesięcy, i po drodze przerobi ten sam materiał, tylko wolniej i z większą liczbą powtórek, bo tydzień przerwy zawsze coś zabiera.

Kwartał przerwany dwutygodniowym wyjazdem nie kosztuje dwóch tygodni, tylko trzy, bo powrót do materiału zaczyna się od odtwarzania rzeczy, które przed wyjazdem były zrozumiałe. Mniejszy, ale nieprzerwany budżet wygrywa więc z większym i poszarpanym, a pięć godzin w każdym tygodniu daje więcej niż dwadzieścia w co trzecim.

Żadna z tych trzech linijek nie mówi nic o zatrudnieniu. Mówią tylko o materiale, który przerobisz.

Kolejność, w której to ma sens

Najpierw język, dopóki nie przestaniesz zgadywać. Typy, pętle, kolekcje, klasy, wyjątki. Uczy się tego na ćwiczeniach, nie na filmach: w tym programie jest 328 zadań i 200 lekcji z wyjaśnieniami, a proporcja jest celowa, bo pisania kodu nie da się obejrzeć.

Dalej narzędzia, czyli etap, który wypada z większości planów.

Debugger, żeby zobaczyć wartości zmiennych zamiast wypisywać je na konsolę w dziesięciu miejscach. Git w zakresie zatwierdzania zmian, gałęzi i scalania, wraz z jednym konfliktem rozwiązanym ręcznie, bo dopiero konflikt tłumaczy, po co są gałęzie. SQL na poziomie zapytania z JOIN, klucza obcego i jednego indeksu. HTTP razem z kodami odpowiedzi, żeby 404 i 500 przestały być tą samą awarią. Do tego kilka testów jednostkowych, uruchamianych poleceniem, a nie klikaniem po aplikacji.

Na rozmowie na juniora pytania z tej listy pojawiają się częściej niż pytania o składnię, a odpowiedź „nie używałem” trzy razy pod rząd kończy rozmowę.

Potem projekt. Jeden, skończony.

CV na samym końcu, i nie z powodu jakiejś zasady. Wysłane w drugim etapie wraca ciszą, a cisza po dwudziestu aplikacjach zamienia naukę w coś, do czego nie chcesz wracać wieczorem.

W samym CV nie liczy się nazwa kursu, tylko to, co stoi obok niej. Link do repozytorium z historią zmian z kilku miesięcy, jedno zdanie o tym, co program robi, i uczciwa lista rzeczy, których jeszcze nie umiesz. Osoba czytająca zgłoszenie otworzy repozytorium przed listem motywacyjnym i zobaczy w nim kolejność commitów, a nie sam końcowy stan plików.

Ta sama kolejność stoi za programem kursu: od pierwszego programu, przez obiekty i LINQ, do testów, API w ASP.NET Core i projektu z bazą danych. Skoro nadal wybierasz język, porównanie C# i Javy zamyka ten temat w jeden wieczór.

Projekt, który ma pliki, a nie ambicje

Projekt na tym etapie nie jest portfolio. Jest dowodem, że umiesz doprowadzić coś do końca, i pierwszym miejscem, w którym nikt nie mówi Ci, co wpisać w pustym pliku.

Weź coś, czego sam używasz. Budżet domowy wystarczy.

Po dwóch tygodniach w katalogu stoi to:

budzet/
├── Budzet.csproj
├── Program.cs
├── Wydatek.cs
├── Kategoria.cs
├── MagazynWydatkow.cs
└── wydatki.csv

Pięć plików z kodem i jeden z danymi. Program.cs czyta polecenia z konsoli, Wydatek.cs opisuje jeden wydatek, Kategoria.cs jest typem wyliczeniowym, a MagazynWydatkow.cs zapisuje i odczytuje plik CSV.

Zwróć uwagę, czego na tej liście nie ma. Brakuje logowania, panelu w przeglądarce i wykresów, bo pierwszy projekt ma zostać skończony, a nie zaimponować komuś na rozmowie. Pół roku później dopiszesz do niego rzeczy, których dzisiaj nie umiesz nazwać.

Pierwszy prawdziwy błąd trafi Cię przy kwocie. Polskim separatorem dziesiętnym jest przecinek, więc „12,50” zapisane przez program i odczytane przy innym ustawieniu regionalnym potrafi wrócić jako 1250. Wtedy dowiadujesz się, czym jest CultureInfo i dlaczego dane zapisuje się w formacie niezależnym od ustawień systemu.

Drugi błąd czeka przy pustym pliku CSV, którego program jeszcze nie widział, i jest ciekawszy od pierwszego, bo uczy pisać kod dla danych, których nie wymyśliłeś. Pusty plik nie jest tym samym co brak pliku, a program musi rozróżniać oba przypadki.

Kiedy to działa, wymień plik CSV na bazę danych, dopisz testy i wystaw te same dane jako API. Kurs kończy się projektem o nazwie TaskTracker, złożonym z wielu plików.

Czego ten plan nie obiecuje

Nie obiecuje zatrudnienia. Nikt nie może go obiecać, a kto obiecuje, sprzedaje coś innego niż naukę: rekrutacja zależy od rynku w Twoim mieście, od tego, ile osób akurat szuka pierwszej pracy, i od tego, czy ktoś w firmie ma czas na wdrożenie juniora.

Skończony kurs też nie równa się gotowości do pracy. Kurs daje materiał i kolejność, a resztę robisz na własnych błędach i tej części nie da się skrócić.

Żaden harmonogram nie przetrwa chorego dziecka i zamknięcia kwartału naraz. Przetrwa go budżet z zapasem, dlatego pięć godzin realnych jest lepsze niż dziesięć wpisanych z nadzieją.

Plan nie zdejmuje też z Ciebie decyzji, na którą nikt nie odpowie za Ciebie: przebranżowienie na programistę oznacza kilkanaście miesięcy wieczorów oddanych czemuś, co przez pierwsze tygodnie zwyczajnie nie działa. Warto wiedzieć o tym przed pierwszą lekcją, nie w trzecim miesiącu.

Pytanie, czy nauka programowania ma sens, gdy modele piszą kod, zostaje tu bez odpowiedzi. Wymaga osobnego tekstu, a w rachunku godzin zmienia jedno: część czasu przeznaczonego na przepisywanie składni lepiej przenieść na czytanie cudzego kodu i sprawdzanie, czy robi to, co obiecuje.

Warto wiedzieć, czego nie obiecuje samo narzędzie: DevJourney działa na Windows 10 i 11, wymaga zainstalowanego .NET SDK 10 i nie ma wersji na macOS ani Linuksa. Na Macu plan zostaje ten sam, tylko środowisko składasz sobie samodzielnie.

Kiedy przerwać albo zmienić podejście

Trzy tygodnie bez otwarcia edytora to nie lenistwo. To informacja, że plan nie mieści się w tygodniu, a najlepszą reakcją jest zmniejszenie budżetu o połowę zamiast kolejnego restartu od pierwszego rozdziału.

Jeśli przechodzisz kurs bez problemu, ale pusty plik Cię blokuje, przerwij kurs w połowie i napisz coś małego. Ta blokada nie znika od kolejnych lekcji.

Jeśli zaczynasz czwarty kurs, nie skończywszy pierwszego, problem nie leży w wyborze kursu.

Bywa też, że wystarczy zmienić podejście, i to jest tańsze od przerwy. Dwa miesiące filmów bez ani jednego programu napisanego od zera oznaczają, że kolejny kurs niczego nie poprawi: odłóż go i przepisz z pamięci najprostszy program, jaki w tym czasie widziałeś. Wyjdzie źle i będzie to pierwszy wieczór, w którym uczysz się pisać, a nie patrzeć.

Jest jeszcze przypadek, o którym mało kto pisze: czasem właściwą decyzją jest odpuścić. Kiedy po czterech miesiącach siadasz do nauki z obowiązku, nic Cię w niej nie ciekawi i trzyma Cię wyłącznie wyobrażenie o wyższej pensji, to również jest wynik rachunku, tylko innego. Poza pisaniem kodu jest w IT wiele ról i warto sprawdzić, czego wymagają dzisiejsze ogłoszenia, zanim uznasz, że odpadasz z całej branży.

Zacznij w środę wieczorem

Wpisz bloki nauki do kalendarza, z godzinami, na dwa tygodnie do przodu. Potem, tego samego wieczoru, zainstaluj .NET SDK 10 i napisz program, który zapyta o imię i odpowie po imieniu.

Gdy w piątek te bloki nadal tam stoją i nic ich nie zjadło, znasz swój budżet i możesz układać naukę na miesiące, a nie na jeden zapał.