Co programiście daje praca nad własnymi projektami po godzinach? Devdebata

– Jeżeli ktoś marzy o naprawdę dużych osiągnięciach w karierze IT, taka praca po godzinach jest po prostu niezbędna – powiedział nam Radek Madecki, jeden z uczestników devdebaty. Zaprosiliśmy developerów z wieloletnim doświadczeniem, by opowiedzieli nam, dlaczego mimo wysokich stanowisk w firmach, w których pracują, nadal czas wolny poświęcają na własne projekty.

W devdebacie udział wzięli:

• Radosław Madecki. Software architect w R&D w Clearcode. Swoją pasję do z IT odkrył w czasach wczesnoszkolnych. Pierwsze kroki w zawodzie stawiał jeszcze w gimnazjum, pisząc do internetowych redakcji związanych z jego hobby. Dziś specjalizuje się we frontendzie. Dzieli się także swoją wiedzą, tworząc serię kursów wideo dla wydawnictwa Helion. Jego hobby to sport, nauka oraz dietetyka.
• Paweł Ochota. Lead Frontend Developer w Startup Development House. Zarażony miłością do IT już od czasów szkoły podstawowej. Postawił wszystko na JavaScript i ta decyzja okazała się strzałem w dziesiątkę. Od dłuższego czasu zwolennik pracy w 100% zdalnej, który nie wypuszcza spod swojej ręki byle jakiego kodu. Pasjonat nowoczesnych technologii i gadżetów, śledzący najnowsze trendy w programowaniu i podejściu do architektury. Zanurzony jedną nogą w świecie IT, drugą stojący pewnie w świecie rzeczywistym i spoglądający zawsze optymistycznie przed siebie.
• Mateusz Kubuszok. Senior Scala Developer w SwissBorg. Pasjonat Scali, szczególnie zainteresowany programowaniem funkcyjnym, nauką i dzieleniem się wiedzą. Udziela się na blogu kubuszok.com, podczas wystąpień, ale i na GitHubie. Od blisko pięciu i pół roku pracuje na kontrakcie dla firm z siedzibami m.in. w Niemczech, Szwajcarii czy w Stanach Zjednoczonych.

1. Czym kierujesz się, tworząc projekt po godzinach? Co w ten sposób chcesz osiągnąć?

Radosław Madecki, Software architect w R&D w Clearcode:

Uważam, że jeżeli ktoś marzy o naprawdę dużych osiągnięciach w karierze IT, taka praca po godzinach jest po prostu niezbędna. W branży jest bardzo dużo mądrych i inteligentnych osób. Nie sposób konkurować z nimi “robiąc swoje” przez 8 godzin na etacie. Oczywiście jako, że praca jest moją pasją, a wspomniane marzenia towarzyszą mi od dziecka, to wszystko sprawia mi mnóstwo frajdy i rekompensuje okresowe przemęczenie.

Paweł Ochota, Lead Frontend Developer w Startup Development House:

Tworzenie projektów po godzinach to dla mnie doskonała okazja, aby nauczyć się nowej technologii, lub też doszlifować coś, co poznałem jedynie w podstawowym stopniu. Zazwyczaj jest tak, że w komercyjnej działalności tworzymy rzeczy, które mają pomóc w biznesie klientowi i rzadko jest to coś, co powoduje u mnie opad szczęki. Projekt po godzinach jest więc dla mnie odskocznią od takiej standardowej, programistycznej rutyny i pozwala pobawić się czymś, co być może nigdy nie mógłbym wykorzystać w normalnej pracy.

Mateusz Kubuszok, Senior Scala Developer w SwissBorg:

Dla mnie to głównie rozrywka intelektualna. Możliwość wyszalenia się w technologiach, których prawdopodobnie mógłbym szybko nie użyć w pracy. No i dodatkowo poczucie bezkarności i braku stresu – moje decyzje nie wpłyną na nikogo więc mogę testować różne rozwiązania, których jako odpowiedzialny człowiek nie mógłbym zaproponować w pracy jako zbyt niepewne. Daje mi to pewną przewagę na rynku, ale nie jest to moją motywacją. Wydaje mi się, że wymaganie wprost od ludzi, aby mieli pasję do swojej pracy, często i regularnie poświęcali jej czas po godzinach jest niemoralne. Jeśli side project cię to bawi, rób to dla przyjemności. Jeśli nie, to nie zamęczaj się bo to tylko grozi wypaleniem.

2. Opowiedz o projekcie po godzinach, nad którym teraz pracujesz. W jakiej technologii powstał, dlaczego?

Radosław Madecki, Software architect w R&D w Clearcode::

Obecnie realizuję projekt inkubatora IT z dwoma moimi uczniami. Bardzo mocno angażuję się w wiele inicjatyw naraz i doskwiera mi brak narzędzia w stylu Jiry, ale z przyjemniejszym interfacem, ukierunkowanego na jednostkę, a nie zespół oraz z mechanizmami, które w “inteligentny” sposób mogą podpowiadać jak poprawić swoją produktywność. Chłopaków uczę frontendu przy zachowaniu wszelkich metodologii, które stosuje się w profesjonalnych firmach, dzięki czemu mają możliwość zdobycia prawdziwego doświadczenia zawodowego. Ćwiczę zarządzanie, pisanie backendu, a od stycznia również ML pod wspomnianą funkcjonalność podpowiedzi.

Paweł Ochota, Lead Frontend Developer w Startup Development House:

W tej chwili nie mam żadnego konkretnego projektu po godzinach, któremu musiałbym poświęcić więcej niż kilka dni. Staram się znaleźć odpowiedni balans pomiędzy pasją, a życiem rodzinnym i w ostatnim czasie raczej tworzę dużo mniejsze projekty, aniżeli jeden większy. Daje mi to możliwość szybkiego zapoznania się np. z nowymi funkcjami języka i późniejszego wykorzystania ich już w komercyjnym zastosowaniu, właśnie dzięki próbowaniu. W ten sposób niedawno poznałem nową, bardzo ciekawą właściwość w CSS tj. content-visibility.

Mateusz Kubuszok, Senior Scala Developer w SwissBorg:

Obecnie mam kilka projektów, nad którymi pracuję. Jeden to kopia Reddita, w którym mógłbym na przykładzie pokazać ludziom zainteresowanym technologiami w jakich pracuję (Scala), jak można by zaimplementować skalowalny serwis z event sourcingiem, podziałem na read i write modele, CQRS, wykorzystanie typów i programowanie funkcyjnego do modelowania domeny. Dzięki temu mógłbym na przykładzie pokazywać jak są przykładowe rozwiązania i jak sprawdzają się one dla nieco większego projektu.

Dodatkowo wspólnie z kolegą utrzymuję bibliotekę do automatycznego generowania transformacji (z głębokim kopiowaniem) z jednego typu danych na inny w czasie kompilacji (Chimney). Pomysł zrodził się, kiedy potrzebowałem osobnych – ale bardzo podobnych! – reprezentacji do modeli wewnątrz domeny, modeli używanych przez API oraz modeli używanych do persystencji. Stworzyliśmy więc bibliotekę, która pozwala opisać jedynie pewne różnice między nimi (dodane pole, zmiana nazwy, zmiana typu jednego pola) oraz wygenerowanie transformacji przepisującej wartości jednego typu na inny z uwzględnieniem tych różnic.

Poza tym próbuję znaleźć czas na poprawki do wydanej niedawno na Leanpubie książki. Zaczynała ona jako blogpost, ale po przekroczeniu 100 stron A4 przyjaciele poradzili mi pójście w stronę ebooka.

3. Jakiego rodzaju wsparcia potrzebowałbyś, by projekt przerodził się w coś więcej? Wsparcie miałoby przyjść od pracodawcy czy od społeczności?

Radosław Madecki, Software architect w R&D w Clearcode::

Za jakieś pół roku planujemy zrobić z tego projektu open source i rozwijać go dalej w takiej formie. W innym wypadku zabraknie rąk do pracy, a niekoniecznie chciałbym robić z tego biznes. Zdecydowanie to jeszcze nie pora dla mnie na odłożenie kodu na bok, a tak to prawdopodobnie by się skończyło, gdybym musiał z zarządzania tym projektem zrobić etat.

Paweł Ochota, Lead Frontend Developer w Startup Development House:

Obie opcje są bardzo motywujące, ale też niosą za sobą pewne obowiązki. Wsparcie pracodawcy na pewno jest dodatkowym motywatorem, ale trzeba pamiętać, że może on narzucić nam pewne dodatkowe funkcjonalności, które chciałby wykorzystać później na własne potrzeby. Wsparcie społeczności natomiast obarcza nas trochę presją, aby nasz projekt miał zawsze najnowsze zależności, aby poprawianie błędów odbywało się w miarę szybko etc. Jest to więc kwestia indywidualna, ale moim zdaniem najważniejszy jest pomysł i plan w jaki sposób chcemy uzyskać na tym projekcie profit. Wsparcie zewnętrznych podmiotów niekoniecznie jest wymagane.

Mateusz Kubuszok, Senior Scala Developer w SwissBorg:

Dużym motywatorem jest odzew społeczności. Ludzie dający znać, że wykorzystali bibliotekę w projekcie, proponujący nowe funkcjonalności albo wspominający o nim w tweetach i blog postach, pokazują że problem, który rozwiązujemy jest czymś więcej niż tylko naszą fanaberią. Docelowo takie projekty mogłyby zyskiwać również społeczność, która wspierałaby rozwój oraz rozreklamowywałaby projekt.

4. Co jest lepsze dla programisty: projekt wewnętrzny, firmowy, robione w „wolnym czasie” w pracy, czy projekt własny, robiony po godzinach?

Radosław Madecki, Software architect w R&D w Clearcode::

Każdy z nich daje zupełnie inne możliwości, uczy czegoś innego, jak i również ma swoje wady. Projekty wewnętrzne mogą być przeróżnego rodzaju, ale zawsze będą obarczone tym, że wybór technologii ma być praktyczny, opłacalny – nawet w pet projektach warto żebyśmy uczyli się czegoś, co przyniesie kiedyś ewentualną korzyść organizacji. Mamy tutaj jednak dostęp do wielu specjalistów, udogodnień, procesów usprawniających pracę, więc wszystko idzie szybciej. Projekt na boku uczy samodzielności, odpowiadamy za wszystko i możemy “eksperymentować”. Oczywiście to z kolei wiąże się z koniecznością popełnienia większej ilości błędów, poleganiu na sobie lub małej grupce znajomych.

Paweł Ochota, Lead Frontend Developer w Startup Development House:

Moim zdaniem główną różnicą jest cel tych projektów. Własny projekt daje nam całkowitą kontrolę nad tym, co chcemy zrobić. Projekt dla organizacji może przyjąć ramy normalnego projektu, możemy dostać do pomocy pracowników i każdy wniesie swoje idee itp. Na pewno żadna z opcji nie jest czasem zmarnowanym, bo coś osiągniemy, czymś będziemy mogli się pochwalić i zdobędziemy nową wiedzę. Myślę, że to również kwestia indywidualna, bo część z nas pewnie potrzebuje motywatora w postaci narzuconego zespołu, a część jest w stanie kontrolować to samodzielnie.

Mateusz Kubuszok, Senior Scala Developer w SwissBorg:

To zależy w czym chcemy się rozwijać. Własne projekty pozwalają nam na eksplorację i podejmowanie ryzykownych decyzji. Jeśli będą złe, my wyciągniemy z nich lekcje, ale nikt nie ucierpi. W projektach firmowych są jednak pewne cele do zrealizowania oraz odpowiada się przed kimś, nawet jeśli projekt jest na boku albo OSS.

Przy firmowych projektach OSS, utrzymywanie projektu staje się dodatkową odpowiedzialnością ponieważ taki projekt jest wizytówką firmy. Musi on też realizować cele firmy a jednocześnie wspierać przypadki użycia potencjalnej społeczności, co wymusza tworzenie ogólniejszych i lepiej przemyślanych rozwiązań. Może to być bardziej uciążliwe ale jednocześnie opieka firmy pomaga uzyskać rozgłos.

5. Czego nauczyłeś się, tworząc swój pierwszy projekt po godzinach? Czego dzisiaj uczą Cię te nowe projekty?

Radosław Madecki, Software architect w R&D w Clearcode::

Mój pierwszy projekt po godzinach, który zacząłem parę lat temu, tak naprawdę był protoplastą wspomnianego wyżej. Założenia były takie same, ale wtedy wszystko chciałem zrobić sam, pisałem go w Angularze 2. Nauczyło mnie to tego, że nie zrobię sam designów, nie zrobię sam user story mapy, nie zaprogramuje sam frontu i backendu, a tym bardziej nie zrobię tego wszystkiego w rozsądnym czasie. Chyba przede wszystkim pozwolił mi zrozumieć jak długa jeszcze droga przede mną była (zresztą nadal jest) by zdobyć ekspertyzę we wszystkich interesujących mnie dziedzinach branży IT. Wszystko wydaje się proste, patrząc z boku – dopiero biorąc sprawy we własne ręce, jesteśmy w stanie zrozumieć złożoność pewnych spraw.

Paweł Ochota, Lead Frontend Developer w Startup Development House:

Szczerze powiedziawszy nie pamiętam dokładnie, który projekt był tym pierwszym. W czasach gimnazjalnych poznawałem HTMLa i wraz z przyjaciółmi tworzyliśmy proste menu dla płyt CD. Potem przyszedł czas na własną stronę i w ten sposób rozpoczęła się moja przygoda z technologiami webowymi. Na studiach po godzinach poznawałem takie rzeczy jak np. tworzenie hybrydowych aplikacji dla urządzeń mobilnych. Pamiętam konkurs BlackBerry, na który wykonałem taką aplikację i w nagrodę otrzymałem swój pierwszy tablet oraz smartfona.

Czegokolwiek nie robiłem, czymkolwiek się nie bawiłem, to nigdy nie był to czas stracony. Albo otrzymywałem w ten sposób jakiś konkretny profit, albo np. przykuwałem uwagę firm, które chciały abym dla nich pracował. Jeżeli więc jeszcze ktoś zastanawia się czy warto, to odpowiadam: zdecydowanie!

Mateusz Kubuszok, Senior Scala Developer w SwissBorg:

Ciężko mi powiedzieć, co było pierwszym projektem po godzinach, bo tworzyłem projekty dla siebie zanim zacząłem pracę i zatrudnienie nie wpłynęło przez długi czas na to jak je zaczynam, rozwijam i kończę. Dopóki odczuwam sens pracy i satysfakcję kontynuuję pracę, kiedy przestaję odstawiam projekt na półkę. Pamiętam jednak lekcje jakie wyciągnąłem z, może nie pierwszego, ale kilku pierwszych projektów.

Wszystko zajmuje więcej czasu niż się spodziewasz. Zawsze jest coś do poprawki i jeśli nie powiesz dość, w końcu przestaniesz posuwać się do przodu. Solidne zrealizowanie czegokolwiek może zabrać miesiące więc dobrze zaplanować tak pracę żeby jak najszybciej móc widzieć wyniki – inaczej można się zniechęcić. Twój projekt obchodzi przede wszystkim ciebie, nie spodziewaj się oklasków/wdzięczności/zainteresowania i nie szukaj takiej motywacji.

We wszystkich projektach jest jedna rzecz wspólna: dają one możliwość podejmowania niepopularnych, nieprzetestowanych i ryzykownych decyzji. W trakcie ich rozwijania masz możliwość wyciągania wniosków i zdobywania wiedzy o bleeding edge rozwiązaniach w sposób, który pozwoli nam sugerować lepsze rozwiązania w przyszłości, ale bez zmuszania naszych współpracowników do płacenia za nasze eksperymenty.

Zdjęcie główne artykułu pochodzi z unsplash.com.

Oferty pracy z