No More Forever Projects

Nigdy więcej „forever projects”

Po prawie 20 latach pracy jako developer — od surowego PHP po nowoczesne full stackowe rozwiązania — wpadłem w znajomą pułapkę: projekt na zawsze.
Za każdym razem, gdy uruchamiałem coś po godzinach, obudowywałem to wielkimi obietnicami. „To narzędzie będzie aktywnie rozwijane.” „Ten blog to długoterminowy projekt.” „Ten framework może kiedyś stanie się produktem.”

Wierzyłem, że zaangażowanie nada projektom wiarygodność — że jeśli nie obiecam ich trwałości, nie będą warte zachodu. To miało dawać im ciężar, przyciągać uwagę, użytkowników, może nawet sukces.

Ale im więcej obietnic składałem, że coś będę utrzymywać „na zawsze”, tym bardziej czułem się uwięziony. Utrzymanie stawało się obowiązkiem. Aktualizacje zależności zamieniały się w wyrzuty sumienia. A pasja, od której się wszystko zaczęło, ginęła pod ciężarem dalszego rozwoju.

Pułapka obowiązku

Zacząłem zadawać sobie pytanie: Dlaczego czuję potrzebę składania takich obietnic?
I niewygodna prawda była taka: nie ufałem sobie, że wytrwam, jeśli nie narzucę sobie presji. Jeśli publicznie nie zadeklaruję, że coś dokończę, bałem się, że po prostu odpuszczę.

Ale doświadczenie nauczyło mnie jednego: obowiązek się nie skaluje. Poczucie winy nie daje energii.
Żadnego z moich pobocznych projektów nie uratowała wielka obietnica. A kod, z którego jestem najbardziej dumny? Pochodzi z eksperymentów — nie z „do końca życia rozwijanych” inicjatyw.

Te wszystkie stare repozytoria, które teraz kurzą się w GitHubie? To nie porażki. One po prostu się skończyły — tylko nie tak, jak sobie to wyobrażałem. Tyle że nigdy nie dałem sobie przyzwolenia, żeby uznać je za ukończone. Więc tylko nosiłem ten ciężar dalej.

Od „na zawsze” do „skończone”

Pewien znajomy developer powiedział mi kiedyś:

„Koniec z projektami na zawsze. Rób rzeczy jako eksperymenty. Wypuść, udokumentuj i pozwól im odejść.”

To jedno zdanie totalnie zmieniło moje podejście. Teraz, gdy zaczynam projekt, traktuję go jak sprint: mały, konkretny, z jasnym końcem. Piszę dokumentację, ładnie domykam całość i idę dalej.

Jeśli komuś się spodoba i będzie potrzeba więcej? Mogę wrócić. Ale to mój wybór, nie obowiązek.

I co ciekawe — to właśnie te jednorazowe rzeczy najczęściej zostają na dłużej.
Ktoś je forkuje. Ktoś używa. A czasem sam do nich wracam, żeby coś rozwinąć. Ale robię to na własnych warunkach.

Rezygnując z trwałości, znalazłem więcej regularności, mniej presji i — co zabawne — większą trwałość w tym, co tworzę.

Udostępnij:
Michał Tajchert
Michał Tajchert

Urodzony w Polsce, Michal ma ponad 18 lat doświadczenia jako inżynier oprogramowania. Specjalizując się w cyberbezpieczeństwie, Michal stał się ekspertem w tworzeniu systemów internetowych spełniających standardy bezpieczeństwa na poziomie bankowym. Budował platformy dla firm z sektora usług finansowych, sieci szpitali oraz przedsiębiorstw zajmujących się prywatnymi odrzutowcami.

Articles: 38

Leave a Reply

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *