Jak zaplanować naukę programowania na 12 miesięcy i nie odpaść w połowie drogi

Punkt wyjścia: po co ci programowanie i w jakim tempie?

Oczekiwania kontra rzeczywistość

Plan nauki programowania na 12 miesięcy ma sens tylko wtedy, gdy stoi za nim jasna intencja. Jedni chcą zmienić branżę, inni po prostu zrozumieć „o co chodzi w tym kodowaniu”, a jeszcze inni dążą do pierwszej pracy jako junior. Od tego, który cel wybierzesz, będzie zależało tempo, obciążenie i to, jak ustawisz priorytety w życiu na najbliższy rok.

Najpierw trzeba odróżnić dwie rzeczy: uczenie się programowania a pełne przebranżowienie do IT. Uczenie się to: rozumiesz podstawowe konstrukcje, umiesz napisać proste skrypty, czytasz cudzy kod i wiesz, co mniej więcej się dzieje. Przebranżowienie oznacza: potrafisz dostarczyć wartość w zespole, rozumiesz proces tworzenia oprogramowania, ogarniasz narzędzia pracy, potrafisz samodzielnie rozwiązać typowe problemy z Twojej działki.

W 12 miesięcy przy rozsądnym, ale regularnym wysiłku da się dojść do poziomu:

• Junior / entry-level – przy 2–3 godzinach dziennie (średnio) i dobrym planie. Nie wszyscy dostaną od razu pracę, ale realnie mogą zacząć się o nią ubiegać.
• Mocny hobbysta – przy 1–1,5 godziny dziennie, za to z żelazną konsekwencją i naciskiem na praktyczne projekty.
• Osoba „rozumiejąca, o co chodzi” – przy mniejszym zaangażowaniu, ale raczej bez gotowości do pierwszej pracy w IT.

Na starcie wiele osób ma iluzje, które szybko palą motywację. Klasyki:

• „Po intensywnym kursie za kilka tysięcy wejdę na poziom mida” – nie wejdziesz. Kurs może przyspieszyć drogę, ale nie przeskoczy procesu uczenia się, budowania intuicji i doświadczenia z prawdziwymi problemami.
• „Będę się uczyć 5 godzin dziennie po pracy” – przez pierwszy tydzień, może dwa. Potem pojawi się zmęczenie, frustracja, życie prywatne. Lepiej założyć mniej, a robić to konsekwentnie, niż fantazjować o maratonach przy klawiaturze.
• „Za rok będę zarabiać pierdyliard jako programista” – pierwsza praca w IT często jest skromna finansowo. Duże pieniądze przychodzą później, gdy dowozisz efekty, a nie po prostu „znasz JavaScript”.

Realistyczne oczekiwania nie są po to, by gasić entuzjazm, tylko żeby go ukierunkować. Lepiej traktować najbliższe 12 miesięcy jak świetnie przemyślaną wyprawę niż jak sprint na oślep.

Twoja sytuacja życiowa a plan

Ten sam plan nauki programowania nie zadziała tak samo u studenta z elastycznym grafikiem i u rodzica dwójki dzieci pracującego na pełen etat. Zamiast kopiować cudze harmonogramy, trzeba uczciwie policzyć, ile realnie masz czasu i energii.

Przykładowe scenariusze:

• Student – zwykle ma więcej elastycznego czasu w tygodniu, ale za to potrafi go spektakularnie przepalić. Tu działa strategia: 2–3 dłuższe bloki nauki w tygodniu + krótkie, codzienne „dotknięcie kodu”.
• Osoba na etacie – mniej energii po pracy, za to więcej dyscypliny. Najczęściej sprawdza się nauka 5–6 dni w tygodniu po 60–90 minut + 1 dłuższa sesja w weekend.
• Rodzic z małymi dziećmi – najmniej przewidywalny scenariusz. Tutaj często lepiej myśleć w kategoriach „dni z nauką vs dni bez nauki” i maksymalnie wykorzystywać poranki albo wieczory, zamiast liczyć na idealne 3-godzinne bloki.

Dobry punkt wyjścia: policz tydzień wstecz. Gdzie zniknęły Twoje godziny? Social media, seriale, bezmyślne scrollowanie, chaotyczne „odpoczywanie”? Jeśli chcesz nauczyć się programowania w rok, coś trzeba tymczasowo obciąć. Nie całe życie, ale fragmenty: mniej Netflixa, mniej gier online, może jeden weekend w miesiącu bardziej „techniczny”.

Pomaga proste pytanie: „Z czego jestem gotów zrezygnować na 12 miesięcy, żeby zyskać nową ścieżkę zawodową?” Bez tego pytania plan nauki programowania zostaje tylko na papierze.

Fundament: wybór ścieżki i języka na start

Co chcesz robić w IT?

Nauka programowania od zera na 12 miesięcy jest łatwiejsza, gdy wiesz, do czego zmierzasz. „Chcę zostać programistą” to za mało. Inne umiejętności są potrzebne do frontendu, inne do backendu, a jeszcze inne do analizy danych czy testów automatycznych.

Krótki przegląd głównych ścieżek:

• Frontend – tworzysz to, co widzi użytkownik w przeglądarce. HTML, CSS, JavaScript/TypeScript, frameworki typu React, Vue, Angular. Dobre dla osób, które lubią szybki efekt wizualny i pracę z UI.
• Backend – logika biznesowa, bazy danych, API. Java, C#, Python, Node.js. Spodoba się, jeśli lubisz łamigłówki, strukturę, logikę danych, mniej Cię kręci „ładność” interfejsu.
• Full-stack – trochę frontend, trochę backend. Na początek lepiej wybrać jedną stronę i dopiero potem się rozszerzać.
• Tester / QA (w tym automatyzacja) – szukanie błędów, dbanie o jakość, pisanie testów automatycznych w jednym z języków (często Java, Python, JavaScript). Dobre dla osób analitycznych, dokładnych.
• Data / ML – praca z danymi, statystyka, uczenie maszynowe. Tu króluje Python, przydaje się matematyka i logika.
• Automatyzacja / devops / skrypty – skrypty do usprawniania procesów, CI/CD, narzędzia. Dużo Pythona, Bash, czasem PowerShell.

Jak dopasować ścieżkę do siebie? Pomyśl, co bardziej Cię kręci:

• Lubisz widzieć efekt „na ekranie” – przyciągnie Cię frontend.
• Lubisz grzebać w danych, tabelkach, logice – backend lub data.
• Masz „zajawkę” na statystykę, modele, algorytmy – data/ML.
• Lubisz testować, sprawdzać, czy coś działa zgodnie z założeniami – QA.

Dobrze jest też porozmawiać z ludźmi z branży. Nie chodzi o wywiady na godzinę, czasem 3–4 konkretne pytania na LinkedIn potrafią rozjaśnić sytuację: „Jak wygląda Twój typowy dzień?”, „Co było najtrudniejsze w nauce?”, „Bez czego dziś nie wyobrażasz sobie pracy?”. Do tego konferencje, meetupy (nawet online), kanały na YouTube – słuchaj, jak mówią o swojej pracy ludzie z różnych ścieżek.

Wybór języka programowania na 12 miesięcy

Plan nauki programowania na rok ma sens tylko wtedy, gdy trzymasz się jednego głównego języka (lub stosu), zamiast skakać co dwa tygodnie: „a może jednak Python, a może jednak JavaScript, a może Rust wygląda fajnie…”. To największy pożeracz postępów u początkujących.

Kilka popularnych wyborów na start:

Na 12 miesięcy wybierz jeden główny język i to pod niego buduj ścieżkę: kursy, książki, projekty, ogłoszenia o pracę, repozytoria na GitHubie. Inne technologie możesz co najwyżej „dotknąć” przy okazji (np. trochę SQL, trochę HTML/CSS przy backendzie), ale trzon ma być jeden.

Żeby sprawdzić, czy wybór ma sens na lokalnym rynku pracy, wystarczą trzy proste kroki:

• Otwórz portal z ogłoszeniami o pracę (np. Pracuj, JustJoin, NoFluff) i wyszukaj oferty na juniora lub „regular” w Twojej okolicy (lub zdalnie).
• Policz, w ilu ogłoszeniach pojawia się Twój język / technologia. Nie potrzebujesz statystyki – zobacz po prostu, czy to pojedyncze sztuki, czy dziesiątki ogłoszeń.
• Przeczytaj wymagania: co poza językiem się powtarza? Frameworki, bazy, narzędzia. Zapisz to – przyda się przy planowaniu kolejnych etapów nauki.

Jeśli lokalnie prawie nie ma ofert na Pythona w webie, a jest mnóstwo na Java/.NET, może warto lekko skorygować kurs. Plan ma Ci pomóc dojść do pracy (jeśli to Twój cel), a nie realizować „estetyczne” preferencje.

Projekt 12 miesięcy: mapa drogowa „dużych kamieni”

Podział na 4 etapy po 3 miesiące

Żeby 12-miesięczna nauka programowania była do dowiezienia, dobrze jest myśleć o niej jak o serii czterech kwartałów, z jasno zdefiniowanymi „dużymi kamieniami” – czyli kluczowymi celami danego okresu.

Etap 1 (miesiące 1–3): fundamenty programowania i podstawy narzędzi

Cel: zrozumieć podstawowe konstrukcje w wybranym języku i poczuć się swobodnie w środowisku pracy programisty. Pod koniec tego etapu powinieneś umieć napisać kilkanaście prostych, ale działających programów / skryptów i wrzucić je na GitHuba.

Etap 2 (miesiące 4–6): pierwsze mini‑projekty i solidne podstawy technologii

Cel: przejść od ćwiczeń „z książki” do małych, ale spójnych projektów. Zaczynasz poznawać główny framework lub bibliotekę, z którą wiążesz swoją ścieżkę (np. React, Django, Spring, .NET). Uczysz się łączyć backend z bazą danych, frontend z API albo pisać sensowne testy.

Etap 3 (miesiące 7–9): większy projekt + ekosystem (framework, testy, Git)

Cel: zbudować 1–2 większe projekty, które nie są już zabawkami na 200 linii kodu, tylko czymś, czym można się pochwalić w portfolio. Do tego dochodzi praca z kontrolą wersji w sposób zbliżony do zespołowego, pierwsze testy jednostkowe, nauka czytania dokumentacji i zadawania pytań (np. na Stack Overflow, Discordach, Slacku).

Etap 4 (miesiące 10–12): portfolio, przygotowanie do rekrutacji, utrwalenie wiedzy

Cel: uporządkować wszystko, co już umiesz, dokończyć projekty, ubrać je w sensowną formę (GitHub, opisy, demo), sprawdzić się na zadaniach rekrutacyjnych i rozmowach technicznych. To też moment na uporządkowanie teorii: algorytmy, struktury danych na podstawowym poziomie, typowe pytania o język i frameworki.

Taki podział na etapy nie jest po to, żeby się go kurczowo trzymać, tylko żeby wiedzieć, co jest teraz najważniejsze. Bez tego łatwo ugrzęznąć w wiecznym dokupywaniu kursów i „oglądaniu tutoriali”, zamiast iść do przodu.

Jak z „mapy” zrobić plan na kalendarz

Mapa to za mało. Trzeba ją przełożyć na konkretny kalendarz: miesiące, tygodnie, nawet dni. Dobrze działa zasada: od ogółu do szczegółu.

1. Rozpisz kwartalne cele na miesięczne. Jeśli w miesiącach 1–3 masz opanować podstawy języka, to:
   • miesiąc 1 – składnia, zmienne, typy, instrukcje warunkowe, pętle;
   • miesiąc 2 – funkcje, kolekcje, proste wejście/wyjście, podstawy pracy z plikami/HTTP;
   • miesiąc 3 – małe projektiki łączące to wszystko + podstawy Git.
2. Rozpisz miesięczne cele na tygodnie. Np. „tydzień 1: pętle i warunki + 3 małe zadania”, „tydzień 2: funkcje + 3 zadania”, itd.

Przekładanie tygodni na codzienną rutynę

Miesięczne i tygodniowe cele są jak plan miasta. Ale żeby rzeczywiście dokądś dojść, potrzebujesz jeszcze codziennej trasy: skręt tu, przejście dla pieszych tam. Bez tego bardzo łatwo wpaść w tryb „nadrabiania w weekend”, który zwykle kończy się zmęczeniem i poczuciem winy.

Przy planowaniu dnia kluczowe są trzy elementy: realistyczny czas, konkretne zadania i rytuał startu.

• Realistyczny czas – jeśli pracujesz lub studiujesz, 2 godziny dziennie nauki programowania to maksimum, które da się regularnie dowieźć. Dla wielu osób 60–90 minut to złoty środek. Lepiej 5 dni po godzinie niż 1 dzień przez 5 godzin.
• Konkretnie, nie „uczyć się” – zamiast „dziś uczę się Pythona”, zapisuj: „obejrzeć lekcje 3–4 z kursu, zrobić 6 zadań o pętlach, wrzucić rozwiązania na GitHuba”. Im mniej miejsca na interpretację, tym mniejsza szansa, że się rozmyjesz.
• Rytuał startu – coś, co kojarzy się tylko z nauką programowania: włączenie konkretnej playlisty, zaparzenie herbaty, otwarcie tego samego IDE. Mózg lubi takie sygnały: „o, teraz robimy to”.

Dobrym trikiem jest też planowanie na dzień następny. Na koniec sesji nauki otwórz notatkę i napisz 2–3 mini‑zadania na jutro. Rano nie zastanawiasz się „od czego zacząć?”, tylko odpalasz gotową listę.

Miesiące 1–3: solidne fundamenty i higiena nauki

Cel etapu: myśleć w wybranym języku

Pierwszy kwartał nie jest po to, żeby znać wszystkie biblioteki. Chodzi o to, żebyś zaczął myśleć w kategoriach: „mam problem → rozbijam go na kroki → zapisuję te kroki w kodzie”. Język to tylko narzędzie – ale dobrze, jeśli trzymasz je już pewnie w ręku.

Na końcu 3. miesiąca chcesz umieć:

• swobodnie używać zmiennych, typów, warunków, pętli i funkcji w wybranym języku,
• rozumieć komunikaty błędów i samodzielnie je googlować,
• korzystać z podstaw IDE lub edytora (skrótów, podpowiedzi, debuggera na bazowym poziomie),
• pracować z Git i GitHubem w najprostszej formie (init, commit, push),
• mieć na profilu kilka małych, ale działających programów / zadań.

Miesiąc 1: oswojenie z językiem i narzędziami

Pierwszy miesiąc to zwykle miks ekscytacji i lekkiej frustracji. Z jednej strony wszystko jest nowe i ciekawe, z drugiej – drobna literówka potrafi zepsuć wieczór. Dobrze jest od razu założyć, że poczucie „jestem głupi” jest częścią procesu, a nie sygnałem, że się nie nadajesz.

Propozycja zakresu na 4 tygodnie:

• Instalacja środowiska – język, IDE/edytor (VS Code, IntelliJ, PyCharm, Rider, itp.), konfiguracja pierwszego projektu.
• Podstawy składni – zmienne, typy proste, operatory, instrukcje warunkowe, podstawowe pętle.
• Wejście/wyjście – wczytywanie danych od użytkownika lub z pliku, wypisywanie wyników.
• Drobne zadania „z życia”:
  • kalkulator wydatków (podajesz kilka liczb, dostajesz sumę i średnią),
  • prosty konwerter (np. walut, temperatur),
  • program liczący ratę kredytu wg prostego wzoru.

Na tym etapie przydają się proste źródła wiedzy: kurs wideo typu „wprowadzenie do języka” + książka lub dokumentacja dla początkujących. Chodzi o to, żebyś miał jedno główne źródło, do którego wracasz, zamiast przeskakiwać między dziesięcioma kursami.

Miesiąc 2: funkcje, kolekcje i pierwsze „mini‑moduły”

Kiedy ogarniesz już warunki i pętle, przychodzi czas na wyjście z „trybu kalkulatora”. Kod zaczyna się robić dłuższy, więc trzeba porządkować go za pomocą funkcji i kolekcji (listy, tablice, słowniki, mapy – w zależności od języka).

W drugim miesiącu dobrze jest skupić się na:

• definiowaniu i wywoływaniu funkcji – parametry, wartość zwracana, proste podziałanie zadań: „funkcja liczy, główny program obsługuje wejście/wyjście”,
• kolekcjach – dodawanie, usuwanie, iterowanie po elementach, wyszukiwanie, filtrowanie,
• podstawach pracy z plikami lub prostym API – np. zapisywanie wyników do pliku tekstowego, odczyt, lub wywołanie jednego publicznego API (np. pogoda),
• rozbijaniu problemu na mniejsze kroki – zanim zaczniesz pisać, spróbuj wypisać sobie na kartce krok po kroku, co ma robić program.

Przykładowe mini‑projekty na tym etapie:

• lista zadań (to‑do) w konsoli – dodawanie, usuwanie, oznaczanie jako zrobione, zapis do pliku,
• analizator tekstu – wczytuje plik, liczy słowa, zdania, najczęściej występujące wyrazy,
• prosta gra tekstowa – zgadywanie liczby, quiz, „kamień, papier, nożyce”.

Wiele osób na tym etapie łapie się na tym, że „ciągle ogląda” i mało pisze. Dobrym patentem jest reguła 50/50: połowa czasu na teorię (czytanie, oglądanie), połowa na praktykę (pisanie własnego kodu, nawet jeśli jest toporny).

Miesiąc 3: projekt na fundamentach + Git w praktyce

Trzeci miesiąc to pierwsza mała „sesja egzaminacyjna”. Nie w sensie uczelnianym, tylko w tym znaczeniu, że sprawdzasz, czy potrafisz samodzielnie dowieźć coś od pomysłu do działającego kodu.

Na tym etapie możesz zaplanować:

• 1–2 małe projekty łączące wszystko, czego się nauczyłeś: funkcje, kolekcje, prosta logika, obsługa błędów.
• Podstawy Git:
  • tworzenie repozytorium,
  • commit z sensownym opisem,
  • push do GitHuba,
  • praca na branchu (chociaż jeden eksperymentalny branch do funkcji).
• Porządkowanie kodu – dzielenie na pliki, nadawanie sensownych nazw funkcjom i zmiennym, krótkie komentarze tam, gdzie logika nie jest oczywista.

Przykładowy projekt na koniec kwartału:

• prosta aplikacja do zarządzania budżetem domowym (kategorie, wydatki, raport miesięczny),
• generator planu nauki – wpisujesz, ile masz dni, ile tematów, a program rozkłada je na harmonogram,
• mini‑biblioteka w konsoli – dodawanie książek, wyszukiwanie, filtrowanie, zapis do pliku.

Wyślij taki projekt znajomemu lub pokaż na grupie początkujących programistów. Reakcje innych (nawet drobne uwagi) pomagają przełamać opór przed pokazywaniem swojego kodu – a to będzie bardzo potrzebne przy dalszej nauce i później na rozmowach rekrutacyjnych.

Higiena nauki: jak się nie „zajechać” w 3 miesiące

Pokusą początku jest „jadę na pełnej, 3 godziny dziennie, zero dnia przerwy”. To działa może przez 2 tygodnie. Potem trzeba zbierać się z podłogi. Dużo lepszy jest tryb sportowca amatora: regularny trening, dni regeneracji, brak wyrzutów sumienia, gdy zdarzy się słabszy dzień.

Co pomaga utrzymać higienę nauki?

• Stałe okno czasowe – nauka o podobnej porze (np. 19:00–20:30) sprawia, że nie musisz codziennie decydować „czy dziś się uczę?”, tylko po prostu robisz swoje.
• Limity – paradoksalnie warto mieć górny limit. Zamiast „jak będę miał siłę”, narzuć sobie np. max 2 godziny. Dzięki temu nie spalisz się pierwszego dnia.
• Mikro‑cele – codziennie coś małego: jedno zadanie z pętlą, poprawienie jednego błędu, push na GitHuba. W gorsze dni wystarczy 20–30 minut, byle nie zrywać łańcucha.
• Świadomy odpoczynek – 1 dzień w tygodniu bez programowania. Bez nadrabiania sumieniem, bez kar. Odpoczywasz po to, żeby tydzień 2 i 3 też w ogóle nastąpiły.

Przydaje się też prosty system śledzenia postępów: kalendarz na ścianie, habit tracker w aplikacji, notatnik z datami. Odhaczenie kolejnego dnia nauki to zaskakująco silny motywator.

Miesiące 4–6: od ćwiczeń do pierwszych sensownych projektów

Cel etapu: połączyć klocki w mały system

Drugi kwartał to moment, gdy wychodzisz z piaskownicy ćwiczeń i zaczynasz składać z poznanych klocków coś, co przypomina prawdziwą aplikację. To nie musi być „startup życia”. Chodzi o system, w którym jest już kilka warstw: np. interfejs + logika + dane.

Na końcu 6. miesiąca chcesz umieć:

• korzystać z głównego frameworka lub biblioteki na poziomie podstawowym (np. React, Django, Spring, .NET, Express),
• zrobić projekt CRUD – tworzenie, odczyt, aktualizacja, usuwanie danych,
• zintegrować aplikację z bazą danych lub API,
• odtworzyć prostą aplikację z tutoriala, a potem ją zmodyfikować pod siebie,
• poradzić sobie z typowymi błędami frameworka (logi, stack trace, googlowanie).

Miesiąc 4: wejście w framework i „hello world” w świecie web/GUI

Początek pracy z frameworkiem to trochę jak zmiana samochodu z manualnej skrzyni na automatyczną. Z jednej strony prościej, bo nie musisz wszystkiego ogarniać ręcznie. Z drugiej – musisz zaufać, że „pudełko” wie, co robi, i nauczyć się jego zasad.

W czwartym miesiącu dobrze jest:

• wybrać główny framework, zgodny z Twoją ścieżką i rynkiem (np. frontend → React/Angular/Vue, backend w Javie → Spring, Python → Django/Flask/FastAPI, C# → ASP.NET Core),
• przejść jeden, spójny tutorial kończący się działającą aplikacją (np. prosty blog, lista zadań, małe API),
• zrozumieć strukturę projektu w danym frameworku – gdzie są pliki konfiguracyjne, gdzie logika, gdzie widoki/komponenty,
• zacząć korzystać z dokumentacji frameworka (nie tylko z filmów).

Na tym etapie typowe jest uczucie „no dobra, ale ja nie rozumiem połowy kodu z tutoriala”. I to jest w porządku. Kluczem jest przejście takiej ścieżki 2–3 razy, a potem próba napisania prawie tego samego projektu od zera, zaglądając w razie potrzeby do oryginału.

Miesiąc 5: pierwszy „prawdziwy” projekt CRUD

CRUD to skrót, który często pojawia się w ogłoszeniach: Create, Read, Update, Delete. Większość aplikacji biznesowych sprowadza się właśnie do tego, tylko w ładniejszym opakowaniu. Umiejętność zrobienia prostego CRUD‑a od zera to duży krok w stronę „prawdziwego kodowania”.

Co możesz zrobić w piątym miesiącu:

• Zaplanować domenę projektu – np. aplikacja do zarządzania treningami, planer nauki, proste CRM dla freelancera, system zgłoszeń serwisowych.
• Zaprojketować dane – jakie tabele/kolekcje będą w bazie, jakie pola są potrzebne, jakie relacje (np. użytkownik → zadania).
• Utworzyć API lub warstwę logiki obsługującą operacje CRUD:
  • tworzenie nowego wpisu,
  • pobieranie listy wpisów,
  • edycja,
  • usuwanie.
• Jeśli jesteś po stronie frontendu – połączyć się z API (choćby prostym, lokalnym) i obsłużyć te operacje z poziomu interfejsu.

Miesiąc 6: domknięcie pierwszego systemu i pokazanie go światu

Szósty miesiąc to czas, żeby z Twojego CRUD‑a zrobić coś, co choć trochę przypomina mini‑produkt. Nie chodzi o dopieszczony design, tylko o aplikację, którą da się komuś pokazać, kliknąć kilka ścieżek i nie bać się, że wszystko wybuchnie.

Dobrze jest wtedy skupić się na kilku rzeczach naraz, ale w rozsądnym zakresie:

• Stabilność – obsługa błędów (np. co się dzieje, gdy API nie działa, brakuje danych, użytkownik wpisze głupoty w formularzu).
• Minimalny „UX dla ludzi” – proste komunikaty o błędach, potwierdzenia akcji („Na pewno usunąć?”), sensowne nazwy przycisków.
• Prosty deploy – wrzucenie aplikacji tam, gdzie ktoś inny może jej użyć: np. Netlify/Vercel dla frontendu, Render/Railway/inna chmura dla backendu.
• Czytelność kodu – drobny refactoring: usuwanie duplikatów, wydzielanie powtarzających się fragmentów do funkcji, porządek w strukturze katalogów.

Dobrym rytuałem jest zrobienie na koniec tego etapu czegoś w rodzaju „demo day” dla samego siebie. Otwierasz aplikację, nagrywasz 5–10‑minutowy screencast, w którym przechodzisz po głównych funkcjach i opowiadasz, jak to działa od środka. Takie nagranie przyda się później w portfolio, a przy okazji zobaczysz, które miejsca jeszcze zgrzytają.

Jeśli masz odwagę, poproś 1–2 osoby (niekoniecznie techniczne), żeby poklikały po aplikacji bez Twoich podpowiedzi. Obserwuj, gdzie się gubią, co jest dla nich niejasne, które funkcje ignorują. To pierwszy przedsmak prawdziwej pracy z użytkownikiem.

Uczenie się na błędach: dziennik problemów

Drugi kwartał to też okres, w którym zaczynają Cię dopadać „magiczne błędy frameworka”. Czerwone logi, dziwne komunikaty, tajemnicze stack trace. Zamiast klikać losowo w Stack Overflow, spróbuj wprowadzić prosty zwyczaj: dziennik problemów.

Może to być plik Markdown w repozytorium albo zwykły notatnik. Za każdym razem, gdy utkniesz na dłużej niż 20–30 minut, zapisujesz:

• krótki opis problemu (1–2 zdania),
• pełny komunikat błędu,
• co próbowałeś, zanim zadziałało,
• finalne rozwiązanie (link, fragment kodu, konfiguracja).

Po kilku tygodniach odkryjesz zabawną rzecz: część błędów się powtarza, a Ty zaczynasz rozpoznawać je „po zapachu”. To znaczy – widzisz wzorzec, kojarzysz wcześniejszy wpis w dzienniku i zamiast godziny szukania, naprawiasz w 5 minut.

Miesiące 7–9: od „działającego kodu” do kodu, z którego możesz być dumny

Cel etapu: jakość, zespołowe nawyki i większe projekty

Trzeci kwartał to przesunięcie akcentu. Nie chodzi już tylko o to, żeby „działało”, ale żeby dało się z tym żyć: rozwijać, poprawiać, współpracować z innymi. Zaczynasz myśleć bardziej jak programista w zespole, a mniej jak samotny wojownik.

Na końcu 9. miesiąca opłaca się być w miejscu, gdzie:

• rozumiesz podstawy testowania (przynajmniej testy jednostkowe na prostych funkcjach),
• potrafisz pracować w workflow Git‑owym przypominającym realny zespół: branch, pull request, code review,
• masz za sobą jeden większy projekt rozwijany przez kilka tygodni, a nie pojedynczy weekend,
• znasz kilka podstawowych wzorców projektowych lub dobrych praktyk w swoim ekosystemie,
• masz przynajmniej ogólne pojęcie o wydajności i prostym profilowaniu: co spowalnia aplikację, jak mierzyć czas wykonania.

Miesiąc 7: wejście w testy i sprzątanie po pierwszym półroczu

Siódmy miesiąc to dobry moment na mentalne „wiosenne porządki”, nawet jeśli w kalendarzu jest jesień. Masz już kilka repozytoriów, pewnie trochę bałaganu i sporo powtarzalnych błędów. Zamiast pędzić dalej, zatrzymaj się na chwilę i podnieś jakość tego, co już istnieje.

Możesz to ugryźć w trzech krokach:

1. Refactoring wybranego projektu – wybierz jedną aplikację (np. CRUD z miesięcy 5–6) i:
   • posprzątaj nazwy funkcji, klas, komponentów,
   • usuń martwy kod (zakomentowane fragmenty, niewykorzystywane funkcje),
   • podziel zbyt duże pliki na mniejsze moduły.
2. Podstawy testów jednostkowych – zainstaluj popularne narzędzie w swoim języku (JUnit, pytest, Jest, NUnit itp.) i:
   • napisz testy do kilku prostych funkcji (np. obliczenia, walidacja danych),
   • uruchom je z linii komend, zobacz, jak wygląda zielony i czerwony wynik,
   • naucz się, jak odpalić wszystkie testy jednym poleceniem.
3. Automatyzacja drobiazgów – proste skrypty lub polecenia:
   • „uruchom serwer + frontend” jednym skryptem,
   • „odpal wszystkie testy”,
   • „zrób build produkcyjny”.

To nie są spektakularne rzeczy, ale właśnie tak wygląda codzienność w prawdziwych projektach. Małe usprawnienia, które oszczędzają setki kliknięć po kilku miesiącach.

Miesiąc 8: praca „jak w zespole” – nawet jeśli jesteś sam

Nawet jeśli uczysz się solo, możesz zasymulować część z tego, co dzieje się w komercyjnym projekcie. Chodzi o nawyki, nie o wielkość kodu.

W ósmym miesiącu spróbuj wdrożyć:

• Pracę na branchach tematycznych – każdy większy feature w osobnej gałęzi, np. feature/logowanie, feature/filtry.
• Pull requesty do samego siebie – nawet jeśli pracujesz sam, twórz PR‑y i przeglądaj diff przed mergem. Zadawaj sobie pytania:
  • czy ten kod jest zrozumiały za tydzień?
  • czy tu nie ma prostszego rozwiązania?
• Prosty opis zadań – zamiast „dziubać, co się nawinie”, zrób listę issue (np. w GitHub Issues lub Trello) i pracuj w małych porcjach: 1 zadanie = 1 branch = 1 PR.
• Commit messages, które coś znaczą – koniec z „fix”, „poprawki”. Zamiast tego:
  • add filtering by date to training list,
  • handle API timeout error on dashboard.

Jeśli masz choć jedną osobę uczącą się podobnie jak Ty, zaproponuj wspólny mini‑projekt. Nawet dwie godziny tygodniowo na callu z dzieleniem ekranu bardzo otwierają oczy: zobaczysz inne skróty klawiaturowe, inne pomysły na strukturę kodu, zderzysz swoje nawyki z cudzymi.

Miesiąc 9: większy projekt „na spokojnie”

Do tej pory większość aplikacji mogła powstać w tydzień czy dwa. Dziewiąty miesiąc to dobry moment, żeby zanurzyć się w większy projekt, rozłożony celowo na kilka tygodni. Tempo ma być świadomie wolniejsze, ale bardziej przemyślane.

Jak to ułożyć?

1. Wybór tematu – coś, co:
   • ma dla Ciebie sens (np. narzędzie, którego sam użyjesz),
   • ma kilka modułów/funkcji, a nie tylko jedną listę rzeczy,
   • można rozszerzać w przyszłości (np. najpierw wersja solo, potem z logowaniem użytkowników).

   Przykłady: planer treningowy z kalendarzem i statystykami, narzędzie do śledzenia czasu pracy, prosty system rezerwacji (np. wizyty u barbera), platforma z prostymi quizami.

2. Podział na etapy – rozpisz projekt na tygodnie:
   • tydzień 1: model danych + podstawowe CRUD,
   • tydzień 2: interfejs podstawowych ekranów,
   • tydzień 3: dodatkowe funkcje (filtry, sortowanie, statystyki),
   • tydzień 4: testy kluczowych funkcji, porządki, prosty deploy.
3. Dokumentowanie na bieżąco – w pliku README.md zapisuj:
   • co jest już zrobione,
   • co planujesz dalej,
   • jak uruchomić projekt (dla „obcego” developera).

To pierwsze zderzenie z tym, jak bardzo „rozsypuje się” plan, gdy pojawiają się niespodziewane trudności. I bardzo dobrze. Uczysz się realnej estymacji: ile jesteś w stanie dowieźć w tydzień, w dwa, w miesiąc.

Miesiące 10–12: układanie portfolio i jazda próbna przed pierwszą pracą

Cel etapu: pokazać efekty i dopiąć kompetencje „na wejście”

Ostatni kwartał to moment, kiedy przestajesz myśleć tylko o nauce, a coraz częściej o jakiejś formie wejścia na rynek: praktyki, staż, pierwsze rozmowy. Nie musisz od razu składać CV, ale zacznij układać swoje „programistyczne CV” w postaci kodu i projektów.

Na końcu 12. miesiąca sensownie jest mieć:

• 2–3 projekty, którymi naprawdę możesz się pochwalić (wdrożone lub łatwe do uruchomienia),
• profil GitHub/ GitLab, na którym widać regularną pracę i historię rozwoju,
• podstawowe pojęcie o tym, jak wygląda rekrutacja juniorskiego developera,
• przećwiczone mówienie o swoich projektach – jak o nich opowiadasz, co było trudne, czego się nauczyłeś.

Miesiąc 10: selekcja i dopieszczanie projektów do portfolio

Przez 9 miesięcy powstało pewnie sporo kodu. Nie wszystko nadaje się do pokazywania – i to normalne. W dziesiątym miesiącu działasz trochę jak kurator wystawy: wybierasz kilka najlepszych prac i lekko je retuszujesz.

Krok po kroku:

1. Wybierz 2–4 projekty, które:
   • pokazują różne umiejętności (np. jeden frontendowy, jeden backendowy, jeden „fullstack”),
   • da się uruchomić w rozsądnym czasie (instrukcje, brak magicznych kroków),
   • są ukończone w jakimś sensie – nie wieczne „w budowie”.
2. Dodaj porządne README do każdego:
   • krótki opis: co to jest i dla kogo,
   • screeny lub GIF z działania,
   • jak uruchomić (wymagania, komendy),
   • lista technologii,
   • co mógłbyś dodać w przyszłości (2–3 pomysły).
3. Sprawdź jakość kodu:
   • usuń „debugowe śmieci”: console.log, printy, tymczasowe pliki,
   • przejdź się po projekcie formatowaniem (prettier, black, ktlint itp.),
   • upewnij się, że testy (jeśli są) przechodzą na czysto.

Jeśli masz siłę, nagraj krótki spacer po projekcie (2–5 minut) i wrzuć link w README. Nawet proste nagranie z darmowego narzędzia będzie dla rekrutera bardziej namacalne niż same zrzuty ekranu.

Miesiąc 11: symulacja rozmów technicznych i powtórka fundamentów

Po roku nauki najgorsze, co można zrobić, to spalić się na pytaniu o pętlę czy różnicę między tablicą a listą. Dlatego jeden miesiąc dobrze jest przeznaczyć na świadomą powtórkę fundamentów i pierwsze „jazdy próbne” z zadaniami rekrutacyjnymi.

Możesz podejść do tego tak:

• Lista tematów do odświeżenia – spisz na kartce lub w notatniku:
  • podstawy języka (typy, pętle, warunki, funkcje, klasy/obiekty),
  • kolekcje i ich typowe operacje,
  • obsługa błędów/wyjątków,
  • podstawy algorytmiczne (sortowanie, wyszukiwanie, złożoność w bardzo uproszczonej formie).

Najważniejsze wnioski

• Plan na 12 miesięcy ma sens tylko wtedy, gdy wiesz, po co się uczysz programowania – inny rytm i priorytety ma ktoś, kto chce „ogarniać kod”, a inny osoba celująca w pełne przebranżowienie na juniora.
• Uczenie się programowania to co innego niż bycie gotowym do pracy w IT: sama znajomość składni nie wystarczy, potrzebne jest też rozumienie procesu tworzenia oprogramowania, narzędzi i typowych problemów w zespole.
• Przy regularnej pracy da się w rok dojść do poziomu kandydata na juniora (2–3 godziny dziennie), mocnego hobbysty (1–1,5 godziny dziennie) albo osoby „rozumiejącej, o co chodzi” przy mniejszym wysiłku – ale bez gwarancji szybkiej, wysokopłatnej pracy.
• Najczęściej zabijają motywację nierealne oczekiwania: kurs za kilka tysięcy nie zrobi z nikogo mida, 5 godzin nauki dziennie po pracy zwykle kończy się po tygodniu, a „pierdyliard” na koncie po roku to bardziej mit niż plan.
• Skuteczny harmonogram musi uwzględniać Twoją sytuację życiową: student, pracownik na etacie czy rodzic ma inne zasoby czasu i energii, dlatego lepiej dopasować bloki nauki do siebie niż kopiować cudze rozpiski z internetu.
• Żeby znaleźć czas na kodowanie, trzeba świadomie coś odciąć – mniej scrollowania, seriali czy gier; proste pytanie „z czego jestem gotów zrezygnować na 12 miesięcy?” często decyduje, czy plan wytrzyma zderzenie z rzeczywistością.