Katy, projekty czy kursy: jak ćwiczyć programowanie, żeby to zostało

Możesz rozwiązać dwieście kat i mimo to zamarznąć, gdy ktoś pierwszy raz poda Ci prawdziwe repozytorium. Nie dlatego, że nie umiesz kodować — najwyraźniej umiesz — tylko dlatego, że kata wytrenowała jeden wąski mięsień, a praca potrzebuje sześciu. Pytanie nie brzmi, czy ćwiczyć. Brzmi, czy to, co ćwiczysz, jest tym, z czego naprawdę zostaniesz rozliczony.

Jak ćwiczyć programowanie, żeby to zostało

Ćwicz to, z czego rozliczą Cię w pracy, nie tylko to, co łatwo ocenić na stronie z zadaniami. Katy dobrze trenują jedną umiejętność — zamianę jasno opisanego problemu na działającą składnię — i ta umiejętność jest realna. Ale proces inżynierski to inny mięsień: układanie struktury projektu, praca z gitem, decydowanie, co przetestować, i pisanie tych testów, czytanie code review, dowożenie zmian przez CI. Tego mięśnia nie zbudujesz kolejnymi katami. Budujesz go, robiąc dokładnie te rzeczy, na kodzie, który ma więcej niż jeden plik i więcej niż jedną poprawną odpowiedź.

Co naprawdę trenuje kata

Oto zwykła kata. Mając listę liczb całkowitych i cel, zwróć indeksy dwóch liczb, które się do niego sumują:

def two_sum(nums: list[int], target: int) -> tuple[int, int]:
    seen = {}
    for i, n in enumerate(nums):
        if target - n in seen:
            return seen[target - n], i
        seen[n] = i
    raise ValueError("no pair sums to target")

pytest -q
5 passed in 0.19s

To dobre ćwiczenie. Nagradza wiedzę, że wyszukanie w słowniku bije zagnieżdżoną pętlę, i szybko karze, gdy zapomnisz o przypadku brzegowym, w którym żadna para nie pasuje. Rozwiąż pięćdziesiąt takich, a Twoja składnia stanie się płynna, instynkt algorytmiczny się wyostrzy, a czytanie cudzego kodu przyjdzie łatwiej. To coś warte.

A teraz spójrz, co kata dała Ci za darmo. Problem był w pełni opisany. Sygnatura funkcji — ustalona. Testy już istniały, napisane przez kogoś innego. Był jeden plik, żadnego gita, żadnego review i nic do nazwania poza dwiema lokalnymi zmiennymi. Zdejmij to wszystko, a to, co zostaje — czysty algorytm — to może jedna piąta tego, co robi programista w ciągu dnia. Kata trenuje tę piątą, której nauczyłbyś się i tak, a pomija cztery piąte, które są trudne.

Czym praca jest naprawdę

Prawdziwe zadanie nie przychodzi jako sygnatura i zestaw testów. Przychodzi jako zdanie: „usługa wyżej wysyła nam rekordy użytkowników i część jest wadliwa — spraw, żeby wczytywanie się nie wywracało". I nagle masz decyzje, które kata podjęła za Ciebie. Co liczy się jako wadliwe? Odrzucasz złe rekordy czy zbierasz błędy? Jak w ogóle nazywa się ta funkcja i gdzie mieszka? Który przypadek zasługuje na test, a który tylko zakładasz, że nigdy się nie zdarzy?

Załóżmy, że piszesz pierwszą wersję, a recenzent zostawia jeden komentarz: „co się dzieje, gdy records jest puste, a co gdy jest None — czy dla wywołującego to to samo?". To jedno pytanie jest całą grą, a składnia nie ma z nim nic wspólnego — składnię znałeś na wylot. Sprawdza ono nawyk myślenia poza szczęśliwą ścieżką, nawyk, o którego zbudowanie kata nigdy nie prosi, bo dane w kacie zawsze przychodzą poprawne. Odpowiadasz na nie, pisząc test, który przybija to zachowanie do podłogi:

def test_empty_and_none_both_yield_no_records():
    assert ingest([]) == ([], [])
    assert ingest(None) == ([], [])   # brak paczki to nie błąd

pytest -q
9 passed in 0.24s

Ta sama osoba, ten sam Python, zupełnie inna umiejętność. Wersja Ciebie od kat napisze wewnętrzną pętlę ingest przez sen. Wersja inżynierska wie, że pętla nigdy nie była ryzykowną częścią.

Dlaczego kursy wideo przenoszą jeszcze mniej

Jeśli katy trenują piątą część roboty, to kurs wideo często trenuje mniej, bo oglądanie to nie robienie. Dobrze zrobiony kurs sprawia wrażenie produktywnego — kod prowadzącego się uruchamia, pojęcia wpadają do głowy, kiwasz głową. Potem otwierasz pusty plik i odkrywasz, że rozpoznanie rozwiązania, gdy ktoś Ci je pokazuje, i wyprodukowanie go z niczego to dwie osobne zdolności, a wytrenowałeś tylko pierwszą. To pułapka tutoriali: czterdzieści godzin obejrzanego materiału, które sypie się w chwili, gdy znika prowadzenie za rękę i nie ma kolejnego przycisku „play", jest tylko problem i migający kursor.

Kursy mają swoje miejsce — to niezły sposób, żeby spotkać pojęcie po raz pierwszy. Ale traktowanie „skończyłem kurs" jako „nauczyłem się umiejętności" to ten sam błąd, co branie kat za ćwiczenie inżynierii. Liczysz wejście i liczysz, że wyjście za nim poszło. Zwykle nie poszło. Uczciwą wersję tego rachunku znajdziesz w tekście o tym, ile czasu naprawdę zajmuje nauka Pythona: liczą się godziny spędzone na produkowaniu, na odpowiednim poziomie trudności, a nie te spędzone na oglądaniu.

To jak ćwiczyć proces?

Ćwicząc go wprost, w najmniejszej formie, która wciąż go zawiera. Nie potrzebujesz dwunastoosobowego zespołu, żeby nauczyć się code review — potrzebujesz jednego uczciwego recenzenta i własnego kodu przed nim. Nie potrzebujesz awarii na produkcji, żeby nauczyć się testowania — potrzebujesz jednego zadania, w którym przypadek brzegowy jest sednem. Sztuką jest ćwiczyć te nudne cztery piąte celowo, zamiast czekać, aż wchłoniesz je przypadkiem w pierwszej pracy.

Taką pętlę ProdQuest uruchamia dziś. Zadanie to nie kata z gotowymi testami; jest oceniane deterministycznie — Twój kod przechodzi przez prawdziwe testy, analizę statyczną i skany bezpieczeństwa, które ważą co najmniej 70% oceny, a rubryka jakości najwyżej 30%. Sensem tego podziału jest ocenianie inżynierii, nie opinii, i to w mniej niż 30 sekund, żeby informacja zwrotna trafiła, gdy jeszcze pamiętasz, o czym myślałeś. Usłyszeć dokładnie, który assert nie przeszedł, na własnym kodzie — to mięsień review w miniaturze.

Reszta procesu dopiero nadchodzi, jeszcze jej nie ma. Pełny symulowany cykl — feature branch, pull request, agent czytający Twój diff jak senior, pipeline CI/CD pilnujący merge'a — to zaplanowany etap na mapie drogowej, nie coś, co odpalisz w tym tygodniu. Dziś istnieje jedna pętla: zadanie, ocena, nagroda, trzymana w strefie 70–80% skuteczności, gdzie praktyka jest wystarczająco trudna, żeby uczyć, i nie na tyle trudna, żebyś zrezygnował. Ta pętla już niesie więcej procesu niż jakakolwiek strona z katami, bo ocena patrzy na Twoje testy i Twoją strukturę, nie tylko na zwracaną wartość.

Uczciwa odpowiedź

Korzystaj z całej trójki, ale wiedz, co każde z nich kupuje. Kurs wprowadza pomysł. Katy sprawiają, że składnia staje się automatyczna, więc pomysł ma gdzie zamieszkać. Żadne z nich nie nauczy Cię układać struktury projektu, bronić decyzji w review ani pisać testu, który łapie błąd, zanim zrobi to recenzent — a ta ostatnia kategoria to większość roboty. Ćwicz ją jako osobną rzecz, świadomie, na prawdziwych zadaniach z prawdziwą oceną. Alternatywą jest nauka na produkcji, na cudzym deadline'ie.

Jeśli chcesz praktyki, która ocenia proces, a nie sam algorytm, dołącz do zamkniętej bety — pierwsze zadanie startuje w przeglądarce, bez instalacji, a ocena powie Ci, które cztery piąte dotąd omijałeś.