Medycyna, chemia, prawo, a na końcu informatyka – droga Mateusza Charewicza do IT przypomina poszukiwanie właściwego miejsca na mapie zawodowej. Z każdej próby wynosił jednak coś cennego: z medycyny świadomość kosztów prestiżu, z chemii realizm wobec perspektyw, z prawa precyzję myślenia i umiejętność argumentacji. Dziś jako Software Engineer w HID pracuje przy systemach do produkcji
kart ID – projektach, gdzie kod spotyka się ze sprzętem, a debugowanie wymaga wyjścia poza ekran. W rozmowie opowiada, dlaczego zmieniał kierunki studiów, co go fascynowało w programowaniu jeszcze przed pierwszą pracą w IT i co znalazł w tej branży, czego zabrakło mu w prawie. To historia o tym, że pozornie chaotyczna ścieżka może prowadzić do miejsca, w którym wszystko zaczyna do siebie pasować.
Chciałeś iść na studia medyczne, ale zdecydowałeś się zmienić kierunek. Co przyczyniło się do tej decyzji?
Od początku liceum zakładałem, że pójdę na medycynę. W pewnym sensie był to mój „domyślny” plan – spójny z tym, jak wtedy wyobrażałem sobie stabilną i sensowną ścieżkę zawodową. Z czasem zacząłem jednak dostrzegać, że takie decyzje podejmujemy zdecydowanie za wcześnie. Już w wieku 14–15 lat wybiera się profil klasy, a później konsekwentnie podporządkowuje mu kolejne kroki. W teorii to tylko wybór przedmiotów, a w praktyce często decyzja, która mocno zawęża dalsze możliwości.
Równolegle bardziej realnie zacząłem oceniać, jak wygląda codzienność w tym zawodzie: odpowiedzialność, presja, dyżury, obciążenie psychiczne i to, że praca „nie kończy się” wraz z wyjściem ze szpitala czy kliniki. Na etapie nastoletnim łatwo widzieć w medycynie przede wszystkim prestiż i misję; dopiero później zaczyna się rozumieć, że może to nieść za sobą koszty – czasowe, emocjonalne i zdrowotne.
W moim przypadku kluczowe było więc nie jedno konkretne wydarzenie, tylko narastająca refleksja: czy wybieram tę drogę, dlatego że naprawdę tego chcę, czy dlatego, że to scenariusz, którego spełnienie kiedyś sobie założyłem. Im częściej zadawałem sobie to pytanie, tym bardziej czułem, że potrzebuję przestrzeni do sprawdzenia siebie w innych obszarach. Ostatecznie uznałem, że lepiej zmienić kierunek wcześniej i świadomie poszukać ścieżki, w której będę się rozwijał z przekonaniem, a nie z rozpędu.
Ukończyłeś prawo na UJ, ale nie zostałeś prawnikiem. Dlaczego?
To prawda – ukończyłem prawo, ale ostatecznie nie związałem z nim kariery. Po pierwszej nieudanej próbie dostania się na medycynę zacząłem studia na wydziale chemii. Traktowałem to jako plan przejściowy: chciałem poprawić wynik z chemii na maturze i jednocześnie zobaczyć, jak wygląda praca akademicka „od środka”. Dość szybko okazało się jednak, że mimo interesującego programu studiów, perspektywy zawodowe po ich ukończeniu nie były szczególnie obiecujące, co potwierdzali starsi absolwenci. To ostatecznie skłoniło mnie do rezygnacji z tego kierunku pod koniec pierwszego roku.
Prawo pojawiło się jako świadomy zwrot w stronę czegoś bardziej humanistycznego. Interesowało mnie myślenie analityczne, argumentacja, porządkowanie chaosu w reguły – i w tym sensie prawo bardzo do mnie pasowało.
W trakcie studiów zacząłem pracę jako stażysta w dziale prawnym firmy farmaceutycznej. To doświadczenie było przełomowe, bo pozwoliło mi zobaczyć, jak ta praca wygląda na co dzień. Z jednej strony – ciekawe tematy, duża dbałość o szczegóły, realny wpływ na procesy. Z drugiej – z czasem coraz wyraźniej odczuwałem powtarzalność zadań i to, że wiele działań ma charakter mocno proceduralny. Uświadomiłem sobie wtedy, że mogę być w tym dobry, ale niekoniecznie będę miał z tego długoterminową satysfakcję. To był moment, w którym zacząłem szukać kierunku, który da mi więcej dynamiki, „sprawczości” i poczucia budowania czegoś namacalnego.
Po chemii i prawie przyszedł czas na informatykę stosowaną. Trzy różne kierunki studiów to niecodzienna droga. Jak wyglądał proces podejmowania każdej z tych decyzji? Co było impulsem do kolejnych zmian?
Patrząc z boku, może to wyglądać jak seria gwałtownych zwrotów, ale dla mnie był to dość logiczny proces: konfrontowanie wyobrażeń z rzeczywistością i coraz lepsze dopasowywanie ścieżki do tego, co mnie realnie napędza. Każdy etap dał mi coś ważnego – nawet jeśli finalnie nie został moją „docelową” drogą.
Chemia była próbą utrzymania kursu na medycynę i jednocześnie sprawdzenia, czy ten typ nauki daje mi satysfakcję. Prawo było świadomym skrętem w stronę analizy, języka i argumentacji. Informatyka pojawiła się wtedy, gdy zacząłem szukać obszaru, w którym połączę intelektualne wyzwania z możliwością tworzenia rozwiązań i szybkiego widzenia efektów pracy.
Ważny był też czynnik rynkowy: obserwowałem, jak szybko rozwija się branża IT, jak wiele daje możliwości specjalizacji i jak mocno premiuje samodzielność oraz ciągłe uczenie się. Rozmowy z osobami z tej branży utwierdziły mnie w tym, że to środowisko, w którym mogę rosnąć – a jednocześnie mieć poczucie sprawczości. Finalnie informatykę wybrałem nie dlatego, że „tak wypada”, tylko dlatego, że to był pierwszy kierunek, przy którym czułem: to mnie naprawdę ciekawi na dłużej, a nie tylko „brzmi rozsądnie”.
Co ciekawiło Cię w programowaniu? Pytam o czas zanim znalazłeś pierwszą pracę w IT.
Na początku najbardziej przyciągała mnie otoczka tego zawodu – ten pewien „mityczny” obraz programisty jako osoby, która potrafi zamieniać pomysły w działające rzeczy. W Internecie często opisuje się programowanie jak coś dostępnego tylko dla wybranych: że trzeba myśleć w określony sposób, mieć specyficzne predyspozycje, a do tego ogromną determinację. To budowało ciekawość i chęć sprawdzenia, czy w ogóle się do tego nadaję.
Pierwszy kontakt z programowaniem miałem jeszcze w podstawówce na dodatkowych zajęciach, a później wróciło to na studiach – m.in. przy podstawach Pythona. I wtedy wydarzyło się coś ważnego: zobaczyłem, że uczenie się tego przychodziło mi zaskakująco naturalnie. Nie chodzi o to, że „wszystko rozumiałem od razu”, ale o to, że sam proces rozwiązywania problemów sprawiał mi frajdę. Było w tym coś bardzo konkretnego: piszesz kod, poprawiasz błąd, zmieniasz jedną rzecz – i widzisz efekt. To poczucie szybkiej informacji zwrotnej mocno mnie wciągnęło.
Z czasem zacząłem robić własne projekty, głównie webowe, bo dawały najszybszą możliwość zbudowania czegoś kompletnego: od pomysłu, przez implementację, po działającą aplikację. Najbardziej kręciła mnie kombinacja logiki i kreatywności: z jednej strony trzeba myśleć precyzyjnie, a z drugiej – projektować rozwiązania, wybierać podejście, usprawniać. To był pierwszy obszar, w którym nauka sama w sobie była dla mnie nagrodą.
Zawsze interesuje mnie zderzenie wyobrażeń z rzeczywistością. Co zaskoczyło Cię, gdy znalazłeś pracę w IT?
Pozytywnie zaskoczyła mnie sprawczość – to, że nawet jako stażysta mogłem realnie wpływać na produkt. Wcześniej zakładałem, że decyzje zapadają „gdzieś wyżej”, a młodsze osoby jedynie wykonują polecenia. Tymczasem okazało się, że dobre zespoły naprawdę słuchają argumentów: jeśli potrafisz uzasadnić zmianę, pokażesz ryzyko albo korzyść, to możesz mieć realny wpływ niezależnie od stanowiska.
Drugie zaskoczenie dotyczyło tego, jak wygląda znajomość systemu w dużych produktach. Miałem wyobrażenie, że programista zna cały kod i całą architekturę. W praktyce, przy systemach rozwijanych latami, nikt nie ma „w głowie” wszystkiego. Często poznajesz dany fragment dopiero wtedy, gdy coś się zepsuje albo gdy dostajesz zadanie w konkretnym module. To zmieniło moje myślenie: ważniejsze od pamięci do kodu jest umiejętne poruszanie się po projektach, logach, dokumentacji i historii zmian.
Trzecia rzecz to skala uczenia się. W pracy bardzo często zanim cokolwiek poprawisz, musisz doczytać: jak działa protokół, jaka jest specyfika biblioteki, jakie są ograniczenia danego rozwiązania, jak wygląda zachowanie u klienta. I tu zobaczyłem duże podobieństwo do prawa: w obu dziedzinach kluczową umiejętnością jest wyszukiwanie informacji, rozumienie kontekstu i budowanie poprawnego rozumowania na podstawie źródeł – czy to dokumentacji i ticketów, czy komentarzy i orzecznictwa. To było dla mnie zaskakująco znajome, tylko w innym „języku”.
Zaczynałeś od stażu. Opowiedz o swoich wrażeniach. Nie zawsze staże wspomina się dobrze, ale u Ciebie jest chyba inaczej.
Staż był dla mnie ważnym etapem, bo wynikał też z wymogów uczelni – żeby zaliczyć drugi rok informatyki, musiałem odbyć określoną liczbę godzin praktyk. To oznaczało, że musiałem zakończyć wcześniejszy staż w dziale prawnym i wejść w świat tworzenia oprogramowania. Miałem już wtedy kilka własnych projektów, głównie webowych, ale brakowało mi doświadczenia w pracy z dużym produktem rozwijanym przez lata.
Na starcie stresowała mnie klasyczna rzecz: poczucie, że „nie umiem wystarczająco dużo”. Wiedziałem, że akademickie zadania i projekty robione samodzielnie to jedno, a praca w zespole, w istniejącym systemie, z wymaganiami jakościowymi i odpowiedzialnością – to zupełnie inny poziom. Obawiałem się, że będę zbyt wolny, zbyt mało samodzielny, że będę blokował innych.
I tu pojawiło się największe pozytywne zaskoczenie: trafiłem do zespołu, który bardzo jasno pokazał mi, na czym polega rola stażysty. Nie oczekuje się, że wiesz wszystko – oczekuje się, że masz otwartą głowę, umiesz zadawać pytania i chcesz się uczyć. Dostałem zadania, które były rozwojowe i odpowiedzialne, ale jednocześnie miałem wsparcie: code review, konsultacje, normalną przestrzeń na popełnianie błędów. To połączenie wysokich oczekiwań co do jakości z bezpiecznym środowiskiem uczenia się sprawiło, że rozwijałem się szybko, ale bez poczucia, że jestem „wrzucony na głęboką wodę” bez koła ratunkowego.
Od dwóch lat pracujesz w zespole tworzącym system do produkcji kart ID. Co z Twojej perspektywy jest największym wyzwaniem w tego typu projekcie? Co sprawia, że to nie jest “zwykły” projekt IT?
Po stażu zmieniłem projekt i zacząłem pracować nad systemem do wydruku kart ID. To był duży skok, bo projekt został przejęty po zespole ze Stanów Zjednoczonych, a największym wyzwaniem na start było bardzo szybkie wejście w ogromny zasób wiedzy – tak, żeby móc realnie pomagać w problemach zgłaszanych przez klientów. W takich produktach nie wystarczy „rozumieć kod”; trzeba rozumieć cały ekosystem rozwijany przez lata.
To nie jest „zwykły” projekt IT, bo nie mówimy o jednej aplikacji. To system składający się z wielu elementów: sama drukarka, aplikacja sterująca, sterownik, SDK – a do tego różne konfiguracje u klientów, środowiska, wersje, zależności. W pewnym momencie odkrywasz, że błąd może wynikać z kodu, ale równie dobrze z ustawień systemu, komunikacji, kabli, specyfiki danego stanowiska, a czasem nawet z tego, jak urządzenie jest fizycznie użytkowane.
Dla mnie nowością była też praca blisko sprzętu. Wcześniej moje projekty były czysto software’owe. Tutaj trzeba umieć „dotknąć” urządzenia, testować scenariusze na żywo, czasem spędzić godziny na odtworzeniu problemu, który w logach wygląda niewinnie, a w rzeczywistości wynika z sekwencji zdarzeń i reakcji maszyny. Paradoksalnie to właśnie czyni tę pracę ciekawą: jednego dnia działasz przy froncie w WPF, kolejnego przy sterowniku w C++, innego dnia analizujesz zachowanie urządzenia i wpływ konkretnego fragmentu kodu na mechanikę. Ta różnorodność sprawia, że trudno tu o rutynę.
Czy do takich projektów wymagana jest konkretna specjalizacja? Czy trzeba mieć doświadczenie w hardware, aby pracować przy systemach produkcji kart ID?
Nie trzeba wchodzić z gotową, „hardware’ową” specjalizacją, ale trzeba mieć odpowiednie podejście: nie bać się pracy na styku software’u i sprzętu oraz zaakceptować, że czasem debugowanie wymaga wyjścia poza IDE. W praktyce bardzo ważna jest gotowość do testowania, cierpliwość w odtwarzaniu problemów i umiejętność myślenia systemowego: jak zachowanie jednego komponentu wpływa na całość.
Z doświadczenia wiem też, że w tak szerokim projekcie kluczowe jest dobre priorytetyzowanie i zarządzanie uwagą. Łatwo wpaść w pułapkę: „sprawdzę jeszcze to”, „doczytam jeszcze tamto” i nagle mijają godziny. Trzeba umieć rozdzielić, kiedy warto kopać głębiej, a kiedy lepiej szybko zawęzić obszar, zebrać dane i eskalować albo poprosić o wsparcie osoby, która zna dany moduł lepiej.
Jeśli chodzi o pracę ze sprzętem: często nie potrzebujesz encyklopedycznej wiedzy, tylko umiejętności zadawania właściwych pytań i weryfikowania hipotez. Bywają dni, kiedy więcej czasu spędza się przy realnej maszynie niż przy samym kodzie – i to jest akurat plus, bo daje pełniejsze zrozumienie produktu i szybciej buduje doświadczenie.
Ukończone studia prawnicze to solidna przewaga w IT, szczególnie w projektach wymagających zgodności z regulacjami. Czy ta wiedza przydaje Ci się w projekcie?
Wprost: raczej nie. Do tej pory nie miałem sytuacji, w której musiałbym wykorzystywać konkretną wiedzę prawniczą w mojej codziennej pracy. Wynika to też z tego, że w dużej organizacji kwestie stricte prawne są odpowiednio zaopiekowane przez wyspecjalizowane zespoły, a nie „doklejane” programistom.
Natomiast pośrednio te studia dały mi dużo: sposób myślenia, precyzję w formułowaniu argumentów, porządkowanie informacji, umiejętność pisania jasno i logicznie, a także nawyk pracy na źródłach. W IT to się przekłada na bardzo praktyczne rzeczy: lepsze opisy problemów, sensowne uzasadnienia zmian, dokładniejsze analizowanie ryzyka i skutków ubocznych.
Docelowo chciałbym jednak kiedyś połączyć te dwa światy bardziej bezpośrednio – na przykład w obszarze licencji, własności intelektualnej, compliance albo produktów, gdzie prawo i technologia realnie się przenikają. Mam poczucie, że to może być ciekawa nisza, w której takie połączenie kompetencji daje przewagę.
Zmieniałeś kierunki studiów, a tym samym cele, które chcesz osiągnąć. Dziś, z perspektywy czasu, postąpiłbyś inaczej i od razu zaczął od studiowania informatyki?
Nie – nawet z perspektywy czasu nie zmieniłbym tej drogi. Oczywiście, gdybym zaczął od informatyki to pewnie szybciej rozpoznałbym, że jest ona moim docelowym kierunkiem. Ale mam poczucie, że wcześniejsze wybory nie były „stracone” – one mnie ukształtowały i dały umiejętności, które wykorzystuję na co dzień.
Prawo nauczyło mnie komunikacji, argumentowania, pracy z niejednoznacznością i budowania logicznych wniosków. To są kompetencje miękkie, które w IT są coraz ważniejsze: praca w zespole, jasne uzgadnianie wymagań, tłumaczenie technicznych kwestii, dyskusje nad rozwojem produktu, umiejętność obrony rozwiązania. Do tego dochodzi dyscyplina w uczeniu się i cierpliwość do złożonych problemów – a to przydaje się niezależnie od technologii.
Najważniejsze jest dla mnie to, że ta ścieżka była uczciwym procesem szukania miejsca, w którym łączą się: zainteresowanie, satysfakcja z codziennej pracy i perspektywa rozwoju. I finalnie właśnie w IT znalazłem obszar, który spełnia te warunki.
Przeszedłeś długą drogę przez różne dziedziny, zanim trafiłeś do IT. Co sprawia, że czujesz, że to “twoje miejsce”? Co tu znalazłeś, czego nie było w prawie?
To, co sprawia, że czuję się w IT „na swoim miejscu”, to przede wszystkim połączenie różnorodności, sprawczości i ciągłego rozwoju. W moim obecnym projekcie system jest na tyle szeroki, że kiedy jedna część zaczyna mnie nużyć, mogę przenieść uwagę na inny obszar i tam znaleźć coś do poprawy albo usprawnienia. Ta zmienność tematów i technologii sprawia, że praca rzadko wpada w rutynę, a ja mam poczucie, że cały czas uczę się czegoś nowego, ale w praktycznym kontekście.
W prawie znacznie częściej miałem do czynienia z monotonią i długim horyzontem spraw. Wiele tematów ciągnęło się miesiącami, część obowiązków była powtarzalna i mocno proceduralna – chociażby przygotowywanie podobnych pism czy powtarzających się wezwań do zapłaty. To oczywiście jest potrzebne i ważne, ale dla mnie na dłuższą metę było mało satysfakcjonujące.
Drugą rzeczą jest charakter rozwoju. W IT uczenie się jest w pewnym sensie wpisane w zawód, ale jednocześnie daje dużą swobodę: mogę wybierać, w którą stronę chcę iść, jakie technologie poznawać, w czym się specjalizować. W prawie też trzeba się stale dokształcać, ale często jest to bardziej narzucone – zmiany przepisów przychodzą „z zewnątrz” i trzeba się do nich dostosować, niezależnie od tego, czy dany kierunek jest dla nas interesujący.
Najważniejsza różnica to jednak możliwość tworzenia. W IT buduję rozwiązania, które zaczynają działać, realnie wpływają na produkt i użytkowników, a efekty mojej pracy są namacalne. To poczucie, że coś projektuję, wdrażam i widzę rezultat, jest dla mnie kluczowe – i właśnie tego elementu najbardziej brakowało mi w prawie.
Mateusz Charewicz – Software Engineer w HID. Zainteresowania: polityka i prawo karne. W IT od 2022 roku.
