Decydując się na założenie startupu, przestajesz być tylko programistą. Rozmawiamy z CTO TwójPsycholog
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.
Spis treści
Mainstreamowe media mówią, że 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ą, że “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, że programiści powinni myśleć o rozwiązywaniu problemów i dostarczaniu wartości biznesowej?
Uważam, że 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 oprogramowania – 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ę. Kluczowe 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 kluczowe znaczenie.
Mam wrażenie, że 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. Współpraca z biznesem przy określaniu wymagań okazuje się czasem nawet 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.