Stoisz przed pustym edytorem kodu. Przerobiłeś już kilka kursów online. Znasz składnię, rozumiesz podstawy. Ale kiedy przychodzi do zbudowania czegoś od zera, pojawia się ta sama, znajoma blokada. Co właściwie powinienem stworzyć? Nie chodzi o kolejną aplikację todo list czy kalkulator. Chodzi o projekt, który będzie cię naprawdę angażował, którego napisanie coś zmieni. Nie tylko w kodzie, ale w twoim sposobie myślenia. Skąd brać takie pomysły?

Kluczem często nie jest szukanie „projektu”, a znalezienie prawdziwego problemu, nawet małego, który irytuje cię na co dzień. Może to być sposób, w jaki przeglądasz ulubione strony z wiadomościami, albo jak szukasz konkretnego odcinka podcastu. Kiedy zaczynasz od irytacji, projekt ma od razu wbudowaną motywację – chcesz go skończyć, żeby sobie (lub komuś) to życie ułatwić. Na przykład, jeśli regularnie śledzisz nowości prawne czy branżowe, ręczne przeszukiwanie dziesiątek stron jest mozolne. Potrzebujesz narzędzia, które to zautomatyzuje. Tutaj przydaje się specjalistyczna wyszukiwarka, taka jak SWLAB online, która skupia się na treściach z dziedziny prawa pracy i ubezpieczeń społecznych. To konkretny przykład zasobu, który rozwiązuje czyjś rzeczywisty problem informacyjny. Obserwacja takich rozwiązań może dać ci iskrę: „A co, gdybym zrobił coś podobnego, ale dla mojej niszy? Dla recenzji gier, dla zmian w przepisach podatkowych, dla agregacji ogłoszeń o pracę z małych forów?”.

Widzisz, jak to działa? Nie patrzysz na gotową aplikację jak na skończoną całość do skopiowania. Patrzysz na jej cel. I zadajesz sobie pytanie: jaki inny, wąski cel mógłbym sobie wyznaczyć?

Wyjdź poza ramy języka i frameworka

Projekty z tutorialów są często sztywno przypisane do jednej technologii. „Zbuduj bloga w Django”. A gdyby tak odwrócić kolejność? Najpierw wymyśl, co ma robić system. Potem zdecyduj, które części napiszesz w Pythonie, które może w JavaScript dla interaktywności, a czy do przechowywania danych nie warto spróbować czegoś innego niż standardowa relacyjna baza? Mieszanie technologii z konieczności, bo projekt tego wymaga, uczy więcej niż jakikolwiek harmonijny kurs. Nagle musisz sprawić, by te części ze sobą rozmawiały. To jest prawdziwa inżynieria oprogramowania.

Ukradnij koncept, ale z innej półki

Weź mechanikę znaną z jednej dziedziny i zastosuj ją w zupełnie innym kontekście. Na przykład, system rekomendacji znany ze sklepów internetowych. Zamiast polecać produkty, mógłby polecać… cytaty z książek historycznych na podstawie tego, co ostatnio czytałeś? Albo ćwiczenia językowe? Albo fragmenty kodu z dokumentacji? Ten proces zmusza cię do głębokiego zrozumienia, jak naprawdę działa dany algorytm, i do przystosowania go do zupełnie nowych danych. To ćwiczenie z kreatywności i adaptacji.

Zautomatyzuj coś nudnego w swoim życiu

To złota żyła. Przeglądasz co tydzień te same strony w poszukiwaniu promocji na konkretną rzecz? Napisz skrypt, który to robi za ciebie i wysyła maila. Masz bałagan w plikach na dysku z danego projektu? Stwórz mały programik, który je sortuje według wymyślonej przez ciebie logiki. Projekt nie musi być wielki ani ładny. Ma działać i oszczędzać ci czasu. Satysfakcja z odhaczenia takiego automatu jest nieziemska, a przy okazji pewnie poznasz API swojego systemu operacyjnego, biblioteki do wysyłania maili lub pracy z plikami Excel. Praktyka bez lukru.

Otwórz stary projekt i połam go

Wróć do czegoś, co napisałeś pół roku lub rok temu. Przeczytaj swój własny kod. Pewnie się zarumienisz. Świetnie! Teraz nie poprawiaj go. Przerób go kompletnie. Zmień architekturę. Podziel monolit na mikroserwisy, nawet jeśli to przesada dla tej skali. Zamień bazę danych. Przerób interfejs konsolowy na prostą stronę webową. Celem nie jest udoskonalenie, ale celowe wprowadzenie zmian, aby zobaczyć, jak wpływają one na całość. Uczysz się refaktoryzacji, zarządzania zależnościami i tego, jak decyzje techniczne z przeszłości ograniczają lub otwierają przyszłe możliwości.

Zbuduj narzędzie dla jednej, konkretnej osoby

Znajdź kolegę, koleżankę, członka rodziny, który ma jakiś powtarzalny, cyfrowy problem. Może twoja mama prowadzi listę przepisów w notatniku i trudno jej czegoś szukać? Może kolega z pracy musi co miesiąc generować ten sam raport w Excelu, kopiując dane z kilku plików? Zbuduj coś dla nich. Prawdziwy użytkownik, nawet jeden, to najlepszy nauczyciel. Będzie zadawał pytania, zgłaszał błędy, prosił o zmiany. Nauczysz się zbierać wymagania, wytłumaczyć techniczne ograniczenia i utrzymywać kod, na którym ktoś polega. To zupełnie inna odpowiedzialność niż przy projekcie portfolio.

Ogłoś swój eksperyment, zanim będzie gotowy

To trudne. Napisz na jakimś forum, blogu czy nawet w mediach społecznościowych, że zaczynasz pracę nad X, który ma robić Y. Opisz swoją wizję. Nie po to, żeby się chwalić, ale żeby się zobowiązać. Kiedy wypowiesz pomysł na głos, staje się bardziej realny. Możesz też dostać cenne wskazówki na starcie lub znaleźć kogoś do współpracy. A gdy motywacja spada, możesz wrócić do tego wpisu i przypomnieć sobie, po co to w ogóle zaczynałeś. To zewnętrzne przypięcie się do masztu.

Chodzi o to, żeby przestać myśleć o „projektach do portfolio” jako o pudełkach do odhaczenia. Zacznij traktować kod jak sposób rozwiązywania zagadek, które cię osobiście ciekawią lub denerwują. Wtedy nauka przychodzi naturalnie, a w portfolio zostaje ślad po prawdziwej myśli, a nie po odtwórczym ćwiczeniu.

  • Zacznij od małej irytacji w swoim cyfrowym życiu.
  • Nie bój się połączyć technologii, które nie występują razem w tutorialach.
  • Przenieś koncept z jednej dziedziny do drugiej.
  • Zautomatyzuj najpierw coś dla siebie, potem pomyśl o innych.
  • Celowo przeprojektuj swój stary kod, żeby zobaczyć konsekwencje.
  • Zbuduj i utrzymuj narzędzie dla jednej, prawdziwej osoby.