Od QA do architekta w jednej firmie. Wywiad z Karolem Żukiem

geek.justjoin.it 1 rok temu

Swoją przygodę branżą IT zaczynał od testingu, po 1,5 roku zaczął pracować jako programista, by skończyć na stanowisku architekta — i to wszystko w jednej firmie, w której pracuje blisko 9 lat. Karol Żuk z Execon opowiada o tym, jakie są zalety i wady pracy w jednym środowisku przez wiele lat.

Twoją historię w IT można by opisać: „od kasjera do developera” Ale wiem, iż w IT przeszedłeś długą drogę i wielokrotnie zmieniałeś stanowiska. Opowiedz, proszę, jak wyglądały Twoje początki w branży.

Tak, w firmie Execon pracuję już prawie 9 lat, co nie oznacza, iż się „zasiedziałem”. Pamiętam moją rozmowę rekrutacyjną, którą przeprowadzał ze mną CEO Execon — Artur Lempkowski. Zapytał mnie, jakie mam doświadczenie zawodowe, więc wymieniałem swoje prace „studenckie” (m.in. praca jako kasjer w supermarkecie), co skomentował: „Widzę, iż jesteś pracowity”. Bardzo dobrze wspominam tę rozmowę, jako student drugiego roku WAT nie miałem jeszcze za wiele do zaoferowania branży IT, a on mimo wszystko dał mi szansę się wykazać.

Przyszedłem do firmy, kiedy zatrudnionych było lekko ponad 20 osób, głównie koledzy w niedoli studenckiej, ale miało to swoje plusy. Byliśmy bardzo zgrani i atmosfera była niepowtarzalna — wspólne wychodzenie po pracy, czy zamawianie kebaba w kuchni, która nie była w ówczesnym biurze zbyt obszerna, więc siedzieliśmy jeden obok drugiego, rozmawiając o tym, jak idą nam projekty, zarówno te firmowe, jak i uczelniane.

Dlaczego zacząłeś akurat od QA? Co zadecydowało — próg wejścia, zarobki, a może jeszcze coś innego?

Szczerze to się zwyczajnie bałem. Na uczelni nie przygotowują zbyt dobrze do tego, jak wyglądają realia pracy programistów. Dołączyłem do firmy dzięki koledze z akademika, który wtedy pracował w Execonie i dodał mi odwagi, aby pójść na rozmowę rekrutacyjną. QA pozwalało mi się oswoić z tym środowiskiem i zobaczyć od środka, jak wygląda taka praca. Uważam, iż to jest świetny początek, można również zrozumieć, dlaczego testerzy są tak uparci w szukaniu luki w naszym programie i docenić ich pracę, kiedy role się odwrócą.

W którym momencie i dlaczego uznałeś, iż pora iść dalej, z QA do programowania?

Pierwsze 1,5 roku pracowałem na stanowisku testera, co dawało mi bardzo dużo możliwości rozwoju. Siedzieliśmy w zespołach projektowych obok siebie, często mogłem pracować z kodem i uczyć się od programistów. Zacząłem automatyzować swoje prace, pisać skrypty testujące, co zostało zauważone przez kierowników i mogłem dołączyć do projektu na stanowisku programisty Java.

Jako programista miałem zawsze świetnych kierowników (przeważnie starszych programistów), którzy chętnie dzielili się swoją wiedzą, jednak darzyli mnie sporym zaufaniem i pozwalali mi pracować moim tempem, chyba iż prosiłem o pomoc. Przez 6,5 roku na tym stanowisku miałem okazję pracować na kilkudziesięciu projektach, w różnych zespołach, zarówno wewnętrznych, jak i u klienta i tym samym poszerzać swoją wiedzę.

Wszystko, o czym za mało mówi się w branży IT.

Prosto na Twoją skrzynkę.

Oświadczam, że zapoznałem/am się z Polityką Prywatności oraz akceptuję jej treść.
Leave this field empty if you’re human:

Teraz jesteś architektem — co zmotywowało Cię do kolejnej zmiany?

Jako programista na początku nie wyobrażałem sobie, iż architektura może być przyjemna. Pamiętam, iż nie lubiłem pisać dokumentacji do kodu, który tworzyłem i zawsze odwlekałem to na ostatnią chwilę. Po kilku latach programowania zacząłem jednak dostawać trudniejsze zadania, które uwzględniały przygotowanie architektury do potrzeb klienta, co na początku też szło mi opornie.

Taki przełom w moim rozumieniu pracy architekta nastąpił na projekcie u klienta, gdzie musiałem samodzielnie rozwijać system, z którego korzysta większość jego systemów wewnętrznych. Pamiętam, iż irytowało mnie ciągłe przechodzenie ludzi z pytaniami, jak korzystać z mojego kodu, czy jak można go dostosować do nowych potrzeb. Zacząłem bardzo skupiać się na dokumentowaniu architektury i projektowaniu tego w taki sposób, aby zabezpieczyć się na potencjalny rozwój i potrzeby. Bardzo polubiłem poznawanie szerszego obrazu w kontekście moich rozwiązań i rysowanie diagramów w taki sposób, aby choćby ludzie nietechniczni mogli je bez problemu zrozumieć.

W trakcie rozwijania swoich umiejętności architektonicznych stwierdziłem, iż taki sposób pracy najbardziej mi odpowiada, chociaż przez cały czas bardzo lubię programować i staram się jakoś zaangażować i ten aspekt pracy, wspierając prace projektowe, w których uczestniczę.

Wszystkie te zmiany odbyły się w jednej firmie — Execon, w której pracujesz do dziś. Jak reagowali Twoi przełożeni na chęci zmian?

Zawsze miałem możliwość samodzielnego wyboru ścieżki rozwoju. Execon często zachęcał mnie do zmian, gdy tylko przełożeni zauważali, iż chciałbym podążać w nowym kierunku. Execon choćby często popychał mnie do zmian, o ile przełożeni zauważyli, iż mam chęć i możliwości, aby te zmiany wprowadzać.

Idź do oryginalnego materiału