Robert Witkowski przebył drogę od juniora do Lead Software Engineera, by po sześciu latach porzucić etat na rzecz startupu TwójPsycholog, którego jest współzałożycielem. Zapytaliśmy go o to, jak podjął decyzję o tym, by przejść ”na swoje”. Z naszej rozmowy dowiecie się także, o czym za mało mówi się w kontekście pracy w startupie.
Mainstreamowe media mówią, iż praca programisty to praca marzeń. W domu, przed komputerem, raczej mało komu kojarzy się ze stresem, zmęczeniem czy frustracją. Jaka jest Twoja perspektywa?
Dużo zależy od tego, jak zdefiniowalibyśmy pojęcie pracy marzeń. Dla jednego będzie to praca przed komputerem z wysokimi zarobkami, a dla kogoś innego praca, w której może podróżować i całymi dniami chodzić boso po dżungli zarabiając przy tym przysłowiowe parę groszy.
Dla mnie praca to pasja, dzięki czemu jest mi zdecydowanie łatwiej. Po prostu lubię to, co robię i naprawdę nie mam na co narzekać. Oczywiście zdarzają się gorsze dni spowodowane nudnymi zadaniami, niepotrzebnymi spotkaniami czy natłokiem obowiązków, ale to zdecydowanie wyjątek od reguły.
Co jest najczęstszą przyczyną zmęczenia czy frustracji w IT?
Nie znajdziemy jednej, konkretnej odpowiedzi. Wszystko zależy od miejsca, w którym aktualnie znajduje się dana osoba. Dla jednych będzie to nierozwojowy projekt z powtarzalnymi zadaniami, dla innych zbyt wygórowane wymagania i oczekiwania, a dla jeszcze innych toksyczna atmosfera/zespół/szef.
Co w podejściu do pracy powinni zmienić programiści, a na co uwagę powinni zwrócić Team Leaderzy, kadra zarządcza?
Programiści powinni przestać skupiać się na używaniu konkretnych technologii i uprawianiu tzw. CV-driven development, a zacząć myśleć przede wszystkim o rozwiązywaniu problemów i dostarczaniu wartości biznesowej.
Team Leaderzy z kolei powinni skupić się przede wszystkim na codziennym doskonaleniu swojego zespołu: na wsparciu, budowaniu autonomii, pozytywnej atmosfery i środowiska, w którym po prostu chce się pracować. Team Leader nie musi brać na siebie najtrudniejszych technicznych zadań i poświęcać im większości swojego czasu.
Co masz na myśli mówiąc “CV-driven development”?
CV-driven development to takie delikatnie “prześmiewcze” określenie na podejście do tworzenia oprogramowania, w którym nie znając wymagań biznesowych i kontekstu projektu, architekci i programiści już wiedzą, iż “będą robić mikroserwisy z wykorzystaniem Quarkusa, eventy będą latały po Kafce, zastosują event sourcing, CQRSa i 15 najnowszych bibliotek utils’owych”.
Najpopularniejszą definicją jest chyba ta z bloga Martina Jee:
CV Driven Development (CDD) is a software development process which prioritises design and development choices that will enhance the implementing programmer’s Curriculum Vitae over other potential solutions, regardless of how rational that choice is.
Używanie nowoczesnych technologii jest oczywiście fajne i również to lubię. Ale trzeba to robić z głową.
Co z kolei masz na myśli, mówiąc o tym, iż programiści powinni myśleć o rozwiązywaniu problemów i dostarczaniu wartości biznesowej?
Uważam, iż my, programiści, mamy tendencje do rozdmuchiwania rozwiązań, niepotrzebnie je komplikując i utrudniając sobie życie. Próbujemy rozwiązywać problemy techniczne, które nie istnieją. Optymalizować rozwiązania pod kątem wydajności nie mając z nią żadnych problemów, działając na 100 razy mniejszej skali niż zakładana we wstępnie definiowanych wymaganiach. Nie stosujemy się do podstawowych, dobrych praktyk budowania systemu – KISS (Keep it simple stupid) oraz YAGNI (You aren’t gonna need it).
W wielu sytuacjach na samym początku naprawdę wystarczy dobrze zaprojektowana monolityczna aplikacja, która niekoniecznie musi składać się z wielu mikroserwisów wystawianych na Kubernetesie komunikujących się asynchronicznie przez Kafkę. najważniejsze jest to, aby aplikacja spełniała postawione przed nią wymagania biznesowe i realizowała cele organizacji.
W poszukiwaniu kolejnej pracy nie ma znaczenia technologia, w której pracowałeś, ale sposób, w jaki rozwiązywałeś problemy?
Znajomość technologii ma ogromne znaczenie i jest bardzo pomocna w codziennej pracy. Jednak to, jak bardzo zwracamy na nią uwagę w poszukiwaniu nowego miejsca pracy jest zależne od kilku czynników.
Na rynku mamy wiele typów programistów, na przykład “klepaczy”. Biorą oni konkretne zadanie dotyczące nowej funkcjonalności, bardzo dobrze rozpisane przez analityka systemowego i bawią się w tłumaczenie z polskiego na Javę/Pythona przy użyciu swoich pięciu ulubionych technologii. Jak mają się dotknąć czegoś innego (a szczególnie tego, co w firmie nazywają “systemem legacy”) to wpadają w rozpacz. Dla tego typu osób technologia będzie miała najważniejsze znaczenie.
Mam wrażenie, iż wraz z doświadczeniem u większości z nas opisane wyżej podejście się zmienia. Grzebanie w starych technologiach przestaje być straszne, a staje się ciekawe. kooperacja z biznesem przy określaniu wymagań okazuje się czasem choćby fajniejsza niż kolejny dzień spędzony na debugowaniu problemów z wydajnością relacyjnej bazy danych.
Dla tego typu osób konkretne nazwy technologii wymienione w ogłoszeniu o pracę nie będą miały już tak dużego znaczenia.
Wszystko, o czym za mało mówi się w branży IT.
Prosto na Twoją skrzynkę.
Jak na etapie rekrutacji sprawdzić, czy firma, do której aplikuję, po prostu zadba o mnie? O to, iż będę pracował w wartościowym zespole?
To jest niestety bardzo trudne. Na rozmowach firmy często przedstawiają siebie w samych superlatywach, chcąc przekonać kandydata. Dopiero po jakimś czasie wychodzą tematy, które zaczynają irytować i przestaje być tak kolorowo.
Dobrym pomysłem jest prośba o spotkanie z zespołem, w którym docelowo będziemy pracować. Na takie spotkanie kandydat powinien przygotować listę konkretnych pytań i tematów, które go nurtują. Członkowie konkretnego zespołu dużo dokładniej i, moim zdaniem, bardziej szczerze są w stanie opowiedzieć o sytuacji w projekcie/firmie.
O co byś ich zapytał?
Na pewno warto zapytać:
- Czy każdy pracownik ma zaplanowaną ścieżkę rozwoju? Jak ona wygląda i kto odpowiada za wsparcie w jej realizacji?
- Jak wygląda przykładowy dzień w pracy?
- Jak wygląda cały proces rozwoju oprogramowania?
- Jak dużo procesów jest zautomatyzowanych?
- Jak wygląda kooperacja z innymi rolami wewnątrz zespołu – z analitykami, testerami, biznesem, Product Owner’ami?
- Jak wygląda kooperacja z innymi zespołami – czy zespół jest mocno zależy od wielu innych działów, czy jest mocno autonomiczny/samowystarczalny?
Nie wszystkie pytania są stricte związane z tym, czy “firma się mną zaopiekuje”, ale jestem pewny, iż pokażą, jak mi się będzie w niej na co dzień pracować.
Firmy, w których pracowałeś znajdowały czas na integrację, poświęcały czas na rozmowy zespołowe, szkolenia dla Team Leaderów? Te elementy nie przynoszą zysku, nie przekładają się na realizację tasków.
Nie zgadzam się z tym, iż wymienione inicjatywy nie przekładają się na realizację zadań/celów. Moim zdaniem jest wręcz przeciwnie. Zespół, który jest zgrany, potrafi ze sobą szczerze rozmawiać, a członkowie ufają sobie nawzajem, na co dzień pracuje wydajniej i po prostu lepiej.
Pracowałem w różnych zespołach – w jednych regularnie wychodziliśmy na wspólne piwko po pracy, a w innych przez pół roku nikt choćby o tym nie wspomniał. Pewnie możesz się już domyśleć, który zespołów był tym wydajniejszym, a mi osobiście pracowało się po prostu fajniej.
Jeżeli chodzi o szkolenia dla Team Leaderów – sam uczestniczyłem w dwóch kilkudniowy szkoleniach tego typu, na których skupialiśmy się tylko i wyłącznie na tematach miękkich – poprawnej komunikacji, kulturze feedbacku, umiejętności rozwiązywania trudnych sytuacji, rozmowach o podwyżkach.
Myślę, iż jest to bardzo potrzebne i każda osoba, która chce iść w stronę ścieżki liderskiej (a nie eksperckiej), powinna przejść przez tego typu szkolenie.
Skupmy się na Twojej ścieżce kariery. Dwa lata temu odszedłeś z etatu w Altkom Software, by rozwijać swój startup. Opowiedz o procesie podejmowania decyzji. Dlaczego z Altkomu odszedłeś dwa lata temu, a nie wcześniej/później?
Proces był długi i wymagał wielu przemyśleń. W Altkomie spędziłem 6 lat, to tam rozpoczynałem pracę jako programista, przechodząc drogę od juniora bez doświadczenia do lidera technicznego ze swoim kilkuosobowym zespołem. Miałem naprawdę super ludzi obok siebie, bardzo interesujące wyzwania, a dodatkowo zarabiałem dobre pieniądze.
Pójście “na swoje” wiązało się z obniżeniem wynagrodzenia, utratą “ciepłej posady” oraz założeniem JDG (jednoosobowej działalności gospodarczej). Biorąc pod uwagę dodatkowo to, iż w życiu prywatnym byliśmy z narzeczoną (teraz już żoną) w trakcie załatwiania kredytu hipotecznego – nie było łatwo.
Przymierzałem się do tego dobrych parę miesięcy. Odszedłem w maju, a firma wiedziała o moich planach już w styczniu. Chciałem być na maxa “fair”, domknąć swoje tematy i przekazać wiedzę. Załatwienie tematów z obecnym pracodawcą to był jednak tylko jeden obszar.
Drugim było upewnienie się, czy nasz startup na pewno na to stać i czy moja pensja to będą odpowiednio wydane pieniądze. TwojPsycholog nie był finansowany przez VC, więc nie mieliśmy kilku milionów na koncie na inwestycje. W momencie mojego przejścia na pełen etat pozyskaliśmy kilkaset tysięcy złotych od aniołów biznesu i to była ta baza, która miała zapewnić możliwość rozwoju firmy i wypłaty wynagrodzeń współzałożycielom przez kilka miesięcy.
Jakiego rzędu jest to inwestycja czasowa?
Pracujesz ile starczy Ci sił. Na początku rozwoju firmy pracowałem 8 godzin dziennie na etacie, a praktycznie drugie 8 godzin tworzyłem TwojPsycholog. jeżeli nie ogarnąłem czegoś w tygodniu, siedziałem w weekend. Na każdy wyjazd (czy to urlop, czy wyjazd na weekend do rodziców) – brałem ze sobą komputer, żeby przeczytać maile z ogólnej skrzynki, naprawić buga czy zrobić przynajmniej jakąś małą nową funkcjonalność.
To nie jest zdrowe podejście na dłuższą metę. Jestem zdania, iż można tak działać przez jakiś czas, jeżeli mocno wierzymy w sukces i nam zależy. Pomimo tego, iż naprawdę mogę nazwać siebie pasjonatem i bardzo lubię pracę programisty to uwierzcie mi, iż nikomu na dobre nie wychodzi siedzenie po 16 godzin dziennie przed komputerem.
