Czas czytania: 4 min
Jak wygląda dzień z życia developera w Polsce pracującego w ITDS? Każda nowa praca wiąże się z krzywą uczenia. Nowy kod, nowy zespół, nowy rytm. To, co robi różnicę, to ludzie i środowisko, które otacza Cię w trakcie wdrożenia.
Tak wygląda pierwszy miesiąc full-stack developera, który dołącza do ITDS.
Pierwszy tydzień: orientacja bez chaosu
Pierwsze dni w ITDS są ustrukturyzowane, ale nie sztywno zaprogramowane. Dostajesz dostęp do narzędzi, poznajesz ludzi i zaczynasz rozumieć, jak naprawdę przebiega praca – nie przez slajdy, ale przez rozmowy.
Konfiguracja techniczna jest prosta: laptop skonfigurowany, dostępy nadane, repozytoria sklonowane. Pod koniec drugiego dnia większość developerów przegląda już prawdziwy kod. Nie kontrybuuje jeszcze – ale czyta, rozumie, zadaje pytania. Oczekiwanie nie jest takie, żebyś od pierwszego dnia działał pełną parą. Chodzi o to, żebyś zaczął budować kontekst.
To, co niezmiennie wyróżnia te pierwsze dni, to ludzie. Jeden z developerów, który niedawno dołączył, ujął to wprost:
“Pierwszy miesiąc pracy był doskonały – świetni ludzie wokół, zapewniający pomoc na najwyższym poziomie. Bardzo dobre doświadczenie.”
To nie jest przypadek. ITDS celowo organizuje onboarding tak, żeby nowi konsultanci mieli jasne punkty kontaktu – zarówno w wewnętrznym zespole, jak i po stronie klienta. Nie zostajesz sam z pytaniami.
Typowy poranek: stand-up z międzynarodowym zespołem
Od drugiego tygodnia dzień nabiera kształtu.
Zazwyczaj zaczyna się od stand-upu. W zależności od projektu może to być spotkanie z zespołem z Holandii, Belgii lub Niemiec – co oznacza, że rozmowa odbywa się po angielsku. Dla większości developerów dołączających do ITDS to jedno z pierwszych autentycznych zaskoczeń: ekspozycja na środowisko międzynarodowe jest natychmiastowa, a nie czymś, co buduje się stopniowo przez miesiące.
Sam stand-up ma standardowy format – co robiłeś wczoraj, co robisz dzisiaj, co Cię blokuje. Ale charakter rozmowy różni się od pracy w czysto lokalnym zespole. Jesteś zsynchronizowany z ludźmi w różnych strefach czasowych, pracującymi na systemach działających na wielu rynkach.
Po stand-upie: głęboka praca. To ta część dnia, którą większość developerów w ITDS opisuje jako jedną z prawdziwych zalet tej roli. Projekty to nie środowiska demo ani narzędzia wewnętrzne – to działające systemy, często w obszarze finansów, retail lub logistyki, gdzie kod który piszesz ma bezpośredni wpływ na doświadczenie użytkowników klienta. React na froncie, Java lub .NET na backendzie, wdrożone na AWS lub Azure, zarządzane przez pipeline’y CI/CD uruchamiane przy każdym pull requeście.
Praca jest wystarczająco złożona, żeby być interesującą. Narzędzia są nowoczesne. A ponieważ jesteś zanurzony w zespole klienta, a nie działasz obok niego – rozumiesz, dlaczego decyzje są podejmowane, a nie tylko jakie decyzje zostały podjęte.
Popołudnie: feature, bug, rozmowa
Popołudnia w ITDS są z reguły mniej ustrukturyzowane niż poranki – i jest to celowe.
Konsultanci w ITDS mają poziom autonomii, który nie zawsze występuje w tradycyjnych modelach zatrudnienia. Oczekuje się, że samodzielnie zarządzasz swoim czasem w ramach sprintu, proaktywnie komunikujesz blokady i podejmujesz decyzje techniczne w swoim zakresie bez konieczności czekania na akceptację.
Dla developerów przyzwyczajonych do otrzymywania gotowych zadań może to wymagać chwili adaptacji. Dla tych, którzy cenią sobie ownership zamiast wykonywania poleceń – ten model sprawdza się od razu.
To nie jest środowisko całkowicie bez tarcia – praca z klientami z różnych krajów i na różnych systemach oznacza, że zdarzają się momenty niejednoznaczności.
Typowe popołudnie może obejmować dokończenie feature’a rozpoczętego rano, review pull requesta kolegi lub debugowanie błędu, który pojawił się na stagingu. Czasem jest to rozmowa techniczna z klientem – synchronizacja wymagań, pytanie o oczekiwane zachowanie systemu, dyskusja o tym, czy obecna architektura utrzyma się przy większym obciążeniu.
Czego rzadko się spodziewać: siedzenia na spotkaniach, które nie wymagają Twojego wkładu, czekania na zatwierdzenia niebędące częścią procesu lub pracy nad rzeczami bez jasnego celu. Struktura projektów w ITDS na ogół to eliminuje.
Późne popołudnie: nauka jest częścią pracy
Jedną z rzeczy, które zaskakują developerów w pierwszym miesiącu w ITDS, jest to, że czas na naukę jest traktowany jako prawomocny czas pracy – a nie coś, co robisz po godzinach, żeby pozostać up-to-date.
Przejawia się to na różne sposoby w zależności od projektu i osoby. Czasem to 1:1 ze starszym konsultantem pracującym na tym samym koncie. Czasem to dedykowana godzina na głębsze poznanie technologii używanej w projekcie – Kubernetes, konkretna usługa AWS, zachowanie frameworka frontendowego, które nie jest w pełni udokumentowane. Czasem to po prostu czytanie dokumentacji architektury klienta, żeby zrozumieć szerszy kontekst.
Oczekiwanie nie jest takie, że przychodzisz już wiedząc wszystko. Chodzi o to, że aktywnie budujesz wiedzę, a tempo tego budowania jest czymś, co ITDS wspiera – a nie tylko zakłada.
Czego naprawdę uczy pierwszy miesiąc
Pod koniec pierwszego miesiąca większość full-stack developerów w ITDS ma jasny obraz tego, czym ta rola faktycznie jest – nie czym opisywało ją ogłoszenie, ale czym jest w praktyce.
Praca jest realna i klienci są realni. Ekspozycja na środowisko międzynarodowe następuje od pierwszego dnia, a nie w bliżej nieokreślonej przyszłości. Autonomia jest autentyczna, co oznacza, że odpowiedzialność też jest autentyczna. A ludzie – zarówno zespół ITDS, jak i klienci – to osoby, u boku których chcesz pracować, kiedy chcesz się rozwijać.
Taka kombinacja nie towarzyszy każdej roli. W ITDS pojawia się częściej niż można by się spodziewać.
Chcesz wiedzieć, jak wygląda rola full-stack developera w ITDS Polska dla Ciebie?
Zobacz otwarte rekrutacje i aplikuj →