[{"data":1,"prerenderedAt":86},["ShallowReactive",2],{"blog-post-side-projects-failed-because-i-kept-making-them-better-pl":3},{"id":4,"title":5,"author":6,"body":7,"cover":72,"description":73,"extension":74,"featured":75,"meta":76,"navigation":75,"path":77,"publishedAt":78,"readingTime":79,"seo":80,"stem":81,"tags":82,"__hash__":85},"blogPl\u002Fblog\u002Fpl\u002Fside-projects-failed-because-i-kept-making-them-better.md","Moje projekty poboczne nie powstawały, bo wciąż próbowałem je ulepszać",null,{"type":8,"value":9,"toc":68},"minimark",[10,14,17,20,26,29,34,37,45,50,53,58,61],[11,12,13],"p",{},"Mam tę skłonność — zarówno jako developer, jak i w życiu. Lubię reorganizować, katalogować, restrukturyzować i przesuwać elementy, aż wszystko wydaje się ergonomiczne i uporządkowane. Przez długi czas mówiłem sobie, że to moja mocna strona. Nie zauważałem jednak, że robię porządki, zanim zdążyłem w ogóle narobić bałaganu.",[11,15,16],{},"Żaden system nie jest naprawdę idealny, wolny od błędów i gotowy na każdą przyszłą funkcję. Mój lęk przed długiem technicznym popychał mnie jednak do wielotygodniowego analizowania architektury prostego projektu. Logika wydawała się rozsądna: zbuduj od razu skalowalny fundament, a później oszczędzisz sobie bólu. Nadal wierzę, że struktura ma znaczenie, także w małych i średnich systemach.",[11,18,19],{},"Ale za każdym razem, gdy kończyłem refaktoryzację i zaczynałem implementować nową funkcję, dostrzegałem sposób, w jaki poprzedni projekt można ulepszyć pod konkretny przypadek. Zmieniałem więc klasy bazowe. Potem model bazy danych. I wkrótce prawie każda nowa funkcja była w jakiś sposób „zablokowana” przez kolejną refaktoryzację.",[11,21,22],{},[23,24,25],"strong",{},"W pewnym momencie musiałem przyznać, że coś w moim procesie nie działa.",[11,27,28],{},"Nie narzędzia. Nie język. Nie framework. Sposób, w jaki pracowałem. Optymalizowałem pod kątem poprawności i elegancji zamiast postępu. A to postęp naprawdę ujawnia złe decyzje. Bez niego dyskutowałem jedynie z wyobrażonymi problemami przyszłości.",[11,30,31],{},[23,32,33],{},"Zmieniłem więc zasady, które sobie narzucałem.",[11,35,36],{},"Oddzieliłem czas na refaktoryzację od czasu na dostarczanie. Refaktoryzacja stała się zaplanowanym działaniem. Wszystko inne dotyczyło wdrażania: nowych funkcji, drobnych ulepszeń, naprawiania błędów i zamykania zadań.",[11,38,39,40,44],{},"Stworzyłem plik ",[41,42,43],"code",{},"TECHNICAL_DEBT.md",". Gdy coś wydawało się niewłaściwe lub brzydkie, zapisywałem to zamiast od razu naprawiać. Co boli? Dlaczego boli? Co zmieniłbym, gdybym miał czas? Zaplanowałem w kalendarzu powtarzający się blok czasu na zajęcie się tym.",[11,46,47],{},[23,48,49],{},"To zmieniło wszystko.",[11,51,52],{},"Praca stała się spokojniejsza. Decyzje — lżejsze. Przestałem walczyć z samym sobą podczas pisania kodu. Mogłem iść do przodu, nie udając, że każdy wybór musi być perfekcyjny. Dłużej zajęło mi zrozumienie, dlaczego ten schemat w ogóle powstawał. Znałem teorię. Wszyscy ją znają. Nadmierne komplikowanie projektu na początku jest błędem. Przedwczesna abstrakcja jest niebezpieczna. Należy pozwolić systemowi rosnąć.",[11,54,55],{},[23,56,57],{},"Ale sama wiedza nie wystarczyła.",[11,59,60],{},"Mój perfekcjonizm robił coś bardziej toksycznego. Nie pozwalał mi w ogóle uznać istnienia długu technicznego. Zapisanie czegoś jako „niedoskonałego” wydawało się przyznaniem do porażki. Dowodem na to, że nie jestem dobrym developerem. Brak postępów w projektach prowadził mnie coraz głębiej w tę spiralę.",[11,62,63,64,67],{},"Uczę się teraz, że dobre systemy nie rodzą się czyste. Stają się takie dzięki użyciu. Dzięki błędom. Pod wpływem realnych użytkowników i prawdziwych ograniczeń. Kończenie rzeczy okazało się bardziej satysfakcjonujące niż projektowanie idealnych systemów. A akceptacja długu technicznego okazała się oznaką ",[23,65,66],{},"dojrzałości",", a nie porażki.",{"title":69,"searchDepth":70,"depth":70,"links":71},"",2,[],"\u002Fimages\u002Fblog\u002Fside-projects-launch.avif","O tym, jak perfekcjonizm i przedwczesne refaktoryzacje zatrzymywały moje projekty — oraz o zasadach, które pomogły mi znów dostarczać efekty.","md",true,{},"\u002Fblog\u002Fpl\u002Fside-projects-failed-because-i-kept-making-them-better","2026-02-02","2 min czytania",{"title":5,"description":73},"blog\u002Fpl\u002Fside-projects-failed-because-i-kept-making-them-better",[83,84],"Dług techniczny","Produktywność","YCoVWhq4IZ5ziVqf1CBtj3Vq0QXfezM1tLIxeur3o7w",1787647490108]