Co dają studia, gdy już pracujesz w IT?

Pracowałeś już podczas studiów. Jak udało Ci się łączyć obowiązki zawodowe ze studiowaniem?

*Konrad Kolasa: Pracę w IT rozpocząłem jeszcze przed studiami. Po technikum zrobiłem sobie przerwę i wyjechałem na rok do Holandii, gdzie pracowałem fizycznie. Po powrocie przez około dwa–trzy miesiące szukałem zatrudnienia, aż dostałem pierwszą pracę jako junior frontend developer w Ideo. Dopiero wtedy zdecydowałem się rozpocząć studia zaoczne. Początek przypadł na pandemię, więc zajęcia odbywały się zdalnie.

Najtrudniejszy był brak czasu. Po ośmiu godzinach pracy trzeba było jeszcze wykonywać zadania, przygotowywać projekty i przeglądać materiały na studia. Miałem poczucie, że ciągle jest coś do zrobienia, a czas na własne życie ucieka mi przez palce. To było męczące przede wszystkim psychicznie.

Pomogły mi planowanie i systematyczność. Zjazdy odbywały się zazwyczaj co dwa tygodnie, więc dużą część obowiązków wykonywałem w weekendy bez zajęć. Starałem się rozkładać pracę w czasie, żeby nie zostawiać wszystkiego na ostatnią chwilę. Nie zawsze było łatwo, ale taki rytm pozwalał mi to pogodzić.

Co dały Ci studia, czego nie dała Ci praca?

K. K.: Przede wszystkim szersze spojrzenie na informatykę, wykraczające poza obszar, którym zajmowałem się zawodowo. Dobrym przykładem były zajęcia ze sztucznej inteligencji. W pracy korzystałem z gotowych rozwiązań, a na studiach mogłem poznać podstawy mechanizmów, które za nimi stoją.

Z perspektywy czasu bardzo doceniam też inżynierię oprogramowania: projektowanie systemów, modelowanie procesów, UML, BPMN czy łączenie wymagań biznesowych z rozwiązaniami technicznymi. Niektóre z tych zagadnień wydawały mi się wtedy trochę nudne. Dopiero kolejne lata pracy pokazały mi ich znaczenie.

Przy obecnych możliwościach narzędzi AI coraz większą wartość widzę w rozumieniu problemu, planowaniu rozwiązania i podejmowaniu świadomych decyzji projektowych. Studia dały mi uporządkowane podstawy w tych obszarach. Oczywiście wymagały one dalszej, samodzielnej nauki, ale miałem już punkt wyjścia.

Czy pamiętasz zadanie zawodowe, przy którym wykorzystałeś wiedzę z konkretnego przedmiotu? Co to było?

K. K.:  Dostałem odpowiedzialność za projekt rozwiązania czatowego: przygotowanie backendu w NestJS i połączenie go z frontendem. Musiałem zaprojektować strukturę bazy danych, podział na tabele i relacje między nimi, a także strukturę backendu, serwisy oraz sposób przesyłania danych.

Przydała mi się wtedy wiedza z baz danych i inżynierii oprogramowania. Wykorzystywałem diagramy ERD do przedstawienia struktury bazy oraz diagramy pokazujące przepływ danych. Dzięki nim mogłem zaprezentować pomysł zespołowi i skonsultować go z bardziej doświadczonymi programistami backendowymi. Pomagały zarówno uporządkować własne myślenie, jak i wspólnie ocenić rozwiązanie przed implementacją.

Który projekt na studiach najbardziej przypominał rzeczywiste wyzwanie programistyczne?

K. K.:  Pamiętam dwa takie projekty. Pierwszy realizowałem na przedmiocie związanym z zarządzaniem i zbieraniem danych. Dostaliśmy dużą swobodę wyboru rozwiązania: mogliśmy korzystać z zewnętrznego API albo stworzyć własne. Wybrałem przygotowanie backendu w NestJS, ponieważ zawodowo zajmowałem się wtedy frontendem i chciałem rozwinąć się w nowym obszarze. Bardzo ceniłem tę możliwość samodzielnego wyboru kierunku projektu.

Drugim przykładem była moja praca inżynierska. Aplikacja wspierająca organizację spotkań online. Użytkownicy mogli tworzyć wydarzenia i się na nie zapisywać. W momencie rozpoczęcia wydarzenia powstawał pokój z czatem działającym w czasie rzeczywistym, dostępny dla zapisanych uczestników.

Prelegent mógł później wykorzystać model AI do wyodrębnienia z rozmowy pytań związanych z tematyką spotkania, które pozostały bez odpowiedzi na czacie. Dzięki temu mógł do nich wrócić i odpowiedzieć uczestnikom, na przykład mailowo. Było to rzeczywiste wyzwanie, bo trzeba było połączyć kilka technologii i funkcjonalności w spójną aplikację rozwiązującą konkretny problem.

Czy zdarzyło Ci się dzięki studiom zrozumieć, dlaczego jakieś rozwiązanie działa, a nie tylko jak je zastosować?

K. K.: Tak. Przede wszystkim w przypadku sztucznej inteligencji. Wcześniej potrafiłem korzystać z modeli w pracy i własnych projektach, ale ich działanie było dla mnie w dużej mierze „czarną skrzynką”. Znałem sposób użycia narzędzia, natomiast znacznie mniej wiedziałem o mechanizmach stojących za jego wynikami.

Zajęcia pomogły mi zrozumieć podstawy działania tych algorytmów. Oczywiście nie oznacza to, że potrafię wyjaśnić każdą odpowiedź współczesnego modelu. Mam jednak lepsze podstawy do rozmowy o tym, jak takie rozwiązania działają, zamiast opierać swoją wiedzę wyłącznie na doświadczeniu z ich używania.

Jaki feedback od wykładowcy zmienił Twój sposób myślenia lub pracy?

K. K.: Nie pamiętam jednej konkretnej uwagi, która całkowicie zmieniłaby moje podejście. Większy wpływ miały regularne wymagania wykładowców, szczególnie dotyczące dokładności i formy oddawanych sprawozdań.

Dzięki temu zacząłem bardziej dbać o dokumentację. Przykładam większą wagę do jej struktury, czytelności i sposobu prezentacji informacji. Zależy mi, żeby była zrozumiała również dla osoby, która nie uczestniczyła bezpośrednio w tworzeniu rozwiązania. To nawyk, który wykorzystuję w pracy.

Co z uczelni przydało Ci się we współpracy z zespołem albo klientem?

K. K.: Dużo dawały projekty grupowe. Sami dobieraliśmy zespoły, dzieliliśmy zadania i ustalaliśmy zakresy odpowiedzialności, często według posiadanych kompetencji. Jeżeli jedna osoba przygotowywała backend, a druga frontend, musieliśmy uzgadniać sposób ich połączenia, informować się o postępach i pozostawać w kontakcie. Pod tym względem przypominało to współpracę w zespole komercyjnym.

Ważne były też prezentacje i obrony projektów. Nie wystarczyło rozumieć własnego fragmentu implementacji. Trzeba było wymienić się wiedzą, żeby każdy potrafił wyjaśnić również pozostałe części rozwiązania. Uczyło to odpowiedzialności za wspólny rezultat i przekazywania wiedzy innym.

Czego musiałeś nauczyć się samodzielnie, a do czego studia dały Ci dobre podstawy?

K. K.: Najwięcej samodzielnej pracy wymagało samo programowanie: nauka języków, frameworków, wzorców projektowych i dobrych praktyk. Sprawność w implementacji budowałem przede wszystkim przez pisanie kodu, realizowanie własnych projektów i rozwiązywanie problemów w pracy.

Uważam, że tej praktyki nie da się zastąpić, niezależnie od jakości uczelni. Czas na zajęciach jest ograniczony, a studenci mają różne zainteresowania i cele zawodowe. Każdy musi więc samodzielnie pogłębiać wiedzę w wybranym kierunku.

Studia dały mi natomiast dobre podstawy inżynierii oprogramowania, tworzenia dokumentacji i porządkowania pracy. Pomagały też rozwijać rzetelność oraz nawyk pilnowania terminów. Te umiejętności wykorzystuję niezależnie od technologii, w której aktualnie pracuję.

Co zmieniłbyś w programie, patrząc z perspektywy obecnej pracy?

K. K.:  Jeszcze mocniej postawiłbym na inżynierię oprogramowania i umiejętności współpracy: rozumienie potrzeb biznesowych, projektowanie systemów, prezentowanie pomysłów oraz argumentowanie decyzji technicznych. W mojej ocenie właśnie te kompetencje mają coraz większe znaczenie, szczególnie na stanowiskach wymagających większego doświadczenia.

Chętnie widziałbym więcej rozbudowanych projektów zespołowych, w których trzeba przejść od rozpoznania problemu przez projekt rozwiązania aż po jego realizację i obronę podjętych decyzji. Warto byłoby też szerzej pokazywać takie podejścia jak Domain-Driven Design, EventStorming czy projektowanie komunikacji opartej na zdarzeniach w połączeniu z rozmową o potrzebach biznesu.

Uczyłbym również świadomego korzystania z AI. Ogólny zakaz używania tych narzędzi uważam za niewłaściwy kierunek. Lepiej wymagać, żeby student rozumiał przygotowane rozwiązanie, potrafił je uzasadnić i zweryfikować. Przydałoby się więcej praktyki w prowadzeniu researchu z pomocą AI, ocenie wyników, tworzeniu agentów oraz automatyzowaniu powtarzalnych zadań. Rozwinąłbym też zajęcia dotyczące budowania i trenowania własnych modeli.

Duży nacisk położyłbym na bezpieczeństwo, niezależnie od specjalizacji. W pracy regularnie spotykamy się z informacjami o podatnościach i koniecznością aktualizowania zależności. Rozumienie takich zagrożeń powinno być częścią przygotowania każdego informatyka.

Podstawy techniczne nadal są niezbędne. Uważam jednak, że nauka konkretnego języka czy frameworka powinna służyć szerszemu celowi: umiejętności rozwiązywania problemów i budowania dobrze przemyślanych systemów. Narzędzia się zmieniają, a te umiejętności pozwalają odnaleźć się w kolejnych technologiach.

*Konrad Kolasa to absolwent WSIiZ na kierunku  Informatyka (studia inżynierskie), specjalność: aplikacje internetowe. Obenie student studiów magisterskich na kierunku Informatyka. Zawodowo realizuje się jako inżynier oprogramowania fullstack.