Budowałem przez 5 miesięcy w oczy publice. Nikt nie patrzył. 22 grudnia mnie zwolnili.
Jest taki moment w każdym projekcie, kiedy nagle zdajesz sobie sprawę, że budowałeś zupełnie złą rzecz.
Dla mnie ten moment pojawił się cztery razy.
Jak to się zaczęło
Dziewięć miesięcy temu wyjechałem z Polski do Holandii.
Ale nie na pracę w IT - pojechałem na pracę do magazynu.
order-picker.
15-20 kilometrów chodzenia codziennie. Skanowanie kodów kreskowych. Ładowanie palet.
W dzień: magazyn.
W nocy: budowanie oprogramowania na laptopie z 2014 roku, który grzeje się do 94°C.
Chciałem zrobić narzędzie do monitorowania komputera.
Nie kolejny dashboard pokazujący "CPU: 87%"
Ale coś, co naprawdę wyjaśni - DLACZEGO. Jaki proces? Jaka aplikacja w tle?
CO POWODUJE SKOK NAPIĘCIA?
Prosty koncept. Co się potem stało, było znacznie bardziej skomplikowane.
Rebuild #1: Pułapka "To Działa"
Moja pierwsza wersja wyglądała jak Windows 95 mający atak paniki.
`Co zbudowałem:
- Emoji wszędzie (myślałem że to "nowoczesne")
- Nieskończone scrollowanie
- Zero hierarchii wizualnej
- 15+ feature'ów których nikt nie prosił`
Ale działało. Technicznie rzecz biorąc. Liczby się aktualizowały. Dane były dokładne.
Byłem dumny... może przez dwa tygodnie.
Potem zacząłem to używać codziennie i nauczyłem się pierwszej, brutalnej lekcji:
"Działające" to nie to samo co "Dobre"
Jest kolosalna różnica między "kod się nie sypie" a "chciałbym patrzeć na to przez osiem godzin dziennie".
Linii napisane: ~15 000
Linii usunięte: ~15 000
Czasu zmarnowanego: 2 miesiące
``
Rebuild #2: Faza "Architekt Astronaut"
Klasyczny błąd. Poszedłem full "proper engineering":
`Co myślałem że ma znaczenie:
- Architektura event-driven ✓
- Modularny system pluginów ✓
- Czyste rozdzielenie odpowiedzialności ✓
- Prawidłowe design patterns ✓
Co faktycznie widzieli użytkownicy:
- Okropna mobilna aplikacja uruchomiona na desktopie
- Niezrozumiała nawigacja
- Feature'y które nikogo nie interesowały`
Spędziłem dwa tygodnie budując automatyczną kontrolę wentylatorów. Kod był piękny. Drag-and-drop krzywe. Live preview.
Potem spróbowałem tego naprawdę.
Jedna zła krzywa = potencjalnie spalony GPU.
Wymazałem wszystko.
Zbudowanych i zabitych feature'ów: 29
Lekcja: Fakt że MOŻESZ coś zrobić wcale nie oznacza że POWINIENEŚ
Moment o trzeciej nad ranem
Wyobraź sobie scenę:
- Godzina: 3 nad ranem
- Temperatura laptopa: 94°C
- Wentylatory: wrzeszczą
- Ja: właśnie wróciłem z 10-godzinnej zmiany w magazynie
- Git log: 20+ commitów z napisami "fix" i "może tym razem będzie dobrze"
I zapytałem siebie: co ja w ogóle buduję?
Chciałem zrobić narzędzie dla ludzi którzy chcą zrozumieć swój komputer.
Ale kodowałem jak ktoś, kto chce udowodnić sobie że potrafi kodować.
Te dwie rzeczy to nie to samo.
Tamtej nocy wymazałem interfejs. Znowu.
Rebuild #3: Pytanie we właściwą stronę
Zamiast: "jakie kolejne feature'y mogę dodać?"
Zapytałem: "Co użytkownik NAPRAWDĘ musi widzieć?"
`
Odpowiedź była śmiesznie prosta:
┌─────────────────────────────────────┐
│ CPU [████████░░] 78% RAM [██████░░] 62% │ - Obok siebie. Bez scrollowania.
├─────────────────────────────────────┤
│ PROCESY NA TOPIE: │
│ ▓▓▓ chrome.exe 43% - Najciemniejszy = największy konsument
│ ▓▓ discord.exe 22% │
│ ▓ windows_update 12% - Natychmiastowa hierarchia
│ ░ vscode.exe 8% │
└─────────────────────────────────────┘
Klikasz na proces → dostajesz szczegóły od razu`
Podczas refactoringu usunąłem 15 000 linii kodu.
Z 39 000 do 24 000.
Produkt stał się LEPSZY odkąd usuwałem kod.
A potem przyszedł 22 grudnia
Trzy dni przed Bożym Narodzeniem.
Agencja: "Okres próbny się nie powiódł."
Ja: W tymczasowym mieszkaniu. Psy w Polsce. Laptop umierający. Projekt 70% gotowy.
Logiczna rzecz: panika. Szukaj pracy. Porzuć projekt.
To co zrobiłem: zacząłem rebuild #4.
Co to właściwie znaczy - 680 godzin
Bądźmy szczerzy:
Godzin kodowania: 680+ (po zmianach w magazynie)
Linii napisanych: 39 000
Linii które przetrwały: 24 000
Kompletnych rebuild'ów interfejsu: 4
Feature'ów które zabiłem: 29
Prób do monitorowania GPU: 6 (5 się nie udało)
Kubków kawy: 340+
Maksymalna temperatura laptopa: 94°C (jakoś przeżył)
Stack techniczny (dla zainteresowanych)
Core: Python 3.11+
UI: Tkinter + CustomTkinter
Dane systemu: psutil, GPUtil, WMI
Architektura: Event-driven, modularny
Zużycie RAM: ~30MB (optymalizowane dla starego sprzętu)
Dlaczego Tkinter?
Bo 30MB RAM **to coś zupełnie innego niż **300MB giganta Electrona. I działa świetnie nawet na sprzęcie sprzed dekady.
Co właściwie się nauczyłem
Motywacja jest bezużyteczna.
Zniknęła w tygodniu drugom. Upór został.
"Działający kod" to pułapka.
Moja pierwsza wersja działała prawie idealnie. Była do kitu.
Usuwaj więcej.
Serio. Usunąłem 40% kodu a produkt się poprawił.
Ograniczenia to twoje największe zasoby.
Umierający hardware = zero bloatu. Każdy feature musiał zarobić miejsce na dysku.
Pokazuj się kiedy jest nudnie.
To jedyna różnica między shipped a abandoned.
Status teraz
Shipping za kilka tygodni. Nie bo jestem szybki
bo nie poddałem się.
`
Feature'y które przetrwały:
- Real-time monitoring z rzeczywistym breakdown'em procesów
- Time travel debugging (zobacz co działało 3 godziny temu)
- Custom fan curves z walidacją bezpieczeństwa
- AI-asystent do diagnostyki
- 30MB RAM ` _Jeśli budujesz coś solo i czujesz że posuwasz się do przodu zbyt powoli, to nie porażka. _ ## To po prostu programowanie. Currently at 70%. Resztę historii dokumentuję na LinkedIn **i **GitHub. - ## A Ty? Jaka jest Twoja historia "Przebudowałem to milion razy"? Daj mi wiadomość w komentarzach. Na pewno się odniosę! - Originally published in English on DEV Community https://dev.to/huckler/i-built-in-public-for-5-months-nobody-watched-22nd-dec-i-got-fired-1k6m
Top comments (0)