side project

POIT #031: Projekty poboczne (side projects)

Witam w trzydziestym pierwszym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy są projekty poboczne czyli side projects.

Dziś moimi gościem jest Łukasz Łażewski, programista, CTO i co-founder kilku startupów. Lider zespołów programistycznych i produktowych. Kojarzony z takimi technologiami jak Ruby on Rails czy Elixir. Występuje przed szerszą publicznością i uczy nowe pokolenia programistów. Prywatnie fan rozwoju, nowych technologii i wycieczek rowerowych.

W tym odcinku o side projects opowiemy w następujących kontekstach:

  • czym są side projects?
  • jakie rady można udzielić osobom poświęcającym swój czas prywatny na pet projects?
  • skąd brać na nie pomysły i inspiracje?
  • czy ich kod powinniśmy pokazywać na GitHub’ie lub blogu?
  • czy powinniśmy martwić się jakością kodu?
  • jaki jest ich wpływ i znaczenie podczas procesu rekrutacji?
  • czym one są dla doświadczonych programistów?
  • kiedy jest dobry czas by zakończyć side project?
  • czy warto do nich zapraszać inne osoby?
  • co się dzieje gdy z side project powstaje firma?
  • dlaczego firmy płacą programistom za spędzanie swojego czasu nad projektami pobocznymi?

🎁 Niespodzianka:

Łukasz przygotował 20% zniżkę na użytkowanie aplikacji do zarządzania tłumaczeniami Yata. Zniżka jest do wykorzystania na stronie: https://run.yatapp.net/discount_code/nx5ne5t6

Subskrypcja podcastu:

Linki:

Pozostańmy w kontakcie:

 

Muzyka użyta w podcaście: „Endless Inspiration” Alex Stoner  (posłuchaj)

Transkrypcja podcastu

To jest 31. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o projektach pobocznych, czyli Side Projects. Przypominam, że w poprzednim odcinku poruszyłem temat SoDA, czyli polskiego związku pracodawców i usług IT. Chcę poszerzać horyzonty ludzi z branży IT i wierzę, że poprzez wywiady takie jak ten, publikowane jako podcasty będę to robił z sukcesem. Wielkie dzięki za wszystkie maile, wiadomości i recenzje podcastów.

Miło, że to, co robię jest wartościowe.

Ja się nazywam Krzysztof Kempiński i życzę Ci miłego słuchania.

Odpalamy!

Krzysztof: Cześć! Mój dzisiejszy gość to programista, CTO, Co-Funder kilku startupów, lider zespołów programistycznych i produktowych. Kojarzony z takimi technologiami jak Ruby on Rails czy Elixir. Występuje przed szerszą publicznością i uczy nowe pokolenia programistów. Prywatnie fan rozwoju, nowych technologii i wycieczek rowerowych. Moim i waszym gościem jest dzisiaj Łukasz Łaszewski.

Cześć Łukasz! Bardzo mi miło, że będziemy mogli dziś porozmawiać i że zgodziłeś się przyjąć zaproszenie do podcastu.

Łukasz: Cześć Krzysztof! Dzięki za zaproszenie.

Krzysztof: Dzisiaj porozmawiamy sobie o fajnym temacie, który bardzo trudno jest przetłumaczyć na język polski. Z angielska nazywa się Side Projects lub Pet Projects. Po polsku chyba najlepiej projekty poboczne. Łukasz ma spore doświadczenie w tym temacie. Ruszamy! Łukasz, ja zawsze na początku zadaję takie pytanie na rozruch: czy słuchasz podcastów? Jeśli tak, to jakich najczęściej?

Łukasz: Tak, zdarza mi się słuchać podcastów. Tak regularniej słucham czterech: Cycling tips , Developerty i z polskich Piotra Buckiego oraz Twój podcast.

Krzysztof: Świetnie. Bardzo fajna lista. Postaram się zalinkować wszystko w notatkach do tego odcinka. Projekty poboczne, czyli z angielska Side Projects, tak jak mówiliśmy. Mało kto wie, ale wywodzą się, ze świata muzycznego, gdzie muzycy rożnych grup nagrywają razem coś, czego nie nagraliby w swojej macierzystej grupie. Innymi słowy, robią coś zupełnie innego niż na co dzień. Czym są Side Projects w świecie programistycznym, Łukasz?

Łukasz: Dla mnie Side Projects są przede wszystkim niezobowiązującym sposobem na poeksperymentowanie z rożnymi technologiami, czy ciekawymi rozwiązaniami w kodzie. Czasem można zobaczyć na własną rękę jak dana dziedzina problemowa może być rozwiązana przy pomocy innego języka programistycznego czy biblioteki, właśnie w celu poeksperymentowania. To na początek. Często zdarza się tak, że wynika to z faktu, że ktoś zauważa pewien brak, pewną potrzebę, którą następnie chcemy wypełnić takim pet projectem, czyli znaleźć rozwiązanie przy pomocy takiego pet projectu. Tutaj już w dalszej części rozmowy przytoczę parę przykładów, ale na szybko powiem Ci, że na przykład Nick Reynolds, który wymyślił projekt OBI, jak zapewne wiesz, w Eliksirze jest coś takiego, co pozwala nam odpalić observera relingowego i zobaczyć procesy oraz co się dzieje z naszymi aplikacjami OTP. Natomiast nie ma łatwego sposobu, aby pokazać to przy pomocy terminala. Nick wymyślił sobie, że wymyśli aplikację, która w terminalu po SSH pokazuje nam dokładnie to samo to observer.

Krzysztof: Czyli coś fajnego może z tego powstać. Wiesz co, muszę Ci się przyznać, że sam miałem coś takiego, że pod wpływem chwili, zapału do zrobienia czegoś nowego, spróbowania nowej technologii podejmowałem się zrobienia czegoś, co później w jakiś sposób mnie zwyczajnie przerastało. Raczej nie mam takiego słomianego zapału, to jednak szybko odpuszczałem, bo czułem, że podjąłem się czegoś za dużego. Jakie miałbyś rady dla osób, które chcą w sowim wolnym czasie chcą zrobić taki projekt poboczny , ale podjąć się go w ten sposób, żeby nie zrazić się zbyt szybko i nie zarzucić po kilku dniach?

Łukasz: Myślę, że kluczowe jest nie stawiać sobie nie wiadomo jakich celów. Owszem, sam znam parę takich osób, gdzie pet project stał się głównym zajęciem. Jednak zdecydowanie jest to wyjątek niż norma. Wydaje mi się, że ludzie czesto zaczynają i nie kończą. Również tak mam, powiem szczerze, że większość czasu tak mam. Natomiast, trzeba się zastanowić jaki jest benefit tego, bo niekoniecznie jest to złe. Mamy limit czasu, nawet każde, nawet najmniejsze doświadczenie czy lekcje z takiego projektu jest wartościowe. Prosty przykład: jako, ze wywodzę się ze świata Java, lata temu, to często zaczynam coś Javy, po to żeby zobaczyć jak to się wszystko pozmieniało. Jak od tej wersji 1.4, której używałem lata temu – jak to teraz wygląda. Tego typu podejście doprowadziło, że eksperymentuję z różnymi językami i dzięki temu właśnie miałem możliwość poznać Elixira i zakochać się w nim, jako języku funkcyjnym. Moim Side Projectem na pewnym etapie, 3 lata temu, było eksperymentowanie z językami funkcyjnymi. Wychodząc z tym bagażem doświadczeń w Javie, przez różne Closury, przez Relanga, ostatecznie kończąc na Eliksirze, dawało mi to kupę frajdy i na koniec wiem, na przykład, jakie są preferencje każdego z tych języków, które można lepiej do czego użyć. Na tej podstawie pozwala mi to poszerzyć moją wiedze i mój toolset tak zwany – zestaw narzędzi, którymi na co dzień można się posłużyć do rozwiązania problemu.

Krzysztof: To bardzo ciekawa i fajna perspektywa, którą teraz przedstawiłeś. Niekoniecznie musimy się skupiać na efekcie tej pracy czy tego projektu, którego chcemy się podjąć, ale sama droga może być istotna i wnosić dużo w nasze umiejętności, wiedzę i skill set. Warto podejmować się rzeczy, których nie ukończymy, chociażby, tak jak powiedziałeś, żeby poznać coś nowego. Może się zainspirujemy czymś nowym. Tak jak powiedziałeś, może nasza kariera zostanie pokierowana w innym kierunku. Zastanawiam się skąd brać pomysły i inspiracje na side projects? Czym się kierować? Coś dużego, coś małego, może rozwiązanie naszego konkretnego case byłoby tutaj dobrym przykładem? Często widzę, że – ja przynajmniej – rzucam się na coś dużego, a mam wrażenie, że lepiej wychodzi to osobom, które mają realny problem w swoim otoczeniu i życiu, i próbują go rozwiązać? Co myślisz? Co jest najlepszą perspektywą? Czym się kierować w wyborze projektów pobocznych?

Łukasz: Zdecydowanie najlepszą motywacją, dla mnie osobiście, jest postawienie sobie konkretnego celu i próba zrealizowania go. Natomiast ten cel musi być realny. Wiedząc, że to będzie tylko kilka godzin w ciągu najbliższych paru miesięcy tu i tam – nie możemy sobie stawiać za cel postawienie i zbudowanie nie wiadomo jakiego rozwiązanie. Cokolwiek by to było – czy projekt biznesowy, czy projekt do przetestowania MWP, czy nawet jakaś biblioteka. Natomiast często jest tak, że rozpoczynając pracę nad czymś – wróćmy do Nicka, które wspominałem wcześniej – jego potrzebą było to, że łącząc się po SSH do zdalnego systemu, można sobie wyjąc tunelem ten zewnętrzy system do swojego laptopa również i odpali Observera lokalnie, tego obecnego, wbudowanego w Relanga, ale dzięki temu rozwiązaniu, które on zaproponował można zrobić to przez terminal. Jest to lżejsze. Jednym z pierwszych problemów, z którym się spotkał było biblioteka ncurses do rysowania w terminalu – nie spełniała wszystkich jego potrzeb. Dlatego powstał projekt Ratatouille w Elixirze, który de facto rozwiązuje ten problem najpierw. Projekt ten potencjalnie rozwija Cię i ma pewne marketingowe dla Ciebie, dla zwiększenia twojej wartości – czy na rynku pracy, czy w oczach innych programistów, ma dość dużą wartość. jeżeli widzisz, że inne osoby też zaczynają się w to angażować, ponieważ ten projekt jest otwarty githubie, gdzie każdy może to przejrzeć, skomentować, otworzyć full requesta z poprawkami czy nowymi ficzerami. To na pewnym etapie zaczyna się to samo nakręcać i taki projekt żyje swoim życiem, bo powstaje jakaś społeczność wokół niego i temat rusza do przodu. Nawet to jest trochę naciąganie, ale zaryzykowałbym stwierdzenie, że niektóre języki programowania powstały jako Side Projecty. Ktoś pracując w danym rozwiązaniu, miał jakiś problem – zarządzania pamięcią czy sieciowy, czy konkurencyjności procesów – nie było rozwiązania odpowiednio i an tej podstawie powstał język dedykowany temu problemowi.

Krzysztof: Pewnie, czyli konkretny problem do rozwiązania. Dla mnie to jest coś takiego, że czujemy większą motywację, żeby dążyć i przechodzić nieraz przez te trudne chwile, które z pewnością nastąpią, jeśli podejmujemy się powiedzmy nowej technologii, nowego języka albo nieraz zupełnie innego aspektu informatyki. Tutaj podawałeś przykłady backendowe powiedzmy, czyli poruszamy się w różnych językach, bibliotekach czy frameworkach backendowych. Można też podejść do tego inaczej – można spróbować zrobić jakiś side project dajmy na to, z frontendu, albo dewopsowy czy coś zupełnie z innej dziedziny. To też myślę, że wnosi dużo do naszego rozwoju jako programisty, bo poszerzamy te horyzonty i lepiej pozwala nam to czym informatyczny czy programowanie, samo w sobie jest. Warto szeroko patrzeć na tę dziedzinę. Te projekty, o których mówimy to dla mnie taka doskonała szansa na naukę. Wiadomo, że robimy wówczas ogrom błędów. Można porównać nas do dzieci, które uczą się chodzić, ale jednocześnie mnóstwo się uczymy. Czy taki kod, który powstaje w wyniku takich zabaw, eksperymentów, jest według Ciebie wart pokazania na zewnątrz – na githbubie na przykład? Czy warto w ogóle wystawiać ten kod na widok publiczny? Dokumentować go, na przykład w formie bloga, co jest ostatnio dość modne? Myślisz, że ma to sens?

Łukasz: Tak, zdecydowanie uważam, ze ma to sens. Po pierwsze mogą powstać z tego fajne materiały edukacyjne dla innych osób, które będą miały podobny problem do zaadresowania. po za tym wydaje mi się, że na pewnym etapie kultura pisania kodu tej osoby staje się wizytówką. Na chwilę wracając do poprzedniego wątku, często jest tak, że pracujesz w backendzie i chcesz się nauczyć czegoś innego, spróbować mobile. Nie zawsze w pracy masz taką możliwość, prawda? Na co dzień pracując dla klienta czy w dużej firmie jesteś przywiązany do tej technologii, której używacie. To jest związane z wieloma czynnikami biznesowymi, nad którymi nie masz kontroli. By się odpowiednio rozwijać samemu i kontrolować sytuację możesz podoświadczać. Dla mnie to jest takie doświadczanie. Udokumentowanie tego doświadczanie na githubie bądź w postaci bloga pozwala pokazać nawet zewnętrznemu rekruterowi – tak jak ja – kiedy technicznie rekrutuję daną osobę i widzę przejaw pasji i zainteresowania, to jest nierzadko dal mnie bardziej wartościowe, niż to, że przychodzi ktoś inny i ma wpisane 3 lata, że robił to w swojej codziennej pracy. Jako programista doskonale rozumiem, że jak złapię bakcyla to ta wiedza wchodzi zupełnie inaczej niż w tych warunkach pracy regulowanej jakimiś godzinami. To jest ten element, dlaczego uważam, że potwornie warto pokazać światu co się robi.

Krzysztof: Tutaj zahaczamy o aspekt jakości kodu, który tworzymy. No właśnie – jak to z tym jest? Jak znaleźć wyważenie czy złoty środek nienabywania złych praktyk, poświęcania zbyt wiele czasu na wchodzenie w detale i czy konkrety? Na te projekty poświęcamy kilka godzin w tygodniu, może w miesiącu nawet – siłą rzeczy bardzo trudno jest nabyć dobre praktyki – zwyczajnie nie mamy na to czasu. Każdy wnosi bagaż doświadczeń i wiadomo jak działa mózg – jeśli raz nauczymy się pewnych wzorców, to staramy się je wszędzie wykorzystywać. Zastanawiam się jakie tutaj jest najlepsze podejście – gdzie znaleźć to wyważenie pomiędzy dobrymi praktykami, a jednocześnie pójście z tym projektem do przodu, czyli osiąganiem rezultatów i wyników mierzalnym do pokazania, po to, aby nas motywowało do dalszej pracy?

Łukasz: To jest świetne pytanie. Nie wiem czy pamiętasz, na przestrzeni lat 2005 i 2011 byłą olbrzymia moda na single page aplications i one wszystkie się wzajemnie do siebie powyrywały przy pomocy takich aplikacji get things done to do list. To stało się dla mnie powtarzalnym sposobem na wykonanie projektu na przykład, przy pomocy innej technologii. Weźmy sobie Chicago Bulls framework webowy, którym się bawiłem. Wybrałem sobie jakaś taką dziedzinę problemową, którą miałem rozwiązana w Relsach czy Javie wcześniej i chciałem zobaczyć jak to będzie postawić restfullowe API przy pomocy Erlangowego frameworka webowego. Kiedy już mi się to udało, to mam bardzo fajny punkt odniesienia miedzy tymi trzema rozwiązaniami, mimo że są identyczne z punktu widzenia biznesowego, ale nie kodu. I widzę, okay, tu jest łatwiej, prościej, lepiej się testuje, jest izolacja testów – jak wszedł Elixir to change sety i cała reszta versus jak to się robi w active record. Ten punkt odniesienia sprawia, że starasz się napisać te projekty, nazwijmy to pod pewny obrany wzorzec. To pozwala Ci starać się odzwierciedlić z tego wzorca wszystkie rzeczy z nowej technologii, czyli jak się pisze teraz testy, JUnit testy czy testy integracyjne przy pomocy tej nowej technologii. Na tym poziomie dochodzisz do momentu, w którym obecna znajomość dziedziny problemowej oraz poprzedni implementacje tego projektu w czymś innym potencjalnie wyznaczają Ci kierunek – jak nie zejść z trasy jakości. Nie o to chodzi, żeby napisać szybki web serwis i zobaczysz, że śmiga. Zobaczyć wartość z tego, jak łatwo piszę się teraz testy czy że Elixir ma DOC testy i jak fajnie to działa, kiedy piszesz fragment dokumentacji i ona jest automatycznie utrzymywana, ponieważ to jest element testu. To wszystko daje Ci tę percepcję, dlaczego jest wartość w nauce, na przykład kolejnego języka programowania, chociażby dla fanu, bo w najbliższym czasie nie bedziesz w nim pracował.

Krzysztof: Pewnie. Łukasz wspomniałeś, że bierzesz udział w rekrutacji, zatrudniasz programistów. Zahaczyliśmy tutaj o taki temat wpływu projektów, które jesteśmy w stanie wystawić na githubie czy coś w tym stylu, wpływu na proces rekrutacji, na nasz odbiór czy na znaczenie naszych umiejętności. Tutaj chciałem Cię bardziej podpytać i pociągnąć ten wątek. Jaki jest wpływ takich projektów na ocenę kandydata w twojej opinii?

Łukasz: Olbrzymi. Dla mnie ktoś, kto na przykład forkuje sobie publiczne repozytorium na githubie, po to, by zaoferować potem pull requesty w ramach własnego, prywatnego czasu, w ramach swojej pasji do tego projektu czy języka programowania. Chociaż często bywa tak, że zaczyna to się z frustracji, ponieważ tworzy się kod, który próbuje obejść jakiś problem w ramach własnej aplikacji.

Krzysztof: Tak, wszyscy tam byliśmy.

Łukasz: Dokładnie. W związku z czymś ktoś mówi: dobra, usiądę i zrobię to porządnie i zrobię im pull requesta. Dla mnie ma to olbrzymią wartość. To jest pokazanie inicjatywy, tego, że dla kogoś programowanie nie ejst tylko pracą i nie jest normowane godzinami pracy, tylko jest to człowiek, którego to naprawdę kreci i chce nie tylko rosnąć w ramach nowego projektu, do którego dołącza do naszej firmy, ale również jako deweloper. To jest potwornie istotnie, dlatego że zbyt często ramy firmowe nakładają ludziom myślenie, Żeby nie wybiegać za bardzo po za ramy domeny biznesowej, tylko po to, aby nie tracić czasu, bo są deadliny. Fakt, że ludzie są gotowi pójść tą extra mile, dodatkowy krok zrobić w kierunku samorozwoju jest niesamowicie dla mnie istotnie. Nie powiem, że jest to najważniejszy czynnik, ale kiedy mam dwóch identycznych kandydatów, i jeden z nich ma side projecty lub jakikolwiek commitment w świecie open source, to jest to olbrzymi plus i nierzadko decydujący czynnik.

Krzysztof: Zgadzam się absolutnie. Dodałbym jeszcze, że prowadzenie takich projektów, które gdzieś sobie żyją i zbierają community, tak jak powiedziałeś, to jest dodatkowy plus do pracy w grupie, do soft skills. W mojej opinii dużo to daje do oceny programisty, bo to znaczy, że najprawdopodobniej będzie on lepiej współpracował w zespole. To jest jak najbardziej cenione.

Łukasz: Tak jest. Github to nie sam kod, są też tam issues i możemy zobaczyć sobie kulturę komunikacji takiego człowieka na co dzień, bez maski, którą ubiera na tę rozmowę i uśmiechu. Widzimy go w swoim środowisku, na co dzień, jak traktuje swoich kolegów czy osoby takie jak on, za darmo, są w stanie utrzymywać jakaś aplikację open source, jako element pewnego community. Pozwala to zobaczyć tego człowieka z bliska, takiego, jakim jest na co dzień. Jeżeli to jest pozytywne to jest to bardzo duża wartość dla osoby rekrutującej, dla sprawdzenia czy dopasowania kulturowego.

Krzysztof: Poruszyliśmy temat prowadzenia takich projektów w kontekscie nauki. Chciałbym teraz przejść w kierunku doświadczonych programistów, czyli takich, którzy mają już naście lat na swoim koncie. Często jest to tak, że mają oni opory przed próbowaniem rzeczy nowych, bo nagle muszą zmierzyć się z technologiami, których tak naprawdę mało potrafią albo bardzo mało. Czyli muszą mentalnie w swoim rozwoju się cofnąć, przyznać się przed sobą, że czegoś nie potrafią. Według ciebie ma to jakieś znaczenie, czy taki pet project jest robiony przez juniora czy seniora?

Łukasz: Nie wydaje mi się. Moim zdaniem jest to tak, że zaczyna się od tego na jakim jesteś etapie rozwoju i swoich umiejętności koderskich. Zawsze znajdzie się temat, który Cię zainteresuje lub zawsze znajdzie się temat, z którego zawsze możesz nauczyć się czegoś nowego. Jakiś czas temu odbyłem fajną rozmowę z kimś ze środowiska właśnie Ruby on Rails i Rails girls inicjatyw, gdzie wiele osób było przerażone, kiedy zobaczyli takie drzewo kompetencji Railsów. Jest tam 15 gałęzi i każdy się rozdziela na kolejne podgałęzie. Łącznie jest ich około 300. To jest fajna myśl, że w samym świecie Ruby, samych implementacji Ruby, rodzajów implementacji Ruby, rodzajów baz oraz ogólnych stucków, na których możesz to zdiplojować czy to będzie AWS czy Digital Option. Jak zaczniesz to przez siebie przemnażać, to ta liczba nie ma końca. podejrzewam, że nie ma pojedynczego człowieka na świecie, albo jest tylko kilku, którzy potrafią odpowiedzieć na pytanie, czy zrozumieć dokładnie każdą z tych konfiguracji. Dlatego w zależności od zainteresowań, czy nawet uwarunkowań biznesowych ludzie rozwijają się indywidualnie, niezależnie i w pewien niepowtarzalny sposób. One są bardzo zbliżone do siebie i ludzie często mówią, że ten programuje w Railsach i tamtem programuje w Railsach i kwalifikują ich do tego samego kubełka PROGRAMIŚCI RAILSÓW. Prawda jest taka, że każdy z nich może mieć inny background, może przyjść ze świata PHP, a może przyjść ze świata Javy. To też wpływa na sposób myślenia, chociażby dotyczący programowania obiektowego. Osoba z doświadczeniem, to nie ważne ile ma lat za pasem w programowaniu, ale właśnie zdanie sobie sprawy: wiem, że nie wiem, i są tematy, których nie wiem, i umiem to przyznać przed sobą. Tym bardziej jeśli te tematy mnie interesują, to dlaczego mam nie próbować się rozwijać. Nawet jeśli jest to powrót do etapu: dobrze, zrobię sobie kolejną to do apkę albo coś w tym stylu, żeby zobaczyć jak się parsuje pliki CSV w Elixirze versus Pythonie czy czymś innym. Całe dziedziny programowanie wykluczały rzeczy, które otworzył przede mną Erlang z konkurencyjnością. Sposób myślenia o aplikacjach jest inny – w świecie OTP versus w świecie Railsów. To bogactwo możliwości jest dla mnie fascynujące, że można zobaczyć jak coś się rozwiązuje w inny sposób i z zupełnie inną mentalnością. Mój ulubiony przykład, to jest na przykład wirtualna maszynka Erlanga – procesy są bardzo proste i każdy ma swoją własną, na koniec jest posprzątane po sobie, po każdym niezależnym procesie versus JVM, które jest majstersztykiem algorytmiki i naszych umiejętności matematycznych na planecie. Po prostu dziesiątki tysięcy godzin ludzi, którzy porobili doktoraty i wyższe stopnie naukowe na tym, ale z punktu widzenia filozofii zupełnie inne podejście obu wirtualnych maszyn.

Krzysztof: Myślę, że to wszystko o czym mówiłeś i tej samoświadomości testy – to szeroki temat i pewnie na osobny odcinek. Faktycznie, takie podejście, że potrafię się przyznać, że czegoś nie wiem – pewnie tutaj dużo pomaga. Łukasz powiedzieliśmy, że Side Project może powiedzmy tyczyć jakiegoś problemu, który mamy do rozwiązania, jakiegoś pomysłu, który chcemy wdrożyć, ale może dotyczyć spróbowania jakieś nowej technologii, języka programowania, frameworka i tak dalej. Tak jak wspomniałeś, to jest mniej więcej ta drogą, którą obrałeś, żeby trafić na Elixira. Możesz powiedzieć dlaczego Elixir i jak to wyglądało z Twojej strony?

Łukasz: Tak jak wspomniałem, miałem taką fazę, że zacząłeś potwornie interesować się języka i programowania przy pomocy użycia funkcji – funkcjonalnego. To było tak, ze zacząłem sobie doświadczać ze skalą, z różnymi odmianami Lispa i najbardziej przypadł mi do gustu Erlang. Bawiąc się Erlangiem, testując go również w tym rozwiązaniu takim, że w kilku terminalach otwierasz wirtualna maszynę i robisz connection i widzisz jak to przekazywanie sobie wiadomości między procesami działa, co się dzieje jak to się wysypie i samo wstaje przy pomocy supervisorów. Potwornie mnie wciągnęło. Zacząłem się bawić tym Chicago Boss. Jest to framework webowy trochę na wzór Railsów, ale w tej chwili nawet nie rozwijany. Był rozwijany przez jednego, może dwie osoby przez krótką chwilę. Tam bardzo mocno brakowało toolsetu, czyli narzędzi, które automatycznie pozwalały Ci budować, automatycznie diplojować, czy tego co teraz ma Elixir – mix tasków. Czasem wpadł mi w ręce Elixir, zbudowany też na tym EVM – Erlang Virual Machine – z możliwością de facto odwoływania się, ponieważ to się wszystko potem kompiluje to beema tak czy siak, więc z możliwością odwoływania się do funkcji Erlangowych i bibliotek, modułów Erlangowych. Co więcej, to jest taka można drobnostka, ale dla mnie miało to ogromne znaczenie – wizualnie bardzo podobny do Ruby – co jest potwornie zachęcające, szczególnie jeśli z Ruby pracowaliście. Oczywiście, na koniec dnia nie ma za wiele wspólnego z Ruby, bo pajpowanie i przekazywanie funkcji – cała filozofia jest zupełnie inna. Natomiast pierwsze wrażenie jest takie, że przechodząc krok dalej można się nauczyć nowego języka, jasne, że to tylko taka percepcja, jest to bardzo zachęcające, jeśli semantyka i wizualny aspekt języka do ciebie przemawiają. Ja tak miałem i z Ruby i z Pythonem. Oba te języki wizualnie do mnie przemawiały, to jak wygląda, jak się je pisze czy czyta. Z Elixirem miałem podobnie, także to było w tym kierunku. Następny krok był taki, że powtórzyłem, nazwijmy to – napisałem kilka prostych rozwiązań w tym Elixirze, nawet takich na podstawie książek, które w Elixirze były wtedy dostępne, czyli rzeczy związane z matematyką, sortowaniem. Tak po to, aby zobaczyć jak to działa, kiedy pewne rzeczy dzieją się dużo szybciej tylko dlatego, że można je wykonać równolegle. Następnie zbudowałem aplikację w postaci czatu, co było dla mnie olbrzymim szokiem, w takim sensie – jak prosto się to robi. Wiadomość może być tuplem z nadawcą, odbiorcą i samym ciałem wiadomości. To jest obsługiwane na poziomie języka, a nie na poziomie Twojej logiki biznesowej, czyli musisz tworzyć obiekty i wokół tego wszystkiego wspólnie zbudować od zera całe założenia w jakimkolwiek innym języku programowania niefunkcyjnym, który nie posiada takiej możliwości przesyłania wiadomości w ten sposób między procesami. Kolejnym krokiem była wydajność. Tutaj też bardzo mi się  Exlicir spodobał i na tym etapie zacząłem doświadczać z elementami webowymi, z frameworkiem finix – odpowiednikiem Railsów. Elixir to sam język, a Finix to framework. Następna rzecz, która mi się strasznie sposobała, to ta obsługa WebSocketów, czyli to, że nareszcie możemy zrobić web. Wiem, że wiele projektów to obiecuje, ale nikomu wcześniej nie udało się tego zrobić na dużą skalę. W Elixirze ze względu na skalowalność procesów i tego, że cały backend serwerowy się klastruje w jeden wielki serwer. Używam wielu skrótów myślowych, ale docelowo mniej więcej tak to wygląda. Pozwalało mi to robić rozwiązania, w których masz 5-6 tysięcy wirtualnych klientów na swoim czasie i wszyscy do wszystkich broadcastują z poziomu jednego laptopa, na którym to puszczam. On nie dostawał żadnej zadyszki i to było niesamowite. Tak mniej więcej to się potoczyło. Potem jak nadarzyła się okazja, to zaangażowałem się w kilka projektów. Najpierw jako freelancer, potem ostatecznie zaczęliśmy prace nad własnym startupem również w tej technologii. Nie powiem, były pewne wątpliwości i opory, ale również przekonywującym argumentem było to, że sporo osób ze świata Railsów czy ze świata innych rozwiązań webowych ma w tej chwili taką zagowstkę – ich ścieżka kariery zmierza w kierunku Elixira, a to dawało nam olbrzymią możliwość rekrutacyjną, osób, które właśnie przy pomocy chęci do samorozwoju i poznania nowej technologii – były gotowe dołączyć do naszego projektu.

Krzysztof: Przypomniało mi się, jak wspomniałeś o tym próbowaniu nowych języków, czy implementowaniu algorytmów czy innych rozwiązań, przypominał mi się taki serwis, który bardzo w tym pomagał. Właśnie próbowanie, testowanie nowych języków – ten serwis nazywa się exercism.io. On się składa z zestawu ćwiczeń do zrobienia, o rosnącym poziomie trudności. Tam jest naprawdę dużo języków programowania, więc polecam. W notatkach będzie link do serwisu. Jest on darmowy, więc warto sobie spróbować, po to, aby potestować różne języki. Może, tak jak Łukasz powiedziałeś, a nuż któryś ze słuchaczy zakocha się w czymś innym. Tutaj nie ma innej drogi. Trzeba wziąć na warsztat jakiś język i popróbować.

Kiedy powinienem widzieć jakieś oznaki, kiedy powinienem zauważyć, że jest czas na zakończenie takiego projektu? Kiedy jest czas na pożegnanie się z projektem i skupienie się na czymś innym?

Łukasz: Wydaje mi się, że kluczowe jest, czy w ramach własnych, postawionych oczekiwań, czy ta aplikacja już w ramach wymagań biznesowych, które sobie przyjęliśmy, robi to, co miała robić. Otestowanie tego pod kątem perspektyw, które były elementem naszego celu, czyli zbudowanie takiej aplikacji Get Things Done ponownie, tylko po to, aby zobaczyć jak implementacyjnie różni się w kolejnym single page aplication w emberze od czegoś innego. Możemy na tej podstawie dojść i wyciągnąć odpowiednie wnioski i stwierdzić, czy przy kolejnym projekcie chcemy nad tym pracować. Przyznam się, że zdarzały mi się sytuacje, kiedy zaczynałem łapać frustrację i miałem wyrzuty sumienia, że coś, co sobie postawiłem za cel nie jest realizowanie. Ostatecznie jakoś to się rozchodziło po kościach i zapominałem o tym projekcie. Po wielu miesiącach mam taką myśl, że to jest element pewnego za-ambitnego celu. Ten cel w pewnym momencie zaczął wpływać na mnie negatywnie, ponieważ czułem się źle, że nie rozwijam takiej aplikacji. Wtedy też trzeba sobie uczciwe powiedzieć, że to ma być dla zabawy, dla nauki. Jeżeli nie czuję tej frajdy, to po prostu tego nie robię. Czy ten projekt archiwizowałem czy usuwałem, żeby mnie nie stresowało dalej.

Krzysztof: Pewnie, nic na siłę. Jeśli już czujemy, że nie mamy tego funu, nie ciągnie nas, żeby dodatkowy czas poświęcać, to pewnie już jest najlepsza oznaka, że pora to zakończyć i spróbować czegoś nowego. Chciałbym Cię zapytać, czy masz jakieś przemyślenia, albo rady na ile taki projekt powinniśmy realizować, rozwijać sami? Czy może to wyjść społeczności? Spróbować skrzyknąć ludzi, albo wręcz zebrać ludzi na podobnym poziomie jak my, którzy jednocześnie rozwijając ten projekt mogliby się uczyć? Czy są jakieś zasady albo twoje spostrzeżenia na ten temat?

Łukasz: Wszelakiego rodzaju meetupy oraz spotkania dla programistów danego języka programowania, czy danych rozwiązań programistycznych są świetną okazją do tego, żeby wymienić się doświadczeniami. To, co ejst fantastyczne w tym zawodzie, czy w ogóle w tej dziedzinie, to to, że ludzie z zasady doceniają to, że ktoś tworzy. Jest to fajnie postrzegane i można się wymienić opiniami. Bardzo często się zdarza, że jesteś w stanie zapalić inne osoby do swojego pomysłu. oni zaczynają od tym mówić, zaczynają zgłaszać pomysły, albo wręcz sami potrafią powiedzieć: „Wiesz co, taki miałem pomysł, żeby to dodać, napiszę Ci pull requesta, przejrzysz, zobaczysz co się stanie.” Wtedy dzieje się następna magiczna rzecz, czyli dwie osoby lub więcej, o zupełnie innych historiach uzyskania swoich informacji, czy dojścia do tego doświadczenia – zaczynają dzielić się kodem. To różnie może się skończyć, ale przynajmniej mamy zupełnie inną perspektywę, jak coś można zakodować. Moim zdaniem w ten sposób człowiek się uczy dużo lepiej niż chociażby googlując czy czytając książki, bo masz na bieżąco poczuje, że pracujesz z kimś kto jest twoim mentorem, a ty jesteś dla niego mentorem.

Krzysztof: Mamy potencjalnie efektem synergii, gdzie jeden plus jeden równa się trzy. Faktycznie taka różna perspektywa nieraz potrafi dużo zmienić, potrafi pokierować taki projekt w zupełnie niespodziewanym kierunku. To jest pozytywna ścieżka, ale z drugiej strony może się to zakończyć kłótnią i zamknięciem projektu. Co też mam okazję obserwować. Zgadzam się z tobą, że warto w takie kooperacje wchodzi, chociażby po to, aby czegoś się nauczyć od ludzi, którzy mają inny background, inne doświadczenia, może inne technologie w swojej głowie. Nigdy nie wiadomo, w którym kierunku to pójdzie.

Załóżmy, że wszystko idzie dobrze, albo wręcz bardzo dobrze i taki projekt przekształca się w coś większego. Przekształca się w jakiś startup. I właśnie – co wtedy? Jakie masz przemyślenia na ten temat? Czy to ejst dobre rozpoczęcie firmy w ten sposób?

Łukasz: Zdecydowanie tak! Wiele ciekawych projektów powstało właśnie w ten sposób, że ludzie pracowali w swojej dziennej pracy, a na boku rozwijali side project, który nie ujrzał światła dziennego, dopóki nie był gotowy, czy dopóki go nie pokazali jakiejś liczbie osób, które to oklaskały czy dawały feedback. Tutaj istotne jest to, żeby zrozumieć, że na pewnym etapie nasz mały problem i jego małe rozwiązanie, może urosnąć do rangi biznesu. Po prostu. Przyznam się szczerze, że nawet sam miałem taką okazję doświadczyć czegoś takiego budując z paroma wybranymi osobami zupełnie towarzysko. Kolejny raz implementując projekt do zarządzania tłumaczeniami. Jest to oklepany temat i istnieje sporo takich aplikacji. To było właśnie naszym sposobem na testowanie i bawienie się technologią, Elixirem również czy wcześniej w Railsach napisanie tego samego projektu w ten sposób, żeby zobaczyć jak on się zachowa. To, co wyszło w między czasie to fakt, że parę innych osób, które też kodują w Elixirze, gdy zobaczyły ten projekt to stwierdziły, że chętnie tego poużywają. Po 15 czy 16 osobie postanowiliśmy zahostować to dla wszystkich i zobaczymy, czy ludzie będą się subskrybować i używać. Naturalnie wychodzą takie rzeczy. Nagle się okazało, że my rozwiązujemy głębszą potrzebę innym programistom, którzy dostrzegają to, doceniają i są w stanie wprowadzić ten projekt w ramach toolsetu czy narzędzi w ramach swojej własnej firmy.

Krzysztof: To świetna sprawa! Wspomniałeś, że było takie zapotrzebowanie na rynku na taki tool do zarządzania tłumaczeniami. Podjęliście się zrobienia tego w sposób jako side projekt, coś dodatkowego po pracy. Myślę, że to ciekawy temat. Mógłbyś więcej opowiedzieć – jak to się działo i o samym produkcie?

Łukasz: Produkt nazywa się YATT – jest to skrót od Yet Another Translation Tool, bo na samym początku celem nie było zbudowanie narzędzia komercyjnie. Celem było pobawianiem się WebSocketami tak, żeby przy pomocy Finixa i Elixira, żeby każdy inny projekt, frontendowy czy backendowy, mógł potem automatycznie mieć odświeżony pewien element kontentu, czy tłumaczeń na swojej stornie. Doprowadziliśmy to do momentu, w którym korzystaliśmy z tego sami, na naszych projektach klienckich, tam gdzie się pracowało. Z drugiej strony osoby, z którymi współpracowałem i na przestrzeni lat również na meetupach, gdzie w rozmowie wychodziła ta YATTA, wykazywali ogromny entuzjazm. Ten entuzjazm był dla nas paliwem, dla mnie, Dominika Zborowskiego i paru innych osób. Był olbrzymim paliwem, żeby pociągnąć ten temat dalej. Dziś jest już na takim etapie, że nie jest to nie wiadomo jaki biznes, ale zaczęliśmy na siebie zarabiać i spłacać koszty bieżące za serwery i reklamę.

Krzysztof: Ten projekt jest dostępny w sieci. Można z niego już korzystać pod adresem yattaapp.net – link będzie w opisie do odcinka. Wiem Łukasz, że masz specjalny prezent dla słuchaczy podcastu.

Łukasz: Chcieliśmy zaproponować wszystkim polskim słuchaczom twojego podcastu 20% zniżkę. Jest specjalny link, który będzie dołączony do notatek pod tym odcinkiem. Zapraszam, żeby przetestować. Jest to rozwiązanie, które jest unikatowe w swojej prostocie, ale oferuje kilka wyjątkowych rozwiązań, w które lubię wierzyć, że są unikatowe w skali wszystkich naszych konkurentów. Pozwalają bardzo uprosić system zarządzania contentem czy tłumaczeniami na projekcie. Nawet jeśli macie tylko jeden język.

Krzysztof: Super, dzięki wielkie Łukasz! Zapraszam do zapoznania się z aplikacją i z tą ofertą. Ja jeszcze chciałbym cię o coś zapytać. Z tego co obserwuję na rynku firm, które zajmują się programowanie, obserwuję taki trend inwestowania w możliwość realizowania takich dodatkowych projektów, nawet w czasie pracy. To oczywiście wyszło od takich gigantów jak Google czy Facebook, ale nawet mniejsze startupy mają kilka godzin przeznaczone na swobodną zabawę czy eksperymentowanie z technologiami i frameworkami. To jest czas, za który płacą jak za normalne godziny poświęcone na pracę. Jaką według ciebie daje to wartość obydwu stronom – pracownikowi i pracodawcy?

Łukasz: Wydaje mi się, że to jest doskonały sposób na wprowadzenie innowacji w organizacji. Google jest prawdopodobnie najlepszym przykładem. Od kilku lat wiem od znajomych, że się otarli o Googla czy są w nim cały czas, że 20%, czyli na przykład piątki są dniem: „pracuj nad czym chcesz w ramach Google i w ramach jego strategii.” Może nawet niewiele osób to wie, ale warto przytoczyć, że Gmail jako najbardziej popularna i dopracowana usługa poczty dla każdego w internecie, powstał jako taki projekt. Dzisiaj widzimy wielką ewolucję w kierunku myślenia, że to nie management podejmuje decyzję i strategię długofalowa, tylko oddolnie pozwala się pracownikom współtworzyć wizję firmę i współtworzyć produkt. Często osoby w managemencie nie są w stanie dostrzec nawet potencjału czegoś tak prostego jak Gmail, który oczywiście dla Google stał się elementem podstawy profilowania użytkowników pod reklamę. W przypadku innych organizacji również pozwala na bardzo pożądane elementy przewagi konkurencyjnej. Jest to forma RND, jest to forma podoświadczenia. Nawet jeśli podejmie się decyzję, że coś nie działa. Jest to doskonałe doświadczenie, żeby zebrać argumenty przeciwko czemu. Weźmy sobie rynek Hardware – jak wszyscy idą w kierunku tych klikowalnych ekranów, czy laptopów, dotykowych ekranów. Można to lubić, można nie lubić. Są jednak firmy, które jasno mówią: „słuchajcie, my w to nie pójdziemy, ponieważ nasze testy i bawienie się w tym kierunku, nasze doświadczenia w tym kierunku pokazały, że to nie ma sensu.” Oczywiście, nie wiem, na ile są to inicjatywy oddolne, ale chodziło mi tutaj o pokazanie argumentu przeciwko robieniu czegoś tylko dlatego, że taki jest mainstream czy kultura rynku czy decyzja samego zarządu.

Krzysztof: Myślę, że tutaj jest element employeer brandingu, albo trzymania pracowników, podniesieniach ich motywacji, takich rzeczy, które nie są bezpośrednio widoczne, ale mimo wszystko w długofalowej perspektywie przyczyniają się do tego, że firma rozwija się lepiej.

Łukasz: To również, zdecydowanie. Tylko to, z czym się spotykam, to w zależności z jakim człowiekiem się rozmaita, to ludzie często nie potrafią sobie wyobrazić tego, że ktoś im da 10 czy 20% czasu na dowolne rzeczy. Firma, czyli management ma złe postrzeganie takich sytuacji, czyli na koniec dnia mówią: „to jest 20%, możesz wykorzystać jak chcesz, ale nadal ma to przynieść ileś tam zysku.”. Jeżeli nie są one odpowiednio ustawione dla pracownika czy jego managera managera, czy managera jego managera, to to nie zadziała. Dlatego niewiele osób ma doświadczenie, wśród tych z którymi się obracam, że widzieli działający system,w  którym ludzie się nagradzani lub zachęcani do tego, żeby robić rzeczy na boku.

Krzysztof: Faktycznie, bo to nie jest łatwa sprawa. Pewnie osobny podcast można by było na ten temat nagrać.

Łukasz: Filozoficznego bardziej.

Krzysztof: Na koniec proszę Łukasz podziel się jeszcze jakie pet project sam zrealizowałeś? po części zahaczyliśmy trochę o ten temat. Czy nadal planujesz w ten sposób się rozwijać?

Łukasz: Dzisiaj jest trochę mniej czasu, bo prowadzenie własnego startupu ma to do siebie, że jest tego czasu mniej. Na przestrzeni ostatnich paru lat, zdecydowanie pisałem małe proste JAMY, do Relsów, czy jakieś rozszerzenia do istniejących bibliotek, które rozwiązywały mój konkretny problem. Parę lat temu, kiedy  strajk nie był tak popularny, były inne systemy płatności, wyobraź sobie, że chociażby tak zwany direct debit, czyli to, że co miesiąc pobierana jest automatycznie kasa w imieniu klienta, w ramach subskrypcji, z konta na konto nie było oczywistym rozwiązanie. Zdarzało się pisać nawet takie rzeczy jak rozszerzenia do istniejących, olbrzymich rozwiązań firm finansowych, które w tamtym czasie były na rynku dominujące. Myślę, że było olbrzymim benefitem dla tych film na przykład open sourcowanie swoich rozwiązań, dlatego, że community programistów dopisywało im te rozwiązania. Tak jak wspomniałem, napisałem szereg tych aplikacji GTD, chyba w każdym możliwym miedzy latami 2005-2011, rozwiązania Java sktryptowe, chociażby po to, aby zobaczyć jak to działa, jak działa SPA, MMVS w przeglądarce. Z drugiej stronie, po stronie backendowej to też zdarzyło mi się napisać aplikację, której nie dokończyłem nigdy, do zarządzania czasem programisty. Też bawiliśmy się na różne sposoby, doświadczyliśmy właśnie z różnymi rozwiązaniami. Tez powstała nieoficjalna grupa, która to tworzyła, która z czasem się rozpadła. Ostatecznie taką rzeczą, która dojrzała do tego, żeby być niezależną działalnością i inicjatywą biznesowa jest YATTA.

Krzysztof: Świetnie. bardzo Ci dziękuje za podzielenie się swoją wiedzą i doświadczeniami w tym temacie. jeszcze raz przypominam właśnie o YATTAAPP.NET i o promocji, którą Łukasz przygotował. Z mojej strony wielkie, wielkie dzięki Łukasz i powiedz na koniec, gdzie Cię można znaleźć.

Łukasz: Śmieszna historia z czasów studiów – mam taką ksywkę luki3k5, bo 3k5 to jest 3005, to był mój numer indeksu studenckiego. W związku z czym jestem luki3k5 praktycznie wszędzie, czyli dowolny social media, czy Gmail to jestem luki3k5. Jeśli to się wrzuci w Google czy napisze maila na ten adres luki3k5@gmail.com to to do mnie dotrze. Tak samo tam jest link do Facebooka, więc zapraszam, żeby się połączyć tam. Tam też jestem luki3k5 na Facebooku, chociaż to jest nick, a występuje pod moim imieniem i nazwiskiem w wersji bez polskich znaków. Zapraszam. Dziękuje Krzysztof za to, że mnie zaprosiłeś do odcinka. Cała przyjemność po mojej stronie.

Krzysztof: Dzięki wielkie Łukasz. Wszystkie linki będą w opisie do odcinka, tam też zapraszam. Do usłyszenia, trzymaj się, cześć!

Łukasz: Dziękuje serdecznie! Cześć!

Krzysztof: To na tyle z tego co przygotowałem dla ciebie na dzisiaj. Mam nadzieje, że Łukasz zachęcił Cię do prowadzenia projektów pobocznych i to nie tylko po to, aby się rozwijać, sprawdzać nowe technologie, ale również po to, by mieć czym się pochwalić podczas rektrutatacji.

Przypominam ci o prezencie od Łukasza w postaci zniżki na użytkowanie aplikacji do zarzadzenia tłumaczeniami YATTA. Jak zawsze zapraszam cie na fanpage na Facebooku, jeśli słuchasz na stronie lub poprzez Youtube, to zapraszam cie do zaisntalowania apliakcji do słuchania podcastów i zaskrubowania Porozmawiajmy o IT. Słuchanie w ten sposób jest znacznie wygodniejsze i przyjemniejsze. Jeśli masz jakies pytanie, jak zawsze zapraszam cię do kontaktu na krzysztof@porozmawiajmyoit.pl. Miło mi było gościć w twoich uszach. Ja się nazywam Krzystzof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o projektach podobnych. Zapraszam cię do kolejnego odcinka już za dwa tygodnie. Cześć!

mm
Krzysztof Kempiński
krzysztof@porozmawiajmyoit.pl

Jestem ekspertem w branży IT, w której działam od 2005 roku. Zawodowo zajmuję się web-developmentem i zarządzaniem działami IT. Dodatkowo prowadzę podcast, kanał na YouTube i blog programistyczny. Moją misją jest inspirowanie ludzi do poszerzania swoich horyzontów poprzez publikowanie wywiadów o trendach, technologiach i zjawiskach występujących w IT.