Najczęściej wpływ na zmianę pracy ma czynnik ludzki. Wywiad z Maciejem Opałą

Co wpływa na zmianę pracy? Czego potrzebuje programista, by nie czuć, że stoi w miejscu? Na te i na wiele innych pytań dot. ścieżki kariery w IT, odpowiedzi znajdziecie w naszej rozmowie z Maćkiem Opałą, Senior Software Engineer w SoftwareMill.

Czego brakuje w programie nauczania studiów informatycznych? Co podniosłoby rangę studiów informatycznych?

Studia ukończyłem w 2009 roku, więc stosunkowo dawno, niestety nie śledzę, jak dokładnie zmienia się program, ale ostatnio widziałem program “Inżynierii internetu rzeczy” na WEiTI PW i naprawdę wyglądało to dobrze. Pytanie jeszcze, co dokładnie stoi za tym planem. Czy realna wiedza i technologia, czy tylko ładne nazwy przedmiotów?

Jak było za Twoich czasów?

W czasach, kiedy studiowałem brakowało przede wszystkim dotrzymywania kroku rynkowi. Mieliśmy masę przedmiotów typowo inżynierskich (rysunek techniczny, pomiary, teorię obwodów) – na co wtedy strasznie narzekałem, ale dziś uważam, że ma sens, bo co to za inżynier, który nie umie przeczytać schematu – a sporo mniej typowo informatycznych. A jak już były to jakieś zupełne podstawy nieprzystające do realiów rynkowych (nie słyszałem za to w ogóle o mavenie).

Prowadzący powinni śledzić trendy i przemycać je do programu. Zawsze też marzyłem o studiach “modułowych” opartych na wspólnej bazie – umówmy się, każdy powinien się umieć poruszać po systemie z rodziny UNIX lub napisać prosty skrypt w bashu. Na takich studiach student sam tworzyłby swój program nauczania w oparciu o swoje preferencje i przykładowe ścieżki przygotowane przez uczelnię. Chcesz poznać sieci? Wybierz to, to i to. Na trzecim roku przeszedłem na indywidualny tok studiów i to była super sprawa, polecam każdemu! Oczywiście nie każdy może, bo istotne były wyniki.

Oferty pracy z

Jak wyglądały Twoje pierwsze poszukiwania pracy? Opowiedz o ówczesnym rynku pracy w IT.

Pracy zacząłem szukać bardzo późno, bo dopiero na V roku. Do tego czasu większość moich kolegów już pracowała, a ja mieszkałem z rodzicami i miałem wszystko, czego potrzebowałem, dlatego nie musiałem szukać pracy. Pamiętam, że długo szukałem pierwszej pracy i w pewnym momencie zacząłem wątpić, że to się w ogóle uda, plułem sobie w brodę, że nie zacząłem wcześniej. Chodziłem po różnych firmach od korporacji do małych kilkuosobowych firm i wszędzie okazywałem się za słaby.

Na każdą rozmowę zakładałem garnitur, czyli coś co, jak dla mnie, jest dziś nie do pomyślenia. Pamiętam jeszcze, że szukałem ogłoszeń w drukowanych gazetach, że “wszędzie” wymagali “dwóch lat doświadczenia w programowaniu w języku Java”. Skąd miałem wziąć to doświadczenie?

Natomiast na IV roku mieliśmy praktyki i z razem z moim kolegą totalnie nie wiedzieliśmy co zrobić, z drugiej strony nie chcieliśmy przynosić zaświadczenia z lokalnego sklepu komputerowego. Poszliśmy do prowadzącego i on skierował nas do firmy Twelve Electric. Tam napisaliśmy symulator analizatora parametrów sieci – super sprawa i pierwszy większy projekt. Nie został nigdzie użyty, ale wtedy były nawet widoki na jakiś biznes z tego, jakoś się wszystko rozmyło.

Czego nauczyłeś się w NVT?

NVT było moją pierwszą firmą i zawsze będę jej wdzięczny za to, że dostałem swoją szansę. Pracowałem tam do obrony, przez 3 dni w tygodniu. Zarabiałem 2k PLN miesięcznie na umowę zlecenie czy o dzieło. Po obronie dostałem umowę o pracę, choć już wtedy powoli robiły się popularne umowy na DG. W NVT wartościowe było to, że miałem okazję pracować z produkcyjnymi systemami, od samego początku. Patrzeć w logi, rozwiązywać prawdziwe problemy. I to jest dla mnie do dziś ważne, uważam, że to core naszej pracy. Nie piękne greenfieldy, ale umazane produkcje.

Uważasz, że praca w tego typu firmie to idealne miejsce na start w branży IT?

To zależy od preferencji i kilku innych czynników. Dla mnie problemem było, że w NVT kręciliśmy się wokół tego samego. Mieliśmy swój produkt, korzystały z niego telekomy i wszystko było dobrze. Bałem się troszkę, że tam zgnuśnieje i poszedłem szukać firmy bardziej otwartej w sensie technologicznym. To był czas, kiedy zaczynały się springi, gity i inne fajerwerki. Dziś na start raczej bym szukał miejsca w większej firmie. Bo takie firmy mają swoje problemy procesowe i organizacyjne, ale też mają większe możliwości.

W kolejnej firmie pracowałeś nad jednym produktem. Jakie zalety, a jakie wady ma praca nad jednym produktem?

Wada to przychodzi mi na myśl jedna: ciągle to samo. I rozumiem, że można być tym zmęczonym. Z drugiej strony “Legacy means it runs on production” i to jest miejsce, gdzie jest życie, a więc zalet jest sporo. Przede wszystkim, ktoś z naszej pracy korzysta, a więc znalazła ona uznanie, co samo w sobie jest nobilitujące. Po drugie rozwiązuje się prawdziwe problemy, prawdziwych ludzi. I to na różnych poziomach np. bezpieczeństwa, UI, wydajnościowych.

Był czas, że praca nad produktem bardzo mnie nużyła i frustrowała. Bo np. wyszedł jakiś nowe feature w JDK, a my nie możemy podbić wersji, bo cokolwiek. Ale to są przejściowe trudności i w końcu taką wersję się podbić uda. W pracy nad produktem trzeba się pogodzić z tym, że niekoniecznie będziemy mieli najnowsze fajerwerki do zabawy. Z drugiej strony spotykamy się z masą nietrywialnych problemów i jakoś je trzeba rozwiązać, albo przestaną do nas płynąć pieniądze.

Wspomniałeś o procesie refactoringu, w którym brałeś udział. Czego uczy takie doświadczenie?

Stosunkowo “łatwo” napisać system od nowa, ale jest to bardzo kosztowne i nie daje gwarancji, że już wszystko będzie działać tak, jak trzeba. Po prostu istniejące błędy zostały zastąpione tymi, o których jeszcze nie wiemy. O wiele trudniej zmieniać system cały czas będący w ruchu. Pamiętam, że aplikacja, którą refaktorowaliśmy była napisana we Flexie. I było tam dosłownie milion warstw abstrakcji! Stanowiło to problem do tego stopnia, że trudno było nawigować po kodzie, a co dopiero coś w nim zmieniać, dodawać czy poprawiać. Aplikacja została znacznie uproszczona, zmienił się format przechowywanych lokalnie danych (z kompatybilnością wstecz), zostało dodane – modne wtedy – wstrzykiwanie zależności.

Taki refaktoring jest ciekawy z kilku powodów. Po pierwsze, można się uczyć na cudzych, popełnionych wcześniej błędach i unikać ich w przyszłości. Po drugie, rozwiązuje się naprawdę nietrywialne problemy. Po trzecie, wreszcie nie można nic popsuć, przecież system cały czas działa. Czasem trzeba naprawdę mocnej gimnastyki.

W rozmowie przed wywiadem powiedziałeś także, że bardzo ważna jest dla ciebie społeczność, otoczenie, które rozwija. To jedna z zalet organizowania czy współorganizowania konferencji, meetupów?

Tych zalet jest sporo więcej. Po pierwsze rodzą się ciekawe i sprawdzone w boju znajomości. Przy organizacji różnego rodzaju imprez pojawiają się nieoczekiwane przeszkody i ich pokonywanie bardzo scala grupę, a także uczy pokonywania przeciwności losu i radzenia sobie w sytuacji braków budżetowych.

Po drugie można się nauczyć organizacji, co w karierze zawodowej mocno się może przydać. Nie tylko wtedy, kiedy skończymy już przygodę z programowaniem i pójdziemy w góry na drabince kariery, ale także na tych niższych stanowiskach.

Po trzecie wreszcie, zyskuje się rozpoznawalność, która może zaowocować w przyszłości, np. przy poszukiwaniu pracy. Organizatorzy mają też ciekawe kontakty za granicą z innymi organizatorami, wymieniają się zaproszeniami czy wejściówkami na imprezy. Nie tylko można się uczyć, ale też zobaczyć trochę świata.

Raczej nie mówi się o tym w poradnikach dla początkujących chcących wejść do branży IT. Pracodawcy zwracają uwagę na to, czy jest się członkiem jakiejś społeczności?

Podchodzę do tego tak, że to, że ktoś nie udziela się w żadnej społeczności nie jest na minus. Dobrze jednak, gdy robi coś poza pracą, chociaż czyta książki z danej dziedziny czy śledzi jakieś blogi. Natomiast jeśli ktoś jest członkiem jakiejś społeczności, udziela się poza pracą to na pewno jest to dla mnie spora zaleta.

Przez ponad trzy lata pracowałeś w Polidei. Co przekonało Cię do zmiany pracy?

Polidea była SH nastawionym na pisanie aplikacji mobilnych na androida, iOSa, pamiętam nawet aplikację napisaną w J2ME. Byłem backendowcem i w tym chciałem się specjalizować. Pisanie backendów dla aplikacji mobilnych – przynajmniej tych, z którymi najwięcej pracowałem, bo jak wiadomo są aplikacje mobilne z całkiem konkretnymi systemami backendowymi – nie było dla mnie specjalnie rozwijające. Dlatego zmieniłem pracę. Co nie zmienia faktu, że w Polidei rozwinąłem się pod wieloma względami i sporo tej firmie zawdzięczam. Nie istniejącej już, bo została przejęta przez Snowflake’a.

Jesteś zwolennikiem częstej zmiany pracy? Według wielu dwa, trzy lata w jednej firmie to maksymalny czas. Drudzy uważają, że dopiero wtedy czuje się więź z produktem, nad którym pracuje się.

Nie jestem. W zasadzie nie miałbym nic przeciwko temu żeby całą karierę przepracować w jednej firmie, ale siłą rzeczy mi się to już nie uda. Chociaż 5,5 roku w SML uważam za całkiem przyzwoity wynik. Uważam, że 2-3 lata w jednym miejscu to tak w sam raz, ale to zależy od wielu czynników – na siłę też nie ma co tkwić w jednym miejscu, bo pozytywnego z tego nie wyniknie. Z drugiej strony żyjemy w złotych czasach IT i uważam, że trochę trzeba na tej fali płynąć.

Co sprawia, że czujesz, że nie stoisz w miejscu?

Otoczenie, bo ono mocno stymuluje do tego, żeby dotrzymywać kroku. Kolejna sprawa to ciekawość, lubię być na bieżąco, odkrywać nowe narzędzie czy wzorce, które mogę się potem przydać w codziennej pracy. Na koniec to jednak tak przyziemna rzecz jak to, że kto stoi w miejscu ten się cofa. Nie chcę wypaść z obiegu, z czegoś jednak muszę żyć.

Co Twoim zdaniem sprawia, że programista nie chce zmienić pracy? Odrzućmy kwestie finansowe, benefity i owocowe czwartki.

Naprawdę nie wiem na kogo te owocowe czwartki i inne tego typu benefity działają, bo na mnie w ogóle. Nie chciałbym zmieniać pracy, kiedy mam do zrobienia ciekawy projekt. Ważny jest również dla mnie aspekt socjalny oraz to jak mi się w tym danym miejscu, czyli taki mix kultury, organizacji i atmosfery. Po wielu rozmowach, które ostatnio odbyłem z różnymi osobami zmieniającymi pracę wychodzi na to, że ludzie nie zmieniają pracy tylko menedżerów. Czyli najczęściej wpływ na zmianę ma czynnik ludzki.

Maciej Opała. Senior Software Engineer w SoftwareMill. Programista lubiący wyściubiać nos poza swoje codzienne obowiązki, niegdyś organizator konferencji i warsztatów programistycznych. Wolnym czasie poświęca się sportowi, głównie wspinaniu.