O pet projects, ambicjach programisty i rzeczywistości

O pet projects

Temat dotyczący pet projects na polskich blogach technicznych był już poruszany, ale z pewnością nie został wyczerpany mogę dodać coś od siebie. Prawie rok temu Maciej Aniserowicz pisał o tym dlaczego warto robić coś po pracy i zachęcał do działania. Komentarze pod wpisem pokazują, że wielu programistów realizuje, lub podejmuje próbę zrealizowania czegoś poza pracą – to cieszy! W tym miejscu warto wspomnieć o nowym, ciekawym przedsięwzięciu Daj się poznać, które ma na celu zmotywować programistów do działania. Sam chętnie wziąłbym udział, ale wiem, że blogowanie z taką częstotliwością mnie przerośnie, dlatego życzę powodzenia wszystkim uczestnikom. Niech kod będzie z Wami! Jeżeli ktoś z Was chciałby wziąć udział, ale nie ma pomysłu na projekt to odsyłam na blog Pawła Tymura, który w nawiązaniu do wspomnianego konkursu opublikował kilka naprawdę ciekawych propozycji.

O ambicjach programisty

Sam niejednokrotnie podejmowałem próby stworzenia jakiegoś “rewolucyjnego” projektu. Impulsy do działania napływały różnymi kanałami, ale najczęściej pojawiał się jeden z poniższych bodźców:

  1. Zobaczyłem jakąś nową, zajebistą bibliotekę, którą chciałem przetestować bo wydawała się być panaceum na całe zło obecne w świecie programistów,
  2. W sieci pojawiły się informacje na temat nowej technologii, która zrewolucjonizuje rynek wymiatając wszystkie pozostałe i zostawiając mnie bez pracy,
  3. Codzienność podsuwała do głowy kolejne pomysły na ułatwienie życia sobie i/lub innym.

W początkowej fazie każdego pomysłu kierowały mną emocje i byłem tak podjarany tematem, że nie umiałem się doczekać kiedy w końcu będę mógł zacząć działać. Gdy już nadeszła ta upragniona chwila i ruszyłem z miejsca to w zasadzie od razu uruchamiała się cicha zabójczyni całego przedsięwzięcia – ambicja.

Ambicja ujawniała się na różnych etapach i w różny sposób, ale z perspektywy czasu zauważyłem pewien schemat. Przecież nazwa projektu musi powalać na kolana. Mam tyle pomysłów na ficzery… Nie może być tak, że wybiorę tylko najważniejsze i mój projekt będzie niekompletny! Przecież muszę się nauczyć samych nowych rzeczy, byłoby smutno gdybym skorzystał z czegoś co już znam. W projekcie w pracy kod nie jest idealny, ale w moim pet project musi błyszczeć, obowiązkowo być pokryty testami w 100%, po prostu musi być idealny. Przecież nie mogę opublikować na githubie pod własnym nazwiskiem czegoś , co posiada wady. Co by community pomyślało? Taki wstyd!

Oczywiście przekolorowałem trochę ten obraz, ale niech pierwszy rzuci kamieniem ten, kto próbował już zrealizować jakiś swój projekt i nie wie o czym piszę.

O rzeczywistości

Podczas mojej kilkuletniej kariery pojawiło się mnóstwo pomysłów, które w większości skończyły jako nieskończony draft w onenote lub praktycznie pusta solucja w lokalizacji D:\Projects. Parę projektów doczekało się publikacji na moim githubie a tylko 2 doczekały się publikacji na szerszą skalę. Zbierając do kupy wszystkie moje doświadczenia na przestrzeni czasu udało mi się ustalić z czego wynika taki stan rzeczy. Otóż problem tkwił w tym, że nieumiejętnie podchodziłem do pet projects stawiając sobie za wysokie cele, co z biegiem czasu prowadziło do zniechęcenia i porzucenia całego przedsięwzięcia. Byłem zmanipulowany przez własne ambicje, które jak nowotwór, skutecznie doprowadzały do klęski.

Oczywiście to nie jest tak, że ambicja programisty to zło i jeżeli jej nie posiadamy to automatycznie mamy gwarancję ukończenia jakiegoś przedsięwzięcia. Jak pisałem wyżej – 2 projekty udało mi się rozwinąć na tyle, że mogłem je opublikować na szerszą skalę. Ostatnio zastanawiałem się jak to się stało, że akurat te dwa udało się  zrealizować. Co było innego w porównaniu do całej reszty pomysłów? Otóż inne było to, że podszedłem do całego przedsięwzięcia bardziej zdroworozsądkowo. Zdefiniowałem sobie takie cele, które były możliwe do zrealizowania. Przekalkulowałem ile czasu będę poświęcał na dany projekt i od razu zestawiłem to z moimi wstępnymi założeniami. Takie zestawienie zasugerowało z jakich funkcjonalności warto zrezygnować. Poza tym wprowadziłem tylko jedno-dwa nowe podejścia/biblioteki/technologie. Dzięki temu zredukowałem liczbę rzeczy, których musiałbym się nauczyć i posuwałem projekt do przodu jednocześnie ucząc się czegoś nowego. Kolejnym kluczowym elementem układanki było uświadomienie sobie, że nieważne ile energii włożę w jakość rozwiązania to i tak zawsze znajdzie się coś co można poprawić. W efekcie zmniejszyłem swoje wymagania co do jakości kodu tłumacząc sobie, że to zawsze można poprawić.

Warto uświadomić sobie, że ukończony projekt z niedociągnięciami daje większą satysfakcję i motywację do dalszego działania niż rozgrzebany kawałek idealnego kodu. Z perspektywy czasu mogę powiedzieć, że miło było patrzeć jak rosną statystyki na Google Analytics, czy nuget.org. Był to dla mnie sygnał, że ktoś się zainteresował tym przedsięwzięciem i od razu zapominałem o brakujących funkcjonalnościach, niskim pokryciu kodu, czy rozwiązaniach, które nie do końca mi się podobały. Obecnie realizuję kolejny pet project, w którym korzystam z mojego poprzedniego projektu dowiezionego do końca. Powiem szczerze, że to dodatkowo napędza i dodaje wiary w to, że kolejny projekt również będzie dowieziony do końca.

Podsumowanie

W ramach podsumowania podaję garść zaleceń wyciągniętych z moich prywatnych doświadczeń:

  1. Wyznacz sobie cel, który jesteś w stanie zrealizować.
  2. Wyważaj proporcje pomiędzy tym co chcesz, a tym co jesteś w stanie osiągnąć.
  3. Wybierz tylko te funkcjonalności/założenia, których naprawdę potrzebujesz.
  4. Nie przeginaj z liczbą rzeczy, których będziesz się musiał nauczyć.
  5. Zdefiniuj MVP (Minimal Valuable Project) i trzymaj się tych założeń.
  6. Wyluzuj z jakością, postaw sobie poprzeczkę ciut niżej.

 Działaj, ale nie daj się pokonać ambicji. Działaj, ale rób to z głową! Powodzenia!

Nie przegap kolejnych postów, zapisz się do newslettera!

Zapisując się na listę zgadzasz się na otrzymywanie informacji o nowych wpisach i informacji marketingowych ze strony tymoteuszkestowicz.pl

6 comments on “O pet projects, ambicjach programisty i rzeczywistości
  1. Świetny wpis. Co do opisanych przez Ciebie ambicji odnośnie pet projectu – trafione w 100%. Ile to już razy ambicje sparaliżowały mnie zupełnie, choćby na etapie designu – bo przecież w moim wymarzonym projekcie architektura od razu musi być pomyślana jako dzieło sztuki.

    Ostatnio z chłopakami zrobiliśmy takie MVP – http://stapp.space/cfp-help-my-first-real-mvp-project/ – i to jest strzał w dziesiątkę. MVP to podstawa. Jak zobaczmy, że coś bangla, dostaniemy dalszej motywacji do działania.

    • ‘bo przecież w moim wymarzonym projekcie architektura od razu musi być pomyślana jako dzieło sztuki.
      Trafione w punkt, ugrzęźnięcie na początku w pełnej analizie czy tworzenie elastycznej architektury to gwarantowany paraliż.
      Niestety mam tak że często ambicje górują nad zdrowym rozsądkiem.

  2. Mimo wszystko jakości bym nie odpuszczał w najmniejszym nawet stopniu. Jeśli poniosła nas ambicja warto projekt okroić nawet o te 50%, ale wszystkie założenia jakościowe zachować na niezmienionym poziomie. Co do całej reszty zgadzam się w 100%. Pozdrawiam!

  3. Grunt przed zabraniem się za duży projekt to stworzenie dobrej i rzetelnej dokumentacji – musimy jasno określić cele jakie sobie sobie stawiamy i wszystkie wymagania. Często to zaważy na naszym sukcesie lub porażce. 😉

Say something

Your email address will not be published. Required fields are marked with a grey bar.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">