TL;DR Jak stworzyć coś swojego, gdy codziennie odpalamy dayjob.exe

Przez ostatnie pół roku łączyłem pracę na kontrakcie z tworzeniem własnych projektów. Pomimo spędzanych przeciętnie 8 godzin dziennie w pracy, udało mi się dowieźć cztery projekty:

  • Blog, który właśnie czytasz
  • Via Negativa - aplikacja iOS, manager rzeczy których należy unikać
  • Combat Sports Jobs🥋 - strona z ogłoszeniami o pracę w sportach walki
  • Rearview - aplikacja chroniąca przed niechcianymi spojrzeniami w monitor - pierwszy pozytywnie zwalidowany projekt

Przez najbliższe pół roku zamierzam pracować zawodowo jedynie 3 dni w tygodniu, więc myślę, że teraz jest najlepszy czas na podsumowanie i zanotowanie kilku wniosków. Trzeba zaznaczyć, że zarówno moje projekty poboczne jak i aktywność zawodowa to głównie programowanie. Być może poniższe wnioski byłyby zupełnie inne dla pracy o innym charakterze.

Znajdź optymalną ilość czasu, którą możesz poświęcić miesięcznie

Brzmi banalnie, ale najważniejsze jest znalezienie czasu na własne projekty. Pracując średnio 160 godzin zawodowo mamy tak naprawdę niewiele czasu, który można na nie przeznaczyć. Do pracy zawodowej dochodzi czas na sen, rodzinę, znajomych, sport i inne zainteresowania. Projekty poboczne nie powinny negatywnie wpływać na pozostałe sfery życia. Jasne, można zamknąć się w piwnicy, mieć miesięczny crunch time i programować 12 godzin dziennie, ale jak długo tak wytrzymasz?

Dla mnie ilością optymalną było 20 godzin miesięcznie. Przy większej ilości byłem mocno zmęczony i nie ogarniałem pozostałych sfer życia, przy mniejszej dowoziłem za mało.

Ustal tygodniową rutynę

Bez ustalenia konkretnych godzin w każdym tygodniu dowiezienie czegokolwiek jest bardzo ciężkie. Z moich obserwacji wynik, że pracowanie z doskoku i w przerwach się nie sprawdza. Dlatego tak ważne jest zaplanowanie konkretnych godzin w których pracujemy nad własnym projektem.

W moim przypadku najlepiej sprawdziło się rozłożenie 20 godzin miesięcznie spędzanych nad własnymi projektami na pracę od poniedziałku do piątku pół godziny dziennie oraz 2,5 godziny w weekendy.

Wybierz poranki, wieczory lub weekendy

Zakładając, że w ciągu dnia pracujesz dla kogoś innego, na własne projekty zostają poranki, wieczory i weekendy. Najlepiej wybrać jedna z tych opcji, w zależności od własnego chronotypu i stylu życia.

W moim przypadku najlepiej sprawdzało się wstawanie wcześnie rano i praca nad własnymi projektami zanim odpalałem dayjob.exe. Jeśli nie mogłem programować w domu (remont budynku), wyjeżdżałem 45 minut wcześniej i przed pracą zawodową wchodziłem na pół godziny do kawiarni posiedzieć przed laptopem. W sobotnie poranki wstawałem tak jak zwykle i pracowałem nieco więcej - 2-4 godziny. 6.00-7.00 rano to był najlepszy czas dla mnie - nic się wtedy nie dzieje, nikt nie przeszkadza, umysł jest wypoczęty.

Unikaj więcej niż jednej zmiany kontekstu dziennie

System polegający na pracy nad własnym projektem rano, potem pracy zawodowej, a później powrocie do własnego projektu wieczorem się nie sprawdza. Brzmi fajnie, ale kończy się tym, że około 14.00 zaczynamy myśleć co i jak trzeba zrobić we własnym projekcie. Z kolei pracując wieczorem nad własnym projektem mamy głowę zawaloną myślami o pracy zawodowej. Trzeba to wyraźnie rozgraniczyć. Najlepiej zarezerwować sobie maksymalnie jeden przedział czasowy dziennie na pracę nad swoim projektem pobocznym.

Połóż nacisk na pracę głęboką

Praca głęboka to termin stworzony przez Cal’a Newporta. Polega ona na pracy umysłowej przy pełnym skupieniu na tylko jednej rzeczy. W trakcie pracy nad własnymi projektami usuń wszystkie rozpraszacze - pozamykaj karty w przeglądarce, zapomnij o sieciach społecznościowych, wyłącz Slack’a, nie odpalaj Youtube’a, nie odpisuj na e-maile i schowaj telefon do torby. Mamy i tak bardzo mało czasu, więc po co go marnować na głupoty?

Zrezygnuj z czegoś

Czas jest zasobem skończonym - żeby pracować nad własnymi projektami po godzinach, prawdopodobnie trzeba będzie z czegoś zrezygnować. Netflix, sieci społecznościowe, przeorganizowanie godzin pracy zawodowej i dojazdów, piwo ze znajomymi. Określ aktywności które możesz ograniczyć i poświęć je na projekty poboczne. Może brzmi to trochę brutalnie, ale nie można mieć wszystkiego.

W moim przypadku praca bardzo wcześnie rano od poniedziałku do soboty wymusiła dość duże zmiany w stylu życia. Zacząłem podchodzić poważniej do rutyny snu (względnie stałe godziny zasypiania i stałe godziny pobudki). Zrezygnowałem całkowicie z picia alkoholu w tygodniu oraz w piątki wieczorem, żeby móc w sobotę rano popracować. Z tego powodu ucierpiało nieco moje życie towarzysko-społeczne. Coś za coś, niestety.

Nie zapomnij o odpoczynku

Odpoczynek jest ważny. Zapominając o nim zaciągamy dług, który przyjdzie kiedyś zapłacić. Chyba każdy kto programował kiedykolwiek po 10-12 godzin dziennie wie o tym i tego doświadczył. Obok czasu na relaks ogromne znaczenie ma czysta dieta, sport i dobrej jakości sen. Sorry, ale stereotyp programisty jedzącego pizzę, pijącego colę i zarywającego nocki przed kompem to jakiś absurd. Próbowałem, nie działa.😉

Znajdź czas na jakąkolwiek aktywność fizyczną, wysypiaj się, wywal z diety cukry proste, ogranicz spożycie kofeiny i alkoholu wieczorem. W trakcie urlopu zapomnij o pracy i poleż nad jeziorem, w święta spędź czas z rodziną lub przyjaciółmi, ubierz choinkę i upiecz głupie ciasto zamiast siedzieć przed monitorem w piwnicy.😉

Czy warto?

Sporo wyrzeczeń. Czy warto w ogóle robić projekty poboczne? Przecież spędzając ten czas nad dodatkowymi zleceniami, albo trzaskając nadgodziny prawdopodobnie zarobilibyśmy więcej.

Po pierwsze, robimy rzeczy inne niż te z którymi spotykamy się w codziennej pracy. Mamy ekspozycję na nowe problemy, nowe API, czasem całkowicie nowe technologie. Rozwijamy się. Powiększamy swoje portfolio. Myślę, że z punktu widzenia zawodowego w długim terminie jest to bardzo wartościowe. Specjalizacja jest dla insektów.

Po drugie, własne projekty dają mnóstwo frajdy, ponieważ pracuje się samemu. Brak specyfikacji od klientów. Brak konieczności pisania dokumentacji. Brak czekania na odpowiedź od designera. Brak pull requestów i code review (no chyba, że robione samemu sobie 🙂). Brak konieczności odpowiadania na komentarze w JIRA. Brak codziennych standupów, cotygodniowych godzinnych retrospektyw, planowania sprintu w dziesięcioosobowych zespołach. Zamiast tego projektowanie na pogniecionych kartkach papieru i radosne kodzenie - w kawiarni, na kanapie czy w piwnicy.

Gdyby moje projekty poboczne zamieniły się w “poważny biznes” i potrzebni byliby nowi deweloperzy, testerzy, analityk biznesowy, project manager, scrum master i fancy biuro z piłkarzykami to bym się z tego wszystkiego zwyczajnie wypisał. 😉